Cibersegurança
PHP2Shell: as falhas críticas no PHP e porque deve atualizar já
Duas falhas no próprio motor do PHP permitem tomar conta de um servidor web sem palavra-passe. Explicamos como funcionam, o seu impacto mundial e os perigos de adiar a atualização, mesmo por poucos dias.
A 21 de outubro de 2026, a equipa de segurança do PHP publicou atualizações de emergência para duas falhas críticas, registadas como CVE-2026-109618 e CVE-2026-109619 e conhecidas como PHP2Shell. Juntas, permitem que um atacante execute o seu próprio código num servidor web sem precisar de qualquer palavra-passe. Como o PHP está por detrás de cerca de sete em cada dez sites, esta é uma das vulnerabilidades mais sérias dos últimos anos.
Neste artigo explicamos como funcionam estas falhas, qual o seu impacto à escala mundial e porque é que adiar a atualização, mesmo por poucos dias, é um risco que nenhuma organização deve correr. A informação reflete o que era público a 23 de outubro de 2026.
O que é o PHP e porque é que isto importa
O PHP é a linguagem de programação que gera, no servidor, as páginas de uma grande parte da Internet: portais institucionais, lojas online, blogues, plataformas de gestão e muitas aplicações internas. Sistemas de gestão de conteúdos muito populares, como o WordPress, o Drupal ou o Joomla, assentam nele.
A particularidade destas falhas é que não estão numa aplicação ou num plugin, mas no próprio motor do PHP. Por isso, atualizar o site, o tema ou a plataforma não resolve o problema: é preciso atualizar o PHP instalado no servidor e reiniciar todos os processos que o executam.
Como funcionam as falhas
Para responder rapidamente, um servidor PHP mantém um conjunto de processos de trabalho (workers) que atendem pedidos uns atrás dos outros. No fim de cada pedido, o processo arruma a memória que usou e fica pronto para o seguinte. As duas falhas exploram momentos em que essa arrumação corre mal.
CVE-2026-109618: memória esgotada a meio do caminho
Quando uma operação fica sem memória, o PHP interrompe o pedido de forma abrupta. Se isso acontecer enquanto os dados internos do pedido ainda estão a ser preparados, ficam estruturas incompletas que a limpeza final trata como se fossem válidas. Um atacante consegue provocar esta situação com um envio de formulário ou de ficheiros especialmente preparado, mesmo dentro dos limites de tamanho configurados.
O risco é maior nos servidores Apache com o módulo mod_php: aí, a falha pode ser explorada antes de a aplicação executar uma única linha de código, ou seja, não importa quão bem escrito esteja o site.
CVE-2026-109619: restos de um pedido anterior
A segunda falha resulta de informação interna que sobrevive de um pedido para o seguinte, apontando para memória que já foi libertada. Um pedido posterior, tratado pelo mesmo processo, pode ler esses restos antes de serem limpos. Um dos caminhos confirmados passa pela funcionalidade de acompanhamento do progresso de envio de ficheiros (session upload progress), que vem ativa por omissão e não exige que a aplicação use sessões.
Em linguagem técnica, ambas são falhas do tipo use after free (CWE-416), com uma pontuação de 9,2 em 10 na escala CVSS 4.0. Estão afetadas todas as formas de servir PHP na web, incluindo PHP-FPM, mod_php, php-cgi, FrankenPHP e LiteSpeed.
Uma cronologia acelerada
As falhas foram descobertas em agosto por duas equipas de investigação independentes, ambas com apoio de ferramentas de inteligência artificial, e comunicadas de forma coordenada à equipa do PHP. O plano era divulgá-las a 22 de outubro, com as correções já disponíveis. Não correu assim.
17 de outubro: segundo a Amazon, surgem as primeiras tentativas de exploração, quatro dias antes das correções.
20 de outubro: os detalhes técnicos chegam ao público antes do previsto e circula uma ferramenta de ataque com o nome PHP2Shell. O PHP anuncia uma atualização de emergência para o dia seguinte.
21 de outubro: são publicadas as versões corrigidas. A Cloudflare relata dezenas de milhares de tentativas de ataque nos primeiros 45 minutos, centenas de milhares em duas horas e milhões ao fim do dia.
23 de outubro: o PHP anuncia uma terceira falha, mais limitada (CVE-2026-115560), relacionada com a mesma funcionalidade de progresso de envio, que será corrigida na próxima versão.
Há ainda informação contraditória. À data da publicação das correções, a PHP Foundation não tinha identificado nenhum ataque funcional, e os investigadores que testaram as provas de conceito públicas concluíram que cada uma só funciona numa combinação específica de sistema, versão e servidor. Mas basta que alguém crie uma técnica mais genérica, e muitos estão a tentar, para que o risco se multiplique de um dia para o outro.
Um impacto à escala mundial
Os números dão a dimensão do problema:
Segundo a W3Techs, o PHP é usado por 69,3% dos sites cuja linguagem de servidor é conhecida. Cerca de um terço desses sites ainda usa PHP 7 ou PHP 5, versões que já não recebem atualizações oficiais.
A Censys contava, a 22 de outubro, mais de 3 milhões de servidores e cerca de 56 milhões de propriedades web com PHP visíveis na Internet, sobretudo nos Estados Unidos, na Alemanha e na China.
No dia das correções, dos cerca de 1,58 milhões de servidores que revelavam a versão do PHP, aproximadamente 1,57 milhões continuavam por atualizar.
Estes valores devem ser lidos com cautela. As distribuições Linux corrigem muitas vezes o PHP sem mudar o número da versão, por isso um servidor que parece vulnerável pode já estar protegido, e o contrário também acontece. Ainda assim, mesmo com uma margem de erro grande, falamos de milhões de sistemas em todo o mundo, incluindo em Portugal.
Os perigos de não atualizar já
Uma vulnerabilidade como esta não é um problema teórico que se possa agendar para o próximo trimestre. Quem adia a atualização corre riscos concretos:
Controlo total do servidor: o atacante executa código com as permissões do servidor web e pode ler ficheiros de configuração, palavras-passe de bases de dados e chaves de acesso a outros serviços.
Roubo de dados pessoais: dados de clientes, utentes ou cidadãos podem ser copiados, com obrigações de notificação ao abrigo do RGPD e danos reputacionais difíceis de reparar.
Portas traseiras que ficam: um atacante que entra hoje pode deixar ficheiros escondidos (web shells), tarefas agendadas ou contas novas que sobrevivem à atualização feita amanhã.
Ransomware e indisponibilidade: o servidor comprometido pode servir de ponto de entrada para cifrar sistemas internos ou para os tornar indisponíveis.
Uso para atacar terceiros: servidores comprometidos são usados para enviar phishing, minerar criptomoedas ou atacar outras organizações, com o seu endereço e o seu nome associados.
Obrigações legais: as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2) têm de gerir vulnerabilidades conhecidas e notificar incidentes significativos ao Centro Nacional de Cibersegurança.
Quando os detalhes de uma falha crítica se tornam públicos, a janela entre a correção e o ataque deixa de se medir em semanas. Neste caso, mediu-se em minutos.
Os ataques automáticos não escolhem vítimas pela dimensão ou pela notoriedade: percorrem a Internet inteira à procura de qualquer servidor vulnerável. Um pequeno site institucional esquecido num servidor antigo é um alvo tão bom como uma grande plataforma.
O que fazer agora
Faça o inventário. Identifique todos os servidores, contentores e serviços de alojamento que executam PHP, incluindo sites antigos, ambientes de testes e aplicações internas.
Atualize o PHP para uma versão corrigida (ver tabela) e reinicie todos os processos de PHP. Num alojamento partilhado ou gerido, confirme com o fornecedor que a atualização foi aplicada.
Confirme a versão em execução, e não apenas a versão instalada: um processo que não foi reiniciado continua vulnerável.
Procure sinais de intrusão, sobretudo nos servidores que estiveram expostos desde 17 de outubro: ficheiros PHP novos ou alterados, tarefas agendadas desconhecidas, contas novas e ligações de saída invulgares.
Planeie a saída das versões sem suporte. O PHP 8.1 e anteriores já não recebem correções oficiais, e o PHP 8.2 deixa de as receber a 31 de dezembro de 2026.
| Versão do PHP | Versão corrigida | Observações |
|---|---|---|
| 8.5 | 8.5.12 | Suporte ativo |
| 8.4 | 8.4.27 | Suporte ativo |
| 8.3 | 8.3.36 | Apenas correções de segurança |
| 8.2 | 8.2.35 | Fim das correções a 31 de dezembro de 2026 |
| 8.1, 8.0 e 7.4 | Sem versão oficial | Há correções mínimas em código-fonte e pacotes de distribuições ou de fornecedores de suporte alargado |
| 7.3 e anteriores | Sem correção | Migrar para uma versão suportada |
E se não for possível atualizar hoje?
A equipa do PHP indica medidas que reduzem a exposição enquanto a atualização é preparada, mas é clara: nenhuma delas torna a instalação segura. A mais simples é desativar o progresso de envio de ficheiros na configuração do servidor, e não na aplicação, reiniciando depois todos os processos:
session.upload_progress.enabled = 0Limitar o tamanho dos pedidos aceites (por exemplo, post_max_size de 8 MB quando não há envio de ficheiros) e bloquear, à entrada, pedidos de formulário com ficheiros em sites que não os usam também ajuda. Estas medidas compram tempo, não substituem a atualização.
A manutenção também é segurança
O PHP2Shell lembra uma regra antiga: um sistema de informação não fica concluído no dia em que entra em produção. Precisa de inventário, de atualizações regulares, de monitorização e de alguém que responda depressa quando surge uma falha crítica, incluindo nos sites e aplicações mais antigos, que ninguém se lembra de que ainda estão ligados.
Na Datapoint, a manutenção e o suporte dos sistemas que desenvolvemos incluem o acompanhamento destes alertas e a aplicação planeada das correções de segurança. Se tem sistemas em PHP e não sabe se estão protegidos, fale connosco.