PHP2Shell (CVE-2026-109618 e CVE-2026-109619): o que verificamos e o que faríamos

A equipe de segurança do PHP lançou hoje, 21 de outubro, uma correção para duas vulnerabilidades, ambas com nota 9,2 de 10. Ela estava prevista para as 10h (horário da costa leste dos EUA) e saiu antes.

Os pesquisadores de segurança chamam a dupla de PHP2Shell. Os nomes oficiais são CVE-2026-109618 e CVE-2026-109619.

Se o seu site funciona com WordPress ou Drupal, ele funciona com PHP.

Atualização, 9h36 (horário da costa leste dos EUA): a correção saiu

O PHP lançou a correção antes do previsto. Nós a vimos em php.net às 9h36 (horário da costa leste dos EUA).

Atualize para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. O PHP 8.1 e versões anteriores não recebem atualização do projeto PHP. Algumas distribuições Linux e fornecedores de suporte levam a correção para versões antigas, então consulte o seu, ou migre para uma versão com suporte.

Junto com a versão, o PHP publicou qual é exatamente o problema. Em termos simples:

• As duas falhas estão na forma como o PHP prepara e encerra cada requisição web. Uma acontece quando o PHP fica sem memória no meio da preparação de uma requisição: a limpeza pode então tratar dados montados pela metade como se fossem reais. A outra deixa os dados de uma requisição para trás depois que a memória é liberada, e a requisição seguinte no mesmo processo pode usá-los.
• Qualquer uma delas pode permitir que um estranho rode o próprio código no seu servidor, sem fazer login, enviando requisições preparadas para isso.
• Afeta o PHP que serve páginas web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O PHP diz que o risco é maior com o mod_php do Apache, para o qual existe um exploit que funciona.
• Acontece antes que o código do seu site rode. Isso significa que um plugin de segurança dentro do WordPress ou do Drupal não consegue enxergá-la. O que protege você é a atualização, e os limites aplicados na frente do PHP.

O PHP também lista configurações que reduzem a exposição se você não puder atualizar na hora, e diz que elas não tornam um servidor seguro. Elas estão no alerta em php.net.

Por que o LFW.com nunca ficou exposto: essas falhas estão no código que roda quando o PHP trata uma requisição. As páginas do LFW.com são arquivos gerados com antecedência, e nenhum PHP lê qualquer requisição nos nossos servidores, então não há o que disparar. As cópias somente leitura que os governos europeus publicaram hoje de manhã são seguras pelo mesmo motivo.

Se você tirou um site do ar, ele pode voltar assim que sua hospedagem confirmar que ele está numa das versões corrigidas.

O que verificamos nos nossos próprios servidores

Começamos hoje de manhã pela nossa própria estrutura.

• LFW.com: não afetado. Ele é feito com Astro e servido pelo Node.js, e não há PHP instalado nos nossos servidores.
• Uma demonstração em WordPress: encontramos uma demonstração em WordPress, em contêiner, que tínhamos parado cerca de três semanas atrás e nunca removido. Ela não estava rodando e ficava atrás de uma senha. Mesmo assim, nós a removemos, com o banco de dados e as imagens.
• Nossas máquinas de desenvolvimento: as cópias locais de WordPress com que trabalhamos estão paradas, e nenhuma pode ser acessada pela internet.

A demonstração é a parte que vale a pena compartilhar. Não havia nada de errado com ela hoje. Era simplesmente um site em PHP de que não precisávamos mais, e ele ainda estava lá.

O site de que ninguém se lembra

Num dia como este, o site principal costuma receber a correção. Alguém é responsável por ele, e alguém está de olho nele.

O risco, com mais frequência, é um site que ninguém lembra que tem:

• o minissite de uma campanha que acabou
• a cópia de homologação que um fornecedor montou para uma reformulação
• o site de um evento de alguns anos atrás
• uma instalação de demonstração ou de teste que nunca foi retirada

Esses sites ainda rodam PHP, e ninguém está esperando a atualização.

O que faríamos hoje

Nesta ordem:

• Consulte primeiro a sua hospedagem. Em hospedagem gerenciada, veja a página de status ou o blog da sua hospedagem. Num dia como este, a maioria publica o plano, e muitas atualizam o PHP para você, então talvez nem seja preciso entrar em contato.
• Liste todos os sites que rodam PHP. Inclua os esquecidos. Remova o que você não usa.
• Aplique a correção nos demais no dia em que ela sair. Peça a quem cuida de cada site que avise quando terminar.
• Mantenha um firewall na frente até lá. Um firewall de aplicação web só ajuda se o servidor recusar o tráfego que não passa por ele, então verifique essa configuração também.

Tirar o servidor do ar

