PHP2Shell (CVE-2026-109618 e CVE-2026-109619): o que as empresas que usam PHP devem fazer agora

Um técnico com um portátil a trabalhar num bastidor de servidores

A 21 de outubro de 2026, o projeto PHP lançou o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir duas vulnerabilidades que «podem permitir a execução remota de código sem autenticação». Dito de forma simples: qualquer pessoa que consiga enviar um pedido HTTP ao seu site poderá conseguir executar código próprio no seu servidor. Não precisa de palavra-passe e, em algumas configurações, o ataque funciona antes de a sua aplicação ter executado uma única linha. O par recebeu o nome PHP2Shell, e o PHP atribui a ambas as falhas uma classificação de 9,2 (CVSS 4.0, numa escala de 10).

Este guia destina-se a quem tem de agir: proprietários de sites e lojas online em PHP, responsáveis de TI e todos os que têm um fornecedor a correr PHP por si. Foi escrito a 22 de outubro de 2026, no dia seguinte ao lançamento, a partir dos próprios avisos de segurança do projeto PHP, das orientações das agências nacionais de cibersegurança e dos números que os fornecedores publicaram. Quando as fontes divergem, dizemo-lo.

Em resumo

Atualize o próprio PHP e depois reinicie-o. Atualizar o WordPress, o Drupal, o Laravel ou um plugin não resolve isto. A falha está no PHP, por baixo da sua aplicação.
Todas as instalações de PHP que servem pedidos web estão abrangidas, segundo o PHP: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O PHP considera o Apache com mod_php o caso de maior risco.
Quase metade dos sites em PHP corre um ramo para o qual o projeto PHP já não lança versões (a nossa leitura dos dados da W3Techs, mais abaixo). Para esses, não há nenhum pacote oficial para instalar.
Definições e firewalls dão tempo, não segurança. O PHP enumera medidas provisórias e diz que «não tornam uma instalação segura».
Se não puder aplicar as correções hoje, as agências dos EUA, do Reino Unido e da UE dão o mesmo conselho: retirar o sistema da internet até ser possível.

O que aconteceu, por ordem

19 de agosto de 2026. Os investigadores da Wiz encontram a primeira das falhas, segundo a sua divulgação, e comunicam-nas à equipa de segurança do PHP a 24 de agosto. Os avisos do PHP creditam também investigadores de várias outras empresas.
20 de outubro. Os números CVE aparecem na internet, por fuga de informação, dois dias antes da divulgação prevista. O PHP antecipa o lançamento num dia, para 21 de outubro às 14:00 UTC, e pede a todos que se preparem.
21 de outubro, 03:02 UTC. A Cloudflare ativa regras de firewall para todos os clientes da sua WAF, incluindo os do plano gratuito. Mais tarde, relata ter «observado tráfego de ataque dirigido aos nossos clientes» e ter visto atacantes «a modificar o payload do ataque para tentar contornar as nossas proteções».
21 de outubro, por volta das 14:00 UTC. O PHP publica as correções e o seu aviso de segurança. No mesmo dia, a CISA nos EUA, o NCSC do Reino Unido, a CERT-EU e uma declaração conjunta da Comissão Europeia, da ENISA, da CERT-EU, da Europol e das CSIRT nacionais da UE pedem todos às organizações que apliquem as correções de imediato.

Qual é a gravidade?

Há três coisas que distinguem isto da habitual correção mensal.

O atacante só precisa de um pedido. Não é preciso iniciar sessão, e ninguém tem de clicar num link. O aviso do PHP descreve um exploit demonstrado contra o Apache com mod_php «em que um pedido não autenticado pode desencadear o ataque antes de ser executado qualquer código da aplicação». A Wiz demonstrou ataques a versões atuais do WordPress, do Drupal e do Joomla, e observa que «mesmo uma simples aplicação “Hello World” a correr numa versão afetada do PHP pode ser vulnerável». O código executado desta forma tem as permissões da conta do servidor web, que na maioria dos sites consegue ler a configuração da aplicação: a palavra-passe da base de dados, as chaves de API, as credenciais de email e de pagamento. Quanto à segunda falha, a CVE-2026-109619, o PHP confirma também a divulgação de memória: dados da memória do servidor a sair para o exterior, mesmo sem execução completa de código.

