Falha no PHP (PHP2Shell): seu site está em risco?

Em 21/10/2026, a equipe do PHP publicou correções urgentes para duas vulnerabilidades críticas no núcleo da linguagem. Se o seu site roda em PHP, veja como saber se está exposto e o que fazer hoje. Este artigo foi publicado em 22/10/2026 e usa apenas informações divulgadas pela PHP Foundation e por relatórios de segurança da Tenable e da Qualys.

O que é o PHP e por que essa falha importa tanto?

PHP é uma linguagem de programação que roda no servidor e monta as páginas que o visitante vê no navegador. Ela está por trás do WordPress, do WooCommerce, de muitos sistemas web feitos sob medida e de vários painéis de hospedagem.

Uma falha no PHP é diferente de uma falha em plugin: mesmo com WordPress e plugins atualizados, o site pode estar vulnerável, porque o defeito está na camada do servidor.

O que é exatamente o PHP2Shell?

PHP2Shell é o apelido dado a duas vulnerabilidades no núcleo do PHP que permitem execução remota de código por um atacante sem autenticação. Execução remota de código significa que alguém, de fora, consegue fazer o seu servidor rodar comandos dele, sem precisar de usuário ou senha. As duas falhas receberam nota CVSS v4.0 de 9,2 cada. Notas 10.0 chegaram a circular antes, mas a PHP Foundation afirmou que estavam incorretas.

CVE-2026-109618: corrupção após falta de memória

A primeira falha acontece depois de um erro de falta de memória (out-of-memory). Nesse cenário, dados de uma requisição que foram apenas parcialmente inicializados acabam sendo tratados como válidos.

CVE-2026-109619: estado global residual (use-after-free)

A segunda falha é do tipo use-after-free. Um resto de uma requisição anterior continua apontando para uma área de memória que já foi liberada, e outra requisição atendida pelo mesmo worker (o processo que executa o PHP) pode usar essa memória. O vazamento de memória foi confirmado como impacto. Por dentro: a requisição A termina e deixa um ponteiro velho; a requisição B chega ao mesmo worker e encontra esse resíduo.

Quem está em risco com a falha no PHP?

Está em risco toda instalação de PHP que atende requisições web e ainda não recebeu a correção. Isso inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php, porque o exploit demonstrado roda antes do código da aplicação. O PHP-FPM, muito comum em servidores modernos, também precisa de atualização.

Os perfis mais expostos costumam ser:

• Sites WordPress e lojas WooCommerce em hospedagem compartilhada.
• Sites e sistemas em VPS ou servidor dedicado.
• Sistemas internos em PHP, que muitas vezes ficam esquecidos em versões antigas.
• Escritórios e clínicas com cadastros online, onde uma invasão também vira problema de LGPD. Se esse é o seu caso, veja também como cuidamos de sites para clínicas.

Como descobrir qual versão do PHP o meu site usa?

A forma mais rápida depende de onde o site está:

No WordPress

No painel, acesse Ferramentas › Saúde do site › Informação › Servidor. Ali aparece a versão do PHP em uso.

No cPanel

Procure a opção "Selecionar versão do PHP" ou o gerenciador MultiPHP.

No servidor ou com a hospedagem

Quem tem acesso ao terminal pode rodar o comando php -v. Sem acesso técnico, pergunte ao suporte da hospedagem se o servidor já recebeu a correção do PHP2Shell.

Quais versões do PHP estão corrigidas?

As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O código afetado mais antigo encontrado remonta ao PHP 5.4.0, então praticamente qualquer versão anterior às corrigidas deve ser considerada vulnerável. Veja a situação de cada ramo:

Versão do PHP	Situação	O que fazer
8.5, 8.4, 8.3 e 8.2	Release oficial com correção (8.5.12, 8.4.27, 8.3.36 e 8.2.35)	Atualizar hoje para a versão corrigida do seu ramo e reiniciar os workers
7.4 a 8.1	Sem release oficial; apenas correções mínimas no código-fonte pela equipe de segurança do PHP	Confirmar com a hospedagem ou distribuição se o patch foi aplicado e planejar a migração para um ramo suportado
5.4 a 7.3	Fim de vida, sem correção	Migrar para um ramo suportado; até lá, isolar a aplicação e aplicar mitigações temporárias
Pacote de distribuição Linux ou da hospedagem	Pode manter o número antigo com a correção aplicada	Conferir o aviso de segurança do fornecedor, não só o número da versão

Atualizar é a única correção completa, mas o número exibido nem sempre conta a história toda: o que vale é o aviso de segurança do fornecedor.

