Uma vulnerabilidade crítica no PHP está sendo ativamente explorada por invasores, segundo relatos recebidos de diversos parceiros de hospedagem. A Cloudflare também confirma ter identificado os primeiros ataques em andamento. O problema afeta diretamente a linguagem PHP, utilizada como base por plataformas amplamente conhecidas, como WordPress, Drupal, Magento, Joomla e Laravel — ou seja, qualquer site construído sobre essas tecnologias pode estar exposto caso esteja rodando uma versão vulnerável do PHP.
Até o momento, a única solução confirmada para essa falha no PHP é a atualização imediata da linguagem. A equipe de segurança do PHP programou um lançamento emergencial para o dia 21 de outubro de 2026, às 14h00 UTC, quando devem ser disponibilizadas as versões corrigidas.
Linha do tempo da falha no PHP
Os acontecimentos se desenrolaram rapidamente nos últimos dias. Veja como a situação evoluiu:
- Mais tarde, em 21 de outubro – Serviços como os sites do governo holandês DigiD e MijnOverheid, o The SEO Framework e grandes plataformas japonesas saem do ar até que a correção seja disponibilizada.
- 07h43 UTC – O CTO da Cloudflare afirma que a empresa está vendo os primeiros ataques e que já implementou regras iniciais de WAF para os vetores de exploração conhecidos.
- 07h34 UTC – Diversos incidentes de exploração ativa são reportados por parceiros de hospedagem à Patchstack.
- 20 de outubro – Detalhes vazam antes da divulgação coordenada. A equipe de segurança do PHP anuncia o lançamento emergencial para o dia 21 de outubro.
O que se sabe até agora sobre a falha
As duas vulnerabilidades foram catalogadas como CVE-2026-109618 e CVE-2026-109619. A equipe de segurança do PHP classifica ambas como críticas, com pontuação CVSS v4.0 de 9,2. Vale destacar que alguns relatos iniciais chegaram a mencionar nota 10,0, mas 9,2 é a classificação oficial confirmada.
Os dois problemas residem no próprio interpretador do PHP, e não em alguma aplicação específica — por isso, qualquer site rodando uma versão vulnerável está exposto, independentemente da plataforma utilizada. Os detalhes vazaram em 20 de outubro, antes da divulgação coordenada, e o incidente já vem sendo chamado de “PHP2Shell”. A empresa de segurança watchTowr confirmou que as vulnerabilidades são reais e conseguiu reproduzir uma delas, que permitiria execução remota de código.
Diante do risco, diversas organizações optaram por tirar seus serviços do ar como medida de precaução até que a correção seja lançada. Entre os casos relatados:
- A emissora holandesa NOS informa que DigiD, MijnOverheid, o site da Câmara dos Deputados holandesa, o Tweakers e o site do Centro Nacional de Segurança Cibernética da Holanda estão entre os serviços fora do ar.
- O veículo japonês ITmedia relata manutenção emergencial em diversos serviços importantes, incluindo Kodmon, Shadowverse: Worlds Beyond e Sakura Rental Server, casos que acredita-se estarem relacionados a essa vulnerabilidade. Outros serviços, como BASE e Xserver, devem seguir o mesmo caminho.
- Os desenvolvedores do The SEO Framework confirmaram que também tiraram seus servidores do ar.
A Cloudflare afirma que os sites PHP protegidos por sua rede já contam com um conjunto inicial de regras de WAF voltadas aos vetores de ataque conhecidos, disponíveis para todos os clientes, inclusive os do plano gratuito. O CTO da empresa reforça que novos ataques continuam surgindo e que as mitigações estão sendo atualizadas conforme novos vetores aparecem — no entanto, ele é claro ao afirmar que essa é apenas uma solução paliativa. Essas regras só funcionam, aliás, se o servidor aceitar tráfego exclusivamente vindo da Cloudflare.
As versões afetadas e corrigidas devem ser divulgadas junto com o lançamento oficial. Branches do PHP já fora do ciclo de suporte (end-of-life) podem não receber correção — informação que, por ora, ainda não foi confirmada. Um desenvolvedor do núcleo do PHP afirmou que atualizar ou corrigir a versão é a única mitigação eficaz disponível.
O CERT-EU já emitiu um alerta oficial sobre o caso, e o Centro Nacional de Segurança Cibernética do Reino Unido (NCSC) publicou um comunicado urgindo organizações a se prepararem para aplicar a atualização do PHP assim que ela for liberada. Segundo o órgão, quando a correção imediata não for viável, o ideal é considerar tirar o sistema do ar até que seja possível mitigá-lo completamente.
Como proteger seu site da vulnerabilidade no PHP
Diante da gravidade do caso, Plustag IA recomenda uma série de cuidados para reduzir os riscos:
- Atualizar o PHP assim que as versões corrigidas forem liberadas, às 14h00 UTC. Caso utilize hospedagem gerenciada, é importante perguntar diretamente ao provedor quando a atualização será aplicada.
- Mapear todas as instalações de PHP em uso — servidores, containers, ambientes de teste (staging) e qualquer software de terceiros que embuta o PHP — para saber exatamente o que precisa ser atualizado.
- Quem ainda utiliza uma versão do PHP já fora do ciclo de suporte deve buscar, desde já, alternativas de upgrade junto ao provedor de hospedagem.
- Evitar plugins de “correção” não oficiais ou trechos de código copiados de fontes não verificadas, já que podem comprometer ainda mais o funcionamento do site.
- Se o site for considerado de alto risco e a atualização não puder ser aplicada de imediato, vale considerar colocá-lo em modo de manutenção ou tirá-lo do ar temporariamente — recomendação também seguida pelo NCSC britânico.
Mitigações parciais, mas não definitivas
Análises preliminares apontam que o problema está relacionado à funcionalidade de progresso de upload por sessão do PHP e a requisições de upload de arquivos no formato multipart. Diante disso, alguns pesquisadores sugerem medidas temporárias até que a correção definitiva seja aplicada.
Uma delas é desativar o progresso de upload por sessão e ativar o modo estrito de sessão. Como essa função vem habilitada por padrão, é recomendado adicionar as configurações abaixo ao php.ini, .user.ini ou às configurações de PHP do provedor de hospedagem, e depois reiniciar o serviço:
session.upload_progress.enabled = Off
session.use_strict_mode = 1
Com isso, as barras de progresso de upload deixam de funcionar, embora os próprios uploads continuem ocorrendo normalmente. Já o modo estrito é uma configuração de reforço geral recomendada pelo próprio PHP para qualquer site.
Outra sugestão é bloquear requisições multipart nos pontos em que elas não são necessárias. Para quem utiliza um WAF ou proxy reverso, é possível rejeitar ou inspecionar requisições POST multipart em endpoints que não aceitam upload de arquivos. Recomenda-se, porém, fazer a correspondência de forma ampla pelo termo “multipart” no cabeçalho Content-Type, sem diferenciar maiúsculas de minúsculas, em vez de buscar exatamente a string “multipart/form-data” — já que invasores podem variar a formatação exata. É fundamental testar antes de aplicar essa medida, pois ela pode comprometer uploads legítimos, como bibliotecas de mídia, formulários de contato com anexos e páginas de checkout ou conta, caso seja aplicada de forma muito ampla.
Apesar dessas alternativas, vale reforçar: trata-se apenas de mitigações parciais, que não interrompem completamente a exploração da falha. Desenvolvedores do núcleo do PHP reiteram que a única forma de resolver o problema por completo é atualizar para a nova versão que corrige a vulnerabilidade — todas as demais medidas devem ser tratadas como soluções temporárias, nunca como substitutas da atualização oficial.
Com informações de patchstack.com.