A base instalada é enorme. Segundo a W3Techs, o PHP corre em 69,3 % dos sites cuja linguagem de servidor é conhecida (números de 22 de outubro de 2026). A Unit 42, da Palo Alto Networks, conta mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis, a partir dos seus próprios varrimentos da internet, e relata que pelo menos um governo europeu retirou o seu site do ar por precaução.

O desenvolvimento de exploits está a avançar depressa. A CERT-EU relata que as primeiras provas de conceito «começaram a circular». A empresa de segurança watchTowr diz que os seus honeypots têm registado exploração desde 21 de outubro. A Cloudflare relata tráfego de ataque. E a Wiz diz que os seus investigadores usaram modelos de IA em todo o processo, de modo que um só investigador fez numa semana o que «teria levado meses a uma equipa de nível mundial». Os atacantes que adaptam um exploit à sua versão do PHP têm as mesmas ferramentas.

Convém ouvir também o outro lado: quando a CISA publicou o seu alerta, a 21 de outubro, não tinha observado exploração, e nenhuma das falhas constava ainda do seu catálogo Known Exploited Vulnerabilities (vulnerabilidades conhecidas e exploradas). A Red Hat classifica o problema como «importante» e não como crítico, porque um servidor Red Hat Enterprise Linux normal corre PHP-FPM, onde a exploração é mais difícil. Mais difícil não é impossível: o PHP confirma que um dos caminhos da segunda falha também funciona em PHP-FPM. Nada disto muda o que deve fazer. Muda apenas a antecedência com que será avisado.

Que versão usa? Os números

A W3Techs publica também as versões do PHP que os sites usam, contando os sites que revelam a sua versão. Juntando as suas duas tabelas de 22 de outubro de 2026:

Ramo do PHP	Percentagem dos sites em PHP	Correção do projeto PHP
8.3, 8.4, 8.5	cerca de 34 %	Sim: 8.3.36, 8.4.27, 8.5.12
8.2	cerca de 18 %	Sim: 8.2.35. Mas o próprio 8.2 chega ao fim de vida a 31 de dezembro de 2026
8.0, 8.1	cerca de 14 %	Nenhuma versão. 8.0 e 8.1: só backport no código-fonte
7.x	26,9 %	Nenhuma versão. 7.4: só backport no código-fonte; 7.3 e anteriores: nada
5.x e anteriores	7,8 %	Nada

Ou seja, cerca de 48 % dos sites em PHP correm um ramo para o qual o projeto PHP não publica nenhuma versão corrigida, e outros 18 % recebem agora a correção e perdem o suporte dentro de dez semanas.

Duas ressalvas. A W3Techs só vê os sites que mostram a sua versão. E uma distribuição Linux pode ter corrigido ela própria um ramo antigo: o Ubuntu fê-lo, como verá mais abaixo. O número da versão, por si só, não lhe diz se está protegido. A versão do pacote do seu fornecedor diz.

Passo 1: encontre todas as instalações de PHP

Não se pode corrigir o que não se inventariou, e o PHP esconde-se bem. O NCSC do Reino Unido pede às organizações que encontrem todos os sistemas PHP, a começar pelos expostos à internet, e acrescenta: «não limitem a descoberta às versões desatualizadas do PHP». A declaração conjunta da UE avisa que alguns produtos «podem ser afetados por estas vulnerabilidades mesmo que não pareçam usar PHP diretamente».

Onde procurar:

Sites e lojas: WordPress e WooCommerce, Drupal, Joomla, Magento e Adobe Commerce, Shopware, PrestaShop, TYPO3, e tudo o que for construído sobre Laravel ou Symfony.
Os esquecidos: microsites de campanhas, uma versão antiga noutra língua, servidores de staging e de testes acessíveis a partir da internet, o webmail ou o helpdesk que alguém instalou há anos.
Contentores: cada imagem construída a partir de uma imagem base php traz o seu próprio PHP. Atualizar o anfitrião não faz nada por ela.
Painéis de controlo de alojamento: o cPanel, o Plesk e painéis semelhantes trazem as suas próprias compilações do PHP ao lado das do sistema. Cada versão ativada no painel tem de ser atualizada à parte.
Produtos com PHP lá dentro: appliances, ferramentas de monitorização, CRM, helpdesks e interfaces de administração de fornecedores. O NCSC neerlandês mantém uma lista pública desses produtos com o respetivo estado, fornecedor a fornecedor.
Fornecedores: a sua empresa de alojamento, a sua agência, qualquer serviço que saiba ter PHP por baixo. Pergunte-lhes por escrito que versões de PHP correm nos seus sistemas e quando vão ser corrigidas.

