PHP2Shell: duas falhas críticas no PHP já são alvo de ataques. O que donos de sites e usuários de WordPress devem conferir hoje

A equipe do PHP corrigiu duas falhas críticas que deixam um invasor executar código em um servidor web sem fazer login. Quais versões do PHP estão corrigidas, por que atualizar o WordPress não basta e o que fazer se você ainda não pode atualizar.

Ctrl+Alt IA 4 min
Um cadeado ciano brilhante se estilhaçando diante de um rack de servidor estilizado, finas linhas ciano de código saindo da rachadura, sobre fundo escuro

Em 21 de outubro, a equipe responsável pelo PHP lançou correções de emergência para duas falhas graves de segurança. Juntas, são chamadas de PHP2Shell. Elas deixam um invasor executar código em um servidor web sem fazer login, e os atacantes já começaram a tentar.

Se o seu site roda em PHP, o que inclui o WordPress, vale gastar cinco minutos hoje.

O que é o PHP2Shell

As duas falhas são de execução remota de código e não exigem login. Elas têm a mesma causa: o PHP pode deixar a memória corrompida quando uma requisição web termina de forma anormal.

  • CVE-2026-109618 pode dar a um invasor a execução de código com os privilégios da conta do worker web, por uma cadeia de fraquezas que começa com a falta de memória.
  • CVE-2026-109619 explora um estado global obsoleto, o que permite um “use-after-free” no heap (ler ou escrever em memória já liberada), vazamento de memória e execução de código.

As duas têm nota 9,2 de 10, crítica, na escala CVSS 4.0. A equipe do PHP diz que o risco é maior no Apache com mod_php, onde um exploit demonstrado usa uma única requisição sem login, antes de qualquer código seu rodar.

O que é afetado

Toda instalação de PHP que atende requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A BleepingComputer cita uma estimativa de mais de 5,1 milhões de hosts PHP expostos na internet, cerca de 3,8 milhões deles com ao menos uma porta aberta.

Um longo corredor de racks de servidores com pequenas luzes âmbar em um data center pouco iluminado
Ilustração gerada por IA.

A Cloudflare diz ter visto tentativas iniciais de ataque, mesmo com suas regras de firewall ativas. Essas regras são temporárias. O Centro Nacional de Segurança Cibernética do Reino Unido orientou as organizações a atualizar imediatamente ou tirar os sistemas do ar.

O que fazer

Atualize o PHP para uma versão corrigida: 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Os desenvolvedores dizem que nenhuma mitigação bloqueia totalmente os ataques.

Um notebook sobre uma mesa organizada mostrando uma janela escura sem texto legível, com um caderno de caixas de seleção em branco ao lado, em luz suave de fim de tarde, sem pessoas
Ilustração gerada por IA.

Em um site WordPress, a correção está no próprio PHP, e não no WordPress nem nos plugins. Na nossa leitura, e num ponto que o aviso da Vercel também faz em uma cobertura que vimos mas não abrimos: atualizar o WordPress ou um plugin não substitui a atualização do PHP.

1. Descubra a sua versão do PHP. No WordPress, vá em Ferramentas, depois Saúde do Site, depois Informações, depois Servidor. O painel da sua hospedagem também mostra. 2. Compare com a lista acima. Se for menor, ou não estiver nessas séries, fale com a hospedagem ou troque a versão no painel. 3. Em hospedagem gerenciada ou compartilhada, quem costuma aplicar a correção é a hospedagem. Peça que ela confirme por escrito que o seu site está corrigido.

Se você usa um PHP mais antigo

O PHP 8.1 e anteriores não recebem mais atualizações do projeto. Distribuições Linux e fornecedores de suporte de longo prazo podem lançar correções próprias, então pergunte ao seu. Para quem compila o PHP a partir do código-fonte, a equipe publicou correções mínimas para 7.4, 8.0 e 8.1. A BleepingComputer diz que quem usa PHP 7 ou anterior deve migrar para uma versão corrigida.

Se você não pode atualizar agora

A equipe do PHP lista medidas temporárias para administradores:

  • Para a CVE-2026-109618, definir memory_limit como -1 de um jeito que a aplicação não possa sobrescrever (por exemplo com php_admin_value), definir um post_max_size baixo (8M sem uploads, 32M com uploads) e usar limites de contêiner ou cgroup.
  • Para a CVE-2026-109619, definir session.upload_progress.enabled como 0 e reiniciar todos os workers. No PHP 8.5, definir fatal_error_backtraces como 0. Remover configurações inválidas ou obsoletas aplicadas por requisição e corrigir erros fatais e timeouts que um atacante consiga alcançar.
  • Esconder erros com error_reporting, display_errors ou o operador @ não ajuda.

Essas medidas reduzem o risco. Não substituem a atualização.

Para outro caso recente com passos práticos, veja a invasão ao OpenCode e, sobre como o acesso a sistemas em produção pode dar errado, agentes de IA que chegaram a sistemas sem autorização.

O que não conseguimos confirmar

Não abrimos o próprio aviso do php.net. A BleepingComputer não traz detalhes específicos sobre WordPress, e não sabemos quais empresas de hospedagem já aplicaram a correção. Não testamos nenhuma das mitigações.

CompartilharXWhatsApp

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *