Duas falhas críticas no PHP expõem 70% da web e acendem alerta de patch em massa

O que aconteceu

Na semana anterior a 28 de outubro de 2026, duas falhas críticas foram descobertas 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 linguagem open source que roda por trás de aproximadamente 70% dos sites da web, segundo dados citados pela TechCrunch. O caso, apelidado de "PHP2Shell" no episódio do podcast Equity que tratou do tema, levou organizações a correr contra o tempo para aplicar correções, e algumas chegaram a tirar sites do ar até concluir o patch.

O relato veio de Tomer Schwartz, CTO de Exposure Management e AppSec na Wiz (empresa de segurança em nuvem comprada pelo Google), em entrevista à jornalista Rebecca Bellan no podcast Equity, da TechCrunch. Schwartz fez parte do grupo que correu para corrigir as brechas.

Quem entrou na linha de frente

Segundo a TechCrunch, a resposta às falhas reuniu um grupo heterogêneo de atores em pouco tempo:

• Wiz, pelo braço liderado por Schwartz;
• OpenAI, citada como parte do esforço conjunto;
• um grupo de pesquisa identificado na reportagem como Calif;
• o próprio time de manutenção do PHP.

A fonte não detalha números de CVE, versões específicas do PHP afetadas nem o vetor técnico exato de exploração das falhas. O que fica claro é a escala do esforço: múltiplas organizações precisaram coordenar uma correção rápida para um componente que sustenta a maior parte da web.

Por que isso é diferente desta vez

O ponto central levantado pelos pesquisadores ouvidos pela TechCrunch não é a gravidade isolada das duas falhas, mas o que elas sinalizam: a inteligência artificial↳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 → está mudando a velocidade com que vulnerabilidades inéditas são descobertas e exploradas. Na visão de quem encontrou os bugs, o episódio é só o começo de um ciclo mais rápido de descoberta e ataque, o que justifica o termo "vulnpocalypse" usado no título do episódio.

Em resumo: se ferramentas de IA aceleram tanto a busca por falhas quanto a criação de exploits, o intervalo entre a divulgação de uma vulnerabilidade e sua exploração em massa tende a encolher. Isso muda o cálculo de risco de qualquer equipe que mantenha PHP em produção, porque a janela para aplicar o patch antes do ataque fica menor.

Exploração ativa já confirmada

Dois dias antes da publicação do episódio, a própria TechCrunch já havia noticiado que o governo dos Estados Unidos confirmou hackers explorando ativamente falhas críticas na web baseadas em PHP, conforme referência trazida na mesma página da reportagem. Ou seja, o cenário não ficou restrito ao campo teórico: a exploração em ambiente real já estava em curso enquanto as equipes ainda corrigiam sistemas.

Para quem administra infraestrutura PHP no Brasil, isso importa de forma direta. O país tem uma base enorme de aplicações em PHP: WordPress (que roda em PHP) domina parte relevante dos sites corporativos e institucionais brasileiros, Laravel é um dos frameworks mais usados em squads de produto locais, e grande parte da hospedagem compartilhada oferecida por provedores nacionais roda stacks PHP legados, muitas vezes sem atualização automática.

O que ficou em aberto

A reportagem da TechCrunch, por ser um resumo de episódio de podcast, não traz detalhes técnicos que normalmente acompanham um advisory de segurança: não há números de CVE, não há lista de versões do PHP afetadas e não há indicação pública de indicadores de comprometimento. Quem administra servidores PHP precisa buscar essas informações diretamente nos canais oficiais do projeto PHP e nos boletins de segurança da sua distribuição ou provedor de hospedagem.

No podcast, Schwartz e Bellan também discutiram dois pontos que vão além do incidente específico: como startups em estágio inicial podem incorporar segurança desde o desenho da arquitetura, e por que aplicar patches manualmente, bug a bug, servidor a servidor, não é uma estratégia que escala para organizações com muitas instâncias PHP em produção.

O que fazer agora

Mesmo sem os detalhes técnicos completos do PHP2Shell, o episódio funciona como lembrete prático para quem mantém PHP rodando em produção:

1. Verificar a versão do PHP em todos os ambientes, incluindo os que rodam atrás de CDN ou proxy, onde esquecer um servidor legado é comum.
2. Confirmar se o provedor de hospedagem já aplicou os patches de segurança mais recentes, especialmente em planos de hospedagem compartilhada.
3. Revisar se o processo de atualização depende de intervenção manual e, se depender, priorizar automação de patch management antes do próximo incidente da mesma escala.
4. Acompanhar os canais oficiais de segurança do PHP e do framework usado (Laravel, Symfony, WordPress) para advisories futuros, já que a fonte deste episódio não lista CVEs específicas.

O argumento de fundo, levantado por quem caçou as falhas, é que a velocidade de descoberta de vulnerabilidades com apoio de IA tende a crescer. Isso não significa pânico a cada bug novo, mas reforça que depender de patch manual como única linha de defesa fica cada vez mais arriscado para quem opera infraestrutura PHP em escala.

Fonte: TechCrunch