Para cada um, anote a versão do PHP, a forma como o PHP corre (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, um contentor), se está acessível a partir da internet e quem tem capacidade para aplicar a correção.

Passo 2: aplique as correções pela ordem certa

Comece pelo que estiver acessível a partir da internet e, dentro disso, pelas instalações com Apache e mod_php.

Num ramo suportado (8.2 a 8.5). Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou para o pacote da sua distribuição que contém a correção. O PHP diz que as distribuições Linux receberam as correções antecipadamente. Confirmado até agora:

Ubuntu: pacotes corrigidos para todas as versões, da 14.04 à 26.10. Na 22.04 e posteriores, chegam com as atualizações normais; na 20.04 e anteriores, exigem uma subscrição Ubuntu Pro, que é gratuita para até cinco máquinas (aviso da Canonical).
Debian: php8.4 8.4.27 para o Debian 13 (DSA-6574-1) e php8.2 8.2.35 para o Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: o boletim de segurança RHSB-2026-013 da Red Hat lista os pacotes por versão.
O repositório Remi, muito usado para versões mais recentes do PHP em sistemas da família Red Hat: a 21 de outubro, a CERT-EU notou que não tinha pacotes no dia do lançamento e aconselhou a mudar para os pacotes da distribuição ou a compilar a partir do código-fonte. Verifique se já recuperou o atraso antes de confiar nele.

No PHP 7.4, 8.0 ou 8.1. O projeto PHP não publica nenhuma versão para estes ramos. A sua equipa de segurança fez backports mínimos no código-fonte para os três ramos, que ajudam se compilar o PHP por conta própria. Caso contrário, a correção tem de vir do seu fornecedor (o Ubuntu Pro cobre o PHP 7.4 no Ubuntu 20.04, por exemplo) ou da passagem para uma versão mais recente do PHP. O conselho da CISA para quem está no 8.1 ou anterior e não pode atualizar é taxativo: pôr o sistema offline até estar corrigido ou migrado para uma versão mais recente.

No PHP 7.3 ou anterior. Do projeto PHP não vem nada. A não ser que um fornecedor ainda corrija a sua compilação, a escolha é entre passar para uma versão mais recente e pôr o sistema offline.

Reinicie depois de atualizar. Instalar um pacote não substitui o PHP que já está a correr. O aviso do Ubuntu di-lo sem rodeios: a aplicação «provavelmente terá de ser reiniciada». Reinicie o PHP-FPM, o Apache, o LiteSpeed ou o contentor em todos os servidores. Depois verifique a versão que o servidor web corre de facto, e não só o php -v na linha de comandos, que pode ser outra compilação.

Contentores: reconstrua as imagens a partir de uma imagem base corrigida e faça novo deploy. Um anfitrião corrigido a correr uma imagem antiga continua exposto.

Alojamento gerido: peça ao seu fornecedor a data e a versão, e depois confirme por si.

Passo 3: se não puder aplicar as correções hoje

O aviso do PHP enumera medidas provisórias e apresenta-as com um alerta: «reduzem a exposição a caminhos de ataque específicos, mas não tornam uma instalação segura». Em resumo, para quem gere os seus servidores:

Para a CVE-2026-109618: defina memory_limit=-1 de forma que a aplicação não o consiga sobrepor (por exemplo, com php_admin_value no pool do PHP-FPM ou na configuração do Apache); defina um post_max_size baixo (o PHP sugere 8M sem upload de ficheiros e 32M com upload); limite o tamanho dos pedidos, o número de campos e as partes multipart no servidor web ou no proxy; e use um limite de memória do contentor ou do cgroup, nunca RLIMIT_AS nem RLIMIT_DATA.
Para a CVE-2026-109619: defina session.upload_progress.enabled=0 no php.ini ou na configuração do servidor (não com ini_set() nem com um ficheiro .user.ini) e reinicie todos os workers. No PHP 8.5, defina também fatal_error_backtraces=0.