Como a falha foi descoberta e já está sendo explorada?

Sim, há relatos de tentativas de exploração ativas, registradas pela Amazon, pela Cloudflare e pela watchTowr. A linha do tempo divulgada foi esta:

• 17/10/2026: a Amazon Threat Intelligence registrou uma tentativa de exploração em seus honeypots (servidores-isca usados para observar ataques).
• 20/10/2026: os identificadores das falhas vazaram e o PHP anunciou o release.
• 21/10/2026: o PHP publicou as correções, adiantadas de 22/10 por causa do vazamento.

A PHP Foundation informou que os códigos de exploração que circularam após o vazamento não eram funcionais no momento da divulgação. Mesmo assim, não baixe esses códigos para "testar" o seu site: exploits não verificados podem conter malware.

O que fazer agora para proteger o site?

O que fazer é atualizar o PHP para uma versão corrigida o quanto antes e, enquanto isso, reduzir a exposição. Siga este passo a passo hoje:

1. Cheque a versão do PHP pelo WordPress, pelo cPanel, com o comando php -v ou com o suporte.
2. Peça a atualização à hospedagem e solicite a confirmação por escrito de que o patch do PHP2Shell foi aplicado.
3. Atualize para a versão corrigida do seu ramo (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) ou para um ramo suportado.
4. Se estiver em versão sem suporte (5.4 a 7.3), planeje a migração imediatamente.
5. Aplique mitigações temporárias só se não puder atualizar agora, sabendo que elas não tornam o site seguro (detalhes abaixo).
6. Coloque o site atrás de um WAF, como as regras publicadas pela Cloudflare, como camada extra.
7. Revise os logs de acesso e de erro desde 17/10/2026, procurando requisições estranhas e erros de memória fora do padrão.
8. Troque senhas de painel, banco de dados, FTP e hospedagem se houver qualquer sinal de invasão.
9. Faça e guarde um backup recente, fora do servidor, antes e depois das mudanças.

Se você usa WordPress, vale complementar com um reforço geral de segurança para WordPress.

Mitigações temporárias, se não der para atualizar hoje

Mitigação temporária é uma configuração que reduz a chance de exploração enquanto a atualização não acontece, mas não elimina a falha. As divulgadas foram:

• Para a CVE-2026-109618: definir memory_limit=-1 imposto pelo administrador, o que aumenta o risco de esgotamento de recursos e deve ser usado só por pouco tempo, junto com limites de tamanho de requisição.
• Para a CVE-2026-109619: session.upload_progress.enabled=0 e, no PHP 8.5, fatal_error_backtraces=0.
• No PHP-FPM: pm.max_requests=1, para que cada worker atenda uma requisição e seja reciclado.
• Depois de qualquer ajuste: reiniciar todos os workers do PHP.
• Regras de WAF da Cloudflare, inclusive no plano gratuito, que só cobrem o tráfego que passa pela Cloudflare.
• Isolar aplicações expostas até corrigir, como recomenda o CERT-EU.

Como saber se o meu site já foi invadido?

Não existe um único sinal definitivo, mas alguns indícios costumam aparecer depois de uma exploração. Fique atento a:

• Arquivos PHP novos ou alterados em pastas onde você não mexeu, como uploads.
• Usuários administradores que ninguém da equipe criou.
• Redirecionamentos para sites estranhos, páginas de spam ou avisos do Google sobre o site.
• Picos de uso de processador ou memória e lentidão sem explicação.
• Requisições incomuns nos logs desde 17/10/2026, especialmente seguidas de erros de memória.

Se encontrar algum desses sinais, não apague nada às pressas: isso destrói evidências. Siga o roteiro do nosso guia site WordPress invadido: o que fazer ou conte com o serviço de recuperação de site invadido e segurança da W Service.

Preciso comunicar a ANPD se o site for invadido?

Sim, se a invasão envolver dados pessoais e puder causar risco ou dano relevante aos titulares. Pela Resolução CD/ANPD nº 15/2024, esse incidente de segurança deve ser comunicado à ANPD e aos titulares em até 3 dias úteis, e uma comunicação preliminar pode ser complementada em até 20 dias úteis. Revisar os logs cedo é o que permite saber, dentro do prazo, se houve acesso a dados de clientes.

Perguntas frequentes

Não sabe qual versão do PHP o seu site usa ou se a hospedagem já aplicou a correção? A W Service verifica para você. Peça o seu diagnóstico gratuito, com atendimento online para todo o Brasil.