CISA confirma exploração ativa de falhas críticas no PHP e dá três dias para agências dos EUA corrigirem

A agência de cibersegurança↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → dos Estados Unidos, a CISA, confirmou nesta segunda-feira (26) que hackers já exploram ativamente duas vulnerabilidades críticas no PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) →. A agência deu a órgãos civis do governo federal americano um prazo de três dias para corrigir seus sistemas, segundo reportagem do TechCrunch.

O alerta chega menos de uma semana depois de os mantenedores do PHP lançarem os patches para as duas falhas, que permitem a um invasor assumir o controle remoto de um servidor vulnerável pela internet, sem precisar de senha. A gravidade do problema já havia levado governos e grandes empresas a tirar sites do ar para aplicar a correção antes mesmo da confirmação de exploração ativa.

A CISA não detalhou, em sua declaração de segunda-feira, quem está por trás dos ataques. O aviso veio pouco depois de pesquisadores de segurança independentes relatarem evidências de que as falhas já estavam sendo usadas em ataques reais.

PHP2Shell: da descoberta esquecida ao exploit real

As duas falhas foram batizadas de PHP2Shell. Segundo o TechCrunch, elas foram descobertas há dois anos, mas a fundação sem fins lucrativos que mantém o PHP considerou na época que não havia forma prática de explorá-las, e os bugs ficaram sem correção.

Isso mudou neste ano. Pesquisadores da empresa de segurança Calif encontraram uma forma de explorar as duas vulnerabilidades adormecidas com a ajuda de um modelo de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →. O caso do PHP2Shell não é isolado: a reportagem destaca que esse tipo de falha, descoberta mas deixada de lado por parecer inofensiva, é cada vez mais comum entre os alvos de modelos de IA capazes de encadear múltiplas vulnerabilidades até montar um exploit funcional.

Em resumo: o que separava uma falha teórica de um exploit prático deixou de ser o trabalho manual de um pesquisador humano e passou a ser o tempo de processamento de um modelo de IA. Isso reduz a margem de segurança que projetos como o PHP tinham ao decidir não corrigir bugs considerados de baixo risco prático.

Por que isso pesa tanto quando 70% da web roda PHP

O PHP move, segundo a reportagem, cerca de 70% dos servidores voltados à internet. No Brasil, essa fatia aparece em WordPress (que sozinho já é boa parte da web nacional), em frameworks como Laravel e Symfony, em sistemas legados de bancos, varejo e setor público, e em boa parte dos painéis administrativos que rodam atrás de CDNs sem ninguém monitorar de perto.

A CISA emite ordens de correção (as chamadas Binding Operational Directives) apenas para agências civis do governo americano, mas o efeito prático vai além das fronteiras dos EUA: quando uma falha crítica de um software tão difundido passa de teórica para explorada, o relógio para todo mundo que roda a mesma stack começa a correr junto. Isso vale tanto para quem opera infraestrutura própria quanto para quem terceiriza hospedagem sem saber qual versão de PHP está rodando por baixo.

A reportagem do TechCrunch também situa o caso num problema mais estrutural: o PHP é uma das muitas tecnologias antigas que sustentam a internet moderna, mas que recebem financiamento e recursos insuficientes há anos, o que dificulta para projetos de código aberto como esse bancar revisões de segurança que poderiam ter achado essas falhas antes.

Checklist técnico: o que fazer agora

Quem mantém qualquer aplicação PHP em produção, próprio ou de terceiro, tem algumas verificações imediatas a fazer:

1. Confirmar a versão de PHP em execução (php -v no servidor ou no container) e comparar com o changelog oficial de segurança do PHP para saber se o patch mais recente já está aplicado.
2. Verificar, no caso de hospedagem gerenciada (cPanel, hosts compartilhados, PaaS), se o provedor já aplicou a atualização ou se o patch depende de ação manual do cliente.
3. Revisar dependências via composer outdated, já que frameworks como Laravel e Symfony costumam travar a versão mínima de PHP suportada no composer.json.
4. Checar logs de acesso recentes em busca de padrões incomuns em endpoints administrativos ou de upload, comuns em exploits que buscam execução remota de código.
5. Priorizar o patch acima de qualquer outra tarefa de sprint caso o ambiente seja exposto à internet pública, já que a CISA classificou a situação como exploração confirmada, não apenas risco teórico.

Para quem administra múltiplos ambientes, vale tratar esse patch com a mesma urgência que uma falha de zero-day em produção: não é hora de esperar a próxima janela de manutenção programada.

O que ainda fica em aberto

A CISA não divulgou os identificadores CVE das duas falhas nem detalhou os vetores técnicos exatos do PHP2Shell em sua declaração pública, e o TechCrunch não teve acesso a essa informação até a publicação da matéria. Também não há confirmação pública de quais grupos estão por trás da exploração ativa, nem do volume de sistemas já comprometidos fora do universo de agências federais americanas monitoradas pela CISA.

O episódio reforça um padrão que tende a se repetir: vulnerabilidades represadas por anos, por parecerem impraticáveis de explorar, estão sendo reabertas por modelos de IA capazes de montar o exploit que um pesquisador humano levaria meses para construir manualmente. Para quem mantém software em produção, isso muda o cálculo de risco de qualquer bug "conhecido, mas não corrigido" na pilha.

Fonte: TechCrunch