Dois avisos. A definição de sessão que circulou amplamente a 20 de outubro só fecha caminhos da segunda falha, como assinalou um membro da equipa de segurança do PHP; contra a primeira, não faz nada. E memory_limit=-1 retira o limite de memória do próprio PHP, pelo que um único pedido pesado pode passar a esgotar o servidor. Combine-o com o limite do contentor ou do cgroup.

Uma firewall de aplicações web ajuda, mas pouco. As regras da Cloudflare estão ativas por omissão em todos os planos com a sua WAF, incluindo o gratuito, e a Palo Alto Networks e outros fornecedores publicaram as suas próprias proteções. A Cloudflare continua a dizer aos clientes que corrijam o PHP «mesmo com proteções de WAF», e viu atacantes alterar os payloads para passar pelas suas regras. Uma WAF também só protege o tráfego que passa por ela. Se o seu servidor responder no seu próprio endereço IP, um atacante pode contorná-la.

Se nada disto puder ser feito depressa, a CISA, a CERT-EU, o NCSC e a declaração conjunta da UE apontam todos no mesmo sentido: retirar o sistema da internet pública até estar corrigido. Uma página de manutenção durante um dia custa menos do que um servidor reconstruído.

Passo 4: verifique se já foi atacado

A janela abriu-se a 20 de outubro, quando começou a fuga de informação, e foi relatado tráfego de ataque logo na manhã seguinte. Se um sistema esteve acessível e sem correções nessa janela, aplicar a correção fecha a porta, mas não lhe diz se alguém entrou antes. O NCSC pede a quem não conseguiu aplicar as correções de imediato que procure sinais de comprometimento e backdoors.

O que procurar, segundo as orientações publicadas e a prática habitual de resposta a incidentes:

Processos PHP a fazer coisas que o PHP nunca faz, como abrir uma shell ou descarregar ferramentas (CISA).
Pedidos multipart invulgares seguidos de erros de limite de memória ou de respostas HTTP 500 repetidas, workers do PHP a reiniciar sem razão clara e cookies PHPSESSID invulgarmente grandes ou malformados nas respostas (Wiz).
Ficheiros PHP novos ou alterados em pastas de upload, pastas de cache ou na raiz web, novas contas de administrador no seu CMS e tarefas agendadas que ninguém criou.

Registos limpos não são prova. O aviso do PHP para a segunda falha alerta precisamente para isso, e a Wiz observa que os registos da aplicação podem conter pouco contexto.

Se encontrar alguma coisa, trate-a como um incidente, não como uma tarefa de correção. Isole o servidor, preserve as provas, chame um fornecedor de resposta a incidentes e altere todos os segredos que o servidor web pudesse ler: palavras-passe de bases de dados, chaves de API, credenciais de pagamento e de email, chaves de assinatura. Como a segunda falha pode divulgar memória, pondere fazer a rotação dos mais sensíveis desses segredos em qualquer servidor que tenha estado exposto e sem correções durante dias, mesmo sem sinais de intrusão.

Passo 5: o que pode ter de notificar

Uma vulnerabilidade, por si só, não é um incidente de notificação obrigatória. Uma vulnerabilidade explorada pode ser.

NIS 2: se a sua organização estiver abrangida e um comprometimento constituir um incidente significativo, o alerta precoce à sua CSIRT nacional tem de ser enviado no prazo de 24 horas. Consulte o nosso guia da Diretiva NIS 2.
RGPD: se houve acesso a dados pessoais, a autoridade de controlo tem de ser notificada no prazo de 72 horas a contar do momento em que teve conhecimento da violação, a menos que esta não seja suscetível de pôr as pessoas em risco. Consulte o nosso guia do RGPD.
Regulamento de Ciber-Resiliência: se vende software ou um dispositivo com PHP lá dentro, é o fabricante desse produto nos termos do CRA. Desde 11 de setembro de 2026, os fabricantes têm de notificar as vulnerabilidades ativamente exploradas nos seus produtos através da plataforma única de notificação do CRA (CRA Single Reporting Platform), como recorda a declaração conjunta da UE. Consulte o nosso guia do CRA.
Os seus clientes: se aloja ou opera PHP para clientes, eles vão perguntar. Uma nota escrita curta (o que usa, quando foi corrigido, o que verificou) responde à maior parte das perguntas, e é a mesma nota que um auditor ou uma seguradora de ciber-risco vai querer ver.

