793 domínios de criptomoedas rodam o PHP que permite invadir servidores sem senha

O projeto PHP publicou nesta quarta-feira as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que fecham duas brechas de nota 9,2 em uma escala que vai até 10. Elas estão registradas como CVE-2026-109618 e CVE-2026-109619 e permitem que um desconhecido execute código no servidor sem senha. Atingem toda instalação que responda a requisições na web, de PHP-FPM a Apache com mod_php, passando por LiteSpeed e FrankenPHP.

A base é grande. O PHP sustenta 69,3% dos sites cujo servidor é conhecido, na medição da W3Techs, e é a linguagem por trás do WordPress, do Drupal, do Joomla e do MediaWiki que roda a Wikipédia. A brecha está no motor da linguagem, na parte que quase toda requisição atravessa. Trocar plugin, tema ou CMS não resolve nada disso.

O defeito aparece quando uma requisição termina mal. Se ela estoura o limite de memória ou morre em um erro fatal, o PHP pode deixar para trás pedaços do estado interno daquele processo. A requisição seguinte, atendida pelo mesmo worker, reaproveita o que sobrou como se fosse dado novo.

O resultado tem dois níveis. No primeiro, o servidor devolve memória do processo para quem pediu, e nela podem estar senhas, certificados, chaves de API e tokens de sessão de requisições alheias. No segundo, o invasor escreve nessa memória e passa a executar o próprio código. A Wiz Research demonstrou as duas coisas, leitura de memória sem autenticação mesmo em aplicações que nunca abrem sessão e execução de código nas imagens mais recentes de WordPress, Drupal e Joomla.

A varredura que achou 793 domínios

A SlowMist varreu os ativos em PHP do setor com o MistEye, ferramenta própria de monitoramento, e contou 793 domínios. O comunicado não nomeia nenhuma das plataformas e pede que exchanges, projetos e provedores de carteira avaliem a exposição e instalem as versões corrigidas. Até a noite desta quarta não havia registro público de ataque bem-sucedido contra plataformas do setor.

A camada mais exposta costuma ser a loja que aceita criptomoeda. A CoinGate e a BitPay mantêm plugins de pagamento publicados no diretório oficial do WordPress, e esse plugin roda no mesmo PHP que atende o checkout. As chaves da conta de recebimento que ele usa ficam guardadas no banco do próprio site e são carregadas em memória a cada pedido. A leitura de memória demonstrada pela Wiz alcança exatamente esse tipo de credencial.

Em exchange grande, o risco depende de o portal ainda estar em PHP. A Kraken começou a migrar o backend para Rust em 2018 e, em dezembro do ano passado, descreveu a linguagem como padrão da casa, com milhões de linhas em centenas de serviços. Quem fez o mesmo caminho tem menos superfície nesta falha específica. Chaves guardadas em carteira física e contratos inteligentes ficam fora dela, porque não passam por PHP.

Changpeng Zhao, fundador da Binance, publicou um aviso no perfil dele no X pedindo cautela ao navegar nos próximos dias, porque parte dos administradores demora a aplicar correção. O post teve 4.745 curtidas. O aviso chega ao usuário, que não tem o que instalar e depende do site onde põe a senha.

A correção saiu e quem instala é o dono do servidor

A atualização oficial está nas versões 8.5, 8.4, 8.3 e 8.2. O PHP considera o mod_php o cenário de maior risco, porque ali uma requisição não autenticada alcança a brecha antes de qualquer linha da aplicação rodar. As distribuições Linux e as empresas que mantêm versões com suporte longo já tinham recebido o remendo antes do anúncio e vêm publicando os pacotes desde então. A linha 8.1 e as anteriores já não recebem atualização. Ainda assim, para 7.4, 8.0 e 8.1 o time publicou um remendo mínimo de código-fonte, voltado a quem compila a própria instalação.