O National Cyber Security Centre do Reino Unido diz que, se você não puder atualizar nem aplicar as correções temporárias do PHP, deve considerar tirar o sistema do ar até poder fazê-lo. Diante da gravidade relatada, não é um mau conselho, mesmo que pareça exagerado.

Tirar o servidor do ar não precisa tirar o site do ar. Enquanto isso, você pode publicar uma cópia somente leitura: páginas estáticas, sem PHP por trás.

• Os moradores continuam lendo as páginas e encontrando os telefones.
• Formulários, logins e buscas esperam até a correção ser aplicada.
• A cópia sai do ar quando o site corrigido volta.

Para um site público do qual as pessoas dependem, é um meio-termo melhor do que uma página em branco.

Governos tiraram sites do ar hoje de manhã

Vários governos decidiram que algumas horas fora do ar valiam a pena.

Foi isto o que vimos às 8h50 (horário da costa leste dos EUA):

• O National Cyber Security Centre dos Países Baixos tirou o próprio site, NCSC.nl, do ar por precaução.
• DigiD e MijnOverheid, o login e o portal do cidadão do governo neerlandês, mostravam páginas de “temporariamente indisponível”.
• A Universidade de Viena desligou seus sites, formulários on-line, webmail e Moodle.
• O site da Câmara dos Representantes dos Países Baixos nem chegou a carregar para nós. O NL Times informou que ele também foi tirado do ar.
• O centro de TI do governo da Finlândia, Valtori, bloqueou por precaução o tráfego de internet de entrada para os serviços públicos do Estado e informou isso no seu site. Acrescentou que a interrupção não foi causada por um ataque.

Não há vergonha nisso. São algumas horas, e o problema é sério o bastante para que o próprio órgão encarregado da cibersegurança tenha escolhido essa opção para o seu site.

O que as agências de cibersegurança recomendaram às organizações

Não foi só a Europa. Agências nacionais de cibersegurança de três continentes publicaram alertas no mesmo dia, e elas concordam em quase tudo:

• Reino Unido: o National Cyber Security Centre recomenda encontrar todos os sistemas que rodam PHP, atualizar e considerar tirar um sistema do ar se não for possível.
• União Europeia: o CERT-EU, que protege as próprias instituições da UE, recomendou isolar as aplicações expostas à internet quando a correção não puder ser aplicada na hora.
• Singapura: a Cyber Security Agency recomenda aplicar a correção imediatamente e procurar PHP em todos os servidores web, mesmo onde o site principal não o usa.
• Austrália: o Australian Cyber Security Centre pediu às organizações que encontrem o PHP no seu ambiente, se preparem para aplicar a correção e fiquem atentas a sinais de ataque.

O ponto de Singapura é o que destacaríamos. Um site feito com outra tecnologia ainda pode ter PHP no mesmo servidor: uma ferramenta de administração antiga, uma instalação esquecida, um complemento de um fornecedor.

O que as páginas fora do ar deles acertaram

Observe essas páginas com atenção. Elas não estão em branco e não são mensagens de erro.

• Dizem o motivo. Cada uma cita as vulnerabilidades do PHP como a razão.
• Dizem o que está fora do ar. Viena lista todos os serviços, para que ninguém precise adivinhar.
• Dizem aonde ir. O NCSC indica o seu site de alertas, o LinkedIn e um endereço de e-mail atendido 24 horas por dia para ajuda urgente.
• São páginas estáticas. Não é preciso PHP para mostrá-las, e é por isso que continuam no ar.

Esse último ponto é toda a ideia da cópia somente leitura. Essas páginas são a versão mínima dela.

Escreva essa página antes de precisar dela

Nada disso é difícil num dia tranquilo. É difícil às 6h da manhã no dia de uma correção de segurança.

Por isso vale a pena decidir algumas coisas agora, enquanto nada está errado:

• Quem pode tirar o site do ar, e a quem essa pessoa avisa. Um nome, e um substituto.
• A própria página fora do ar, escrita e guardada num lugar que não roda PHP: o motivo, o que está fora do ar, onde acompanhar as atualizações e uma forma de falar com uma pessoa.
• Quais páginas nunca podem sair do ar. Avisos de emergência, alertas para ferver a água, os telefones. Essas entram na cópia somente leitura.
• Como você vai saber que é seguro voltar. Normalmente: a hospedagem confirma a versão corrigida, e você mesmo confere uma página.

Algumas horas fora do ar, planejadas, são um bom dia. Sem planejamento, viram uma história.

Se quiser uma ajuda

Teremos prazer em ajudar com qualquer parte disso, seja encontrar os sites esquecidos ou publicar uma cópia somente leitura. Escreva para nós.