Falhas no PHP em 2026: por que sites saíram do ar e qual foi o impacto

Duas falhas críticas no runtime PHP motivaram atualizações urgentes e suspensões preventivas de alguns sites. Indisponibilidade, exposição e invasão confirmada são fatos diferentes.

Em 21 de outubro de 2026, surgiram avisos de segurança, janelas emergenciais de manutenção e relatos de sites fora do ar ligados ao PHP. É fácil resumir isso como “o PHP caiu no mundo todo”, mas essa frase mistura acontecimentos diferentes.

O projeto PHP publicou correções para duas vulnerabilidades críticas no runtime, ambas capazes de permitir execução remota de código sem autenticação em instalações vulneráveis. Diante desse risco, alguns operadores preferiram suspender serviços enquanto preparavam, aplicavam e verificavam as atualizações. Uma página temporariamente indisponível, portanto, não é por si só evidência de invasão.

O episódio merece atenção pela gravidade técnica e pelo alcance potencial de uma linguagem usada em tantos sites. Também merece precisão: não há um único serviço central chamado “PHP” cuja queda explique todas as páginas indisponíveis.

O que foi confirmado até 21 de outubro

Em 20 de outubro, a equipe de segurança do PHP avisou que lançaria correções para duas falhas classificadas com 9,2 no CVSS v4.0. No dia seguinte, foram disponibilizadas as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Os identificadores são CVE-2026-109618 e CVE-2026-109619. A recomendação oficial é atualizar imediatamente as instalações que atendem requisições web. Fonte: projeto PHP.

As falhas estão no PHP em si, abaixo da aplicação. O aviso inclui ambientes com PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O projeto considera mod_php o cenário de maior risco: há uma exploração demonstrada em que uma requisição sem autenticação aciona a falha antes mesmo de o código da aplicação começar a rodar. Isso não significa que o mesmo caminho tenha sido demonstrado em todas as formas de executar PHP. Fonte: projeto PHP.

O que as duas falhas fazem, sem entrar no passo a passo de exploração

A CVE-2026-109618 envolve o tratamento de falta de memória. Em certas condições, o PHP interrompe uma requisição enquanto dados internos ainda não foram inicializados por completo. A limpeza posterior pode tratar esse estado inválido como se estivesse pronto para uso. O aviso técnico descreve como isso pode resultar em corrupção de memória e execução de código.

A CVE-2026-109619 envolve estado global antigo. Um worker pode conservar uma referência a dados de uma requisição depois que a memória correspondente foi liberada. Outra requisição atendida pelo mesmo worker pode alcançar essa referência antes da inicialização normal. O segundo aviso técnico documenta caminhos de exploração confirmados e outros que dependem da configuração ou do comportamento da aplicação.

Em termos práticos, o problema não se resolve apenas revisando uma rota de WordPress, Laravel ou outro software feito em PHP. É necessário verificar e corrigir a versão do runtime efetivamente usada pelos processos que recebem tráfego.

Por que alguns sites ficaram fora do ar?

Uma vulnerabilidade e uma indisponibilidade são fatos diferentes. Um operador pode manter um serviço no ar enquanto aplica um patch, restringir o acesso temporariamente ou suspender a aplicação até concluir a verificação. A escolha depende da exposição e da capacidade de resposta de cada ambiente.

A ICANN informou ter desativado temporariamente três sites administrativos baseados em PHP por cautela. No comunicado, disse não haver indicação de que seus sistemas tivessem sido afetados negativamente. A Contabo informou a suspensão de sua hospedagem compartilhada com cPanel até aplicar e verificar a correção, deixando claro que outros serviços continuavam operando e que não tinha evidência de impacto nos dados de clientes.

Esses exemplos mostram respostas de operadores específicos. Não permitem concluir quantos sites ficaram fora do ar no mundo, por quanto tempo cada um permaneceu indisponível nem que todos tenham sofrido um ataque.