Para quem não consegue atualizar hoje, a nota do projeto lista ajustes que fecham caminhos específicos. Desligar o progresso de upload de sessão, tirar o teto de memória do controle da aplicação e baixar o tamanho máximo de POST para 8 MB cobrem parte dos ataques. Nenhum deles deixa a instalação segura.

Existe também a camada de quem fica na frente do servidor. A Cloudflare começou a implantar regras contra a falha no começo de outubro. O bloqueio entrou no ar 9 horas antes de o anúncio sair, e clientes de plano gratuito e pago passaram a ser protegidos por padrão a partir das 3h02 UTC desta quarta. A empresa relata tráfego de ataque contra clientes e tentativas de alterar o payload para furar a regra. Para isso precisou de um recurso novo no firewall, que olha pedido e resposta da mesma transação, porque o pedido sozinho não distingue ataque de acesso normal.

Uma década no código e a correção travada por escolhas

O problema não é novo. Em 2024, durante a primeira auditoria externa do PHP em anos, um desenvolvedor do núcleo viu os primeiros sinais do erro de memória enquanto corrigia outra coisa. Naquele ano a exploração foi teorizada, sem vetor concreto, e o assunto ficou parado. Fechar a brecha exigia escolher entre quebrar compatibilidade, abrir uma nova porta para derrubar o serviço ou obrigar centenas de extensões a mudar, e o time, que decide por consenso, ficou meses sem definir qual caminho seguir. A própria fundação classificou a demora como falha de processo e de recursos.

O quadro mudou em agosto. A Calif reportou no dia 11 uma forma de executar código à distância sem precisar de condição alguma, a OpenAI chegou à mesma origem do problema no mesmo dia e a Wiz apresentou outros vetores em 24 de agosto. Daí em diante a correção virou prioridade do time inteiro.

A exploração ficou viável pela mesma tecnologia que agora a torna mais fácil de repetir. A Wiz usou o Wiz Atlas, o modelo Gemini 4 Argon e o GPT-5.6 Sol no trabalho. O encadeamento de falhas exigia adaptar o ataque à forma como cada alvo organiza a memória, com teste e depuração a cada tentativa, e os modelos de fronteira fizeram essa adaptação sair em horas, em várias aplicações. A complexidade deixou de ser a barreira que mantinha essas falhas fora de alcance.

A divulgação coordenada também furou. Na terça-feira, perto das 15h UTC, os identificadores das duas brechas passaram a ser compartilhados em fóruns com nota 10,0, acima da nota real de 9,2, e sem detalhe técnico. O projeto publicou o alerta às 19h30 e adiantou a publicação de 22 para 21 de outubro. Por volta das 20h, a Calif publicou por engano um vídeo com a prova de conceito rodando, apagou, e as cópias já estavam em circulação. Na manhã seguinte, às 7h41 UTC, a Chainguard colocou no ar imagens com a correção, mais de 6 horas antes do prazo combinado, e qualquer atacante pôde estudar o remendo já compilado enquanto o resto do mundo esperava.

A Holanda tirou sites do ar antes de a correção sair

Antes do pacote, o centro de segurança cibernética holandês recomendou que donos de site avaliassem o risco e tirassem do ar o que não pudesse ser corrigido na hora. O governo seguiu a recomendação. O DigiD, o sistema de identidade digital do governo, e o MijnOverheid saíram do ar, assim como o site da Câmara dos Deputados e o do próprio centro de segurança cibernética. A Receita holandesa desligou parte das páginas e manteve no ar o portal principal, que não roda PHP.

A distribuição das versões mostra onde a falha segue aberta. Na medição da W3Techs, 27% dos sites que usam PHP continuam na linha 7 e 7,7% na linha 5, justamente as que saíram do suporte. Para 7.4 existe o remendo de código-fonte. Para as anteriores não existe nada, e a saída é trocar de versão. O time do PHP afirmou que, no momento do anúncio, não havia identificado exploit funcional entre as provas de conceito que circulavam.