Falha crítica do WordPress começou a ser explorada horas depois da correção
A vulnerabilidade CVE-2026-87902 foi corrigida no WordPress 7.1.2. Investigadores observaram sondagens em menos de cinco horas e, depois, tentativas de exploração ativa.
O WordPress lançou a versão 7.1.2 a 22 de setembro com uma única correção de segurança. A falha, identificada como CVE-2026-87902, afeta a resolução de templates de página e pode, em determinadas condições, permitir inclusão de ficheiros locais e chegar a execução remota de código.
A parte mais importante da história não é apenas a gravidade da vulnerabilidade. É a velocidade. A Patchstack diz ter observado as primeiras sondagens dirigidas à falha menos de cinco horas depois da publicação da atualização. Nos dias seguintes, outros investigadores começaram também a registar tentativas de exploração ativa.
Isto não significa que todos os sites WordPress sejam exploráveis da mesma forma. Existem pré-condições específicas relacionadas com a configuração do servidor e com os ficheiros disponíveis no sistema. Mas mostra até que ponto o intervalo entre divulgar um patch e começar a ver atividade maliciosa pode ser curto.
Uma atualização que também inicia uma corrida
O WordPress descreve o problema como uma falha de path traversal sem autenticação na resolução de templates de página, com possibilidade condicional de execução remota de código. A versão 7.1.2 corrige o problema e o projeto recomenda atualização imediata.
A correção foi também disponibilizada para várias versões anteriores ainda abrangidas por atualizações de segurança. Isso é relevante porque instalações antigas podem receber o patch sem fazer imediatamente uma atualização de versão principal.
Do lado dos atacantes, uma atualização de segurança também fornece informação. Comparar o código vulnerável com o código corrigido pode revelar exatamente que validação mudou e acelerar a criação de testes e tentativas de exploração.
Primeiro sondagens, depois exploração ativa
A Patchstack registou atividade de reconhecimento no próprio dia 22 de setembro. Os primeiros pedidos apontavam para ficheiros normais do WordPress e serviam sobretudo para perceber se um site respondia como um sistema vulnerável.
Relatos publicados depois indicam uma mudança de comportamento: investigadores da Previdian e da própria Patchstack observaram pedidos destinados a explorar a falha de forma ativa em ambientes de monitorização. A distinção é importante. Uma sonda procura confirmar se existe uma porta aberta; uma tentativa de exploração procura efetivamente atravessá-la.
O número de tentativas observado por redes de segurança não permite concluir quantos sites foram comprometidos. Também não significa que todos os pedidos tenham sido bem-sucedidos. O dado relevante é que a vulnerabilidade passou rapidamente de informação pública a alvo operacional.
O problema do patch gap
Em segurança, patch gap é o intervalo entre existir uma correção e essa correção estar realmente instalada nos sistemas expostos. É nesse espaço que organizações e atacantes correm em sentidos opostos.
Quanto mais automatizada é a análise de diferenças entre versões e a procura por sistemas desatualizados, menor tende a ser a margem para adiar uma atualização crítica. O caso da CVE-2026-87902 ilustra essa compressão do tempo: a correção foi publicada e, poucas horas depois, já havia atividade especificamente desenhada em torno da falha.
O que deve retirar um administrador de um site
A conclusão prática não é que o WordPress tenha subitamente deixado de ser seguro. É que uma atualização de segurança crítica deve ser tratada como uma janela operacional curta, não como uma tarefa para a próxima semana.
Para esta vulnerabilidade, a orientação principal continua a ser simples: instalar o WordPress 7.1.2 ou a versão corrigida correspondente ao ramo utilizado e rever sistemas que tenham permanecido expostos antes da atualização.
A história deixa também um sinal mais amplo: na web moderna, publicar a correção e começar a observar exploração podem já fazer parte do mesmo ciclo de horas.