Depois da emergência: o que mudar

Na maioria dos servidores bem geridos, o PHP2Shell vai estar corrigido em poucos dias. O que revelou sobre o seu ambiente vai continuar a ser verdade depois disso.

Saiba quanto tempo demora a aplicar uma correção. Desde o aviso de segurança até todos os servidores reiniciados: horas, dias ou semanas? Se a resposta honesta for «teríamos de perguntar à agência», resolva isso antes da próxima vez. Quando os investigadores dizem que a IA reduziu o seu trabalho de desenvolvimento do exploit de meses para uma semana, parta do princípio de que os atacantes também conseguem avançar a esse ritmo.
Mantenha o inventário que acabou de construir. Foi a parte mais difícil da resposta, e fica desatualizado no momento em que deixa de ter dono.
Abandone as versões do PHP em fim de vida. Um site em 7.4 ou 8.1 precisou desta vez de um fornecedor ou de um backport no código-fonte; da próxima vez pode não haver nem uma coisa nem outra. O PHP 8.2 chega ao fim de vida a 31 de dezembro de 2026, por isso um site que sai do 8.1 deve passar diretamente para o 8.3 ou posterior. Mudar de versão do PHP obriga muitas vezes a atualizar também a aplicação: o nosso artigo sobre o fim de vida do Drupal, do Umbraco e do Kentico mostra o que isso implica num CMS.
Prefira o PHP-FPM ao mod_php onde puder. Desta vez, foi a configuração de menor risco.
Deixe o progresso de upload desligado se não o usa. O aviso do PHP sugere manter session.upload_progress.enabled desligado mesmo depois de aplicar as correções, quando a aplicação não precisa dele.
Ponha prazos de correção nos seus contratos. Pergunte à sua empresa de alojamento e à sua agência com que rapidez aplicam correções críticas do PHP, e obtenha a resposta por escrito.

Lista de verificação para esta semana

Inventariar todas as instalações de PHP, incluindo contentores, painéis de controlo, produtos de fornecedores e servidores de staging.
Corrigir primeiro os sistemas expostos à internet, a começar pelo Apache com mod_php.
Reiniciar todos os processos PHP e verificar a versão que o servidor web indica.
Reconstruir as imagens de contentor e fazer novo deploy.
Onde não for possível corrigir hoje, aplicar as definições provisórias do PHP, encaminhar o tráfego através de uma WAF ou pôr o sistema offline.
Pedir por escrito aos fornecedores e às empresas de alojamento a sua versão do PHP e a data da correção.
Rever os registos e as alterações de ficheiros em tudo o que esteve exposto e sem correções desde 20 de outubro.
Decidir se se aplica alguma obrigação de notificação (NIS 2, RGPD, CRA).
Planear a saída do PHP 8.1 e anteriores, e do 8.2 antes de 31 de dezembro.

Onde podemos ajudar

À maior parte das empresas não falta vontade de aplicar as correções. O que lhes falta é uma ideia clara do que têm a correr, ou pessoas para fazer o trabalho esta semana. É dessa parte que tratamos:

Inventário e correções, em dias. Encontramos as suas instalações de PHP em servidores, contentores, painéis de alojamento e fornecedores, aplicamos as correções, reiniciamos e verificamos, e deixamos-lhe um registo escrito do que foi feito e quando. Esse registo é também a sua resposta a clientes e auditores.
Sair do PHP antigo. Aplicações presas ao PHP 7.x, 8.0 ou 8.1 porque o código não corre em nada mais recente: portamo-las para uma versão suportada no âmbito do nosso serviço de manutenção de sistemas legados.
Reforço da segurança e uma rotina de correções, para que o próximo aviso de segurança seja um trabalho agendado e não uma emergência.

Se encontrar sinais de intrusão, contacte primeiro um fornecedor de resposta a incidentes. Podemos tratar da reconstrução e da migração de versão em paralelo com eles.

Escreva para office@c9group.dev a dizer o que usa, e respondemos com o que faríamos primeiro.

Fontes

Verificadas a 22 de outubro de 2026. A situação continua a evoluir: em particular, o estado da exploração e os pacotes dos fornecedores podem ter mudado entretanto.

Projeto PHP

Agências

Investigadores, fornecedores e dados