Quem opera PHP deve verificar o quê?

A primeira tarefa é localizar todas as instalações que servem requisições web, incluindo servidores, pools, imagens de contêiner, hospedagens gerenciadas e aplicações de terceiros que embutem PHP. A versão exibida no terminal de um servidor pode não ser a mesma usada pelo site publicado. É preciso conferir o runtime em execução e a origem dos pacotes.

Depois, a sequência prática é:

1. Confirmar a exposição. Identificar versão, forma de execução do PHP e serviços acessíveis pela internet. Priorizar ambientes que recebem tráfego público.
2. Consultar a origem da atualização. Para uma instalação mantida diretamente, verificar os pacotes da distribuição ou a imagem usada. Em hospedagem gerenciada, acompanhar o aviso do fornecedor e pedir confirmação da aplicação do patch.
3. Aplicar uma versão corrigida. O projeto PHP disponibilizou 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Se o fornecedor utiliza correção retroportada, validar pelo comunicado e pela versão do pacote distribuído, em vez de confiar apenas no número principal do PHP.
4. Reiniciar ou substituir os processos afetados e validar. Garantir que os workers antigos deixaram de atender requisições, executar verificações funcionais dos fluxos importantes e monitorar erros e comportamento anormal.
5. Investigar indícios concretos, se houver. Logs e alertas podem ajudar a avaliar tentativas de abuso, mas sua ausência não prova que a instalação esteve segura. A análise de eventual comprometimento é separada da aplicação do patch.

A CERT-EU recomenda corrigir imediatamente. Quando isso não for viável, recomenda considerar o isolamento de aplicações expostas à internet até a correção ser aplicada e verificada. Atualizar apenas CMS, temas ou plugins não substitui a atualização do PHP subjacente.

E se a aplicação estiver em uma versão antiga?

PHP 8.1 e anteriores não recebem lançamentos regulares de segurança do projeto PHP. Isso não quer dizer que toda instalação antiga esteja necessariamente sem opção imediata: algumas distribuições e fornecedores de suporte prolongado oferecem correções retroportadas. Para este caso, a equipe do PHP também disponibilizou retroports mínimos de código-fonte para 7.4, 8.0 e 8.1. A decisão precisa considerar quem fornece e mantém o pacote em uso; migrar para uma versão suportada continua sendo o caminho de manutenção mais claro. Fonte: projeto PHP.

O aviso oficial lista ajustes temporários que reduzem caminhos específicos de ataque. Ele é explícito sobre o limite deles: somente a atualização é uma correção completa. Por isso, não vale copiar uma mudança de configuração isolada, considerá-la definitiva e encerrar o incidente.

O que ainda não dá para concluir

A CERT-EU registrou a circulação inicial de provas de conceito, o que aumenta a urgência de corrigir. Mas a existência de uma prova de conceito não mede, sozinha, a escala de exploração em sistemas reais. Comunicados de fornecedores também refletem o que cada um observou em seu próprio ambiente e no momento da publicação.

O retrato pode mudar nas próximas horas ou dias. Antes de atribuir um site indisponível a essas falhas, é preciso consultar seu operador. Antes de afirmar vazamento ou invasão, é preciso evidência específica. E, antes de publicar uma nova orientação de resposta, é preciso reler os avisos técnicos e os pacotes do fornecedor.

O aprendizado que fica

O PHP não depende de um serviço central para funcionar. Ainda assim, uma falha no seu runtime pode exigir uma resposta coordenada em milhares de ambientes independentes. Em alguns deles, interromper o acesso por um período curto pode fazer parte dessa resposta.

Para quem desenvolve ou opera aplicações, a pergunta útil é menos “o PHP caiu?” e mais: sabemos onde nosso PHP está rodando, quem o atualiza, como trocar os processos em execução e como confirmar que a correção entrou em produção? Esse inventário e esse caminho de atualização fazem diferença quando um aviso crítico chega com pouco tempo para reagir.