Em resumo: Uma semana depois da primeira tentativa de ataque observada, o PHP2Shell é atualmente sobretudo uma questão de execução: os patches para o PHP 8.2 a 8.5 existem desde 21 de outubro, as grandes distribuições acompanharam, o BSI alerta com o nível laranja. Foram observadas tentativas de ataque; ataques bem-sucedidos em larga escala confirmados não foram inicialmente comunicados pelo BSI. Continuam em aberto as versões antigas, os servidores não reiniciados e a questão do que aconteceu antes do patch.
A situação em três frases
O PHP2Shell são duas vulnerabilidades críticas no próprio interpretador PHP, CVE-2026-109618 e CVE-2026-109619, cada uma classificada com CVSS v4.0 9,2. Permitem a execução de código à distância sem autenticação, ou seja, o caso que os profissionais de segurança mais temem. Estão afetados o PHP-FPM, o Apache com mod_php, o php-cgi, o FrankenPHP e o LiteSpeed; o risco mais elevado é visto pela equipa do PHP no mod_php.
Este resumo organiza o estado a 25 de outubro de 2026 por intervenientes. A sequência dia a dia encontra-se na cronologia do PHP2Shell; aqui trata-se do quadro geral.
O que está comprovado após uma semana
Estão assegurados os dados do projeto PHP: as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, de 21 de outubro, fecham ambas as vulnerabilidades. Para o PHP 7.4, 8.0 e 8.1 existem apenas backports mínimos do código-fonte, sem lançamentos oficiais. O php.net salienta que não há medidas provisórias completas e que a atualização é o único caminho seguro.
A 23 de outubro juntou-se um aviso sobre a CVE-2026-115560. Diz respeito apenas a uma configuração de sessão invulgar; como atenuação, o php.net indica session.upload_progress.enabled=0 até à próxima versão regular de correção de erros.
Também as grandes distribuições tomaram posição. Verificámos os comunicados oficiais:
| Fornecedor | Estado segundo o comunicado oficial |
|---|---|
| Ubuntu | USN-8948-1 para 22.04, 24.04, 26.04 e 26.10; USN-8948-2 para 14.04 a 20.04 através do Ubuntu Pro |
| Debian | Pacotes corrigidos para bookworm (php8.2, DLA-4848-1) e trixie (php8.4, DSA-6574-1) |
| Red Hat | Boletim RHSB-2026-013 para RHEL 7 a 10; algumas atualizações disponíveis, outras em curso |
A Red Hat classifica a CVE-2026-109618 com uma classificação própria de “Important” e justifica-o com maior complexidade do ataque. É um método de avaliação diferente do do projeto PHP e não é motivo para adiar a atualização.
Como as autoridades avaliam a situação
O BSI declarou o nível de alerta 3 / laranja. Recomenda a atualização imediata e, se isso não for possível de imediato, retirar temporariamente da rede os servidores web afetados. O BSI contava com uma exploração rápida e em larga escala. O que significa a classificação é explicado na página O que o BSI recomenda sobre o PHP2Shell.
Segundo notícias, o CERT-EU considera possível que estejam afetadas versões a partir do PHP 5 e aconselha isolar as aplicações acessíveis ao público se não puderem receber o patch em tempo útil. O CERT-Bund (a equipa de resposta a incidentes do governo alemão) e a empresa de segurança Huntress também alertaram.
A recomendação de, em caso de necessidade, desligar foi aplicada de forma visível. Segundo notícias dos media, a cidade de Mogúncia retirou por precaução o seu portal web central da rede; os serviços municipais continuaram contactáveis por telefone e e-mail. No Hessen estiveram, segundo a hessenschau, temporariamente offline páginas do governo regional, do BKA (o Gabinete Federal de Polícia Criminal alemão) e das cidades de Kassel e Wiesbaden. A chancelaria não comunicou qualquer ataque e as páginas voltaram a estar acessíveis ao fim da tarde. Outros municípios, universidades e hospitais agiram, segundo notícias, de forma semelhante.
O que se sabe sobre ataques
Aqui, a separação entre observação e confirmação é particularmente importante.
- Observado: Segundo notícias dos media, houve a 17 de outubro uma primeira tentativa de ataque, observada pela Amazon. A Cloudflare e a Patchstack reportaram tentativas de ataque; a Cloudflare viu ainda padrões de ataque alterados.
- Reproduzido: A watchTowr reproduziu, segundo notícias, a CVE-2026-109618, de acordo com as suas próprias declarações.
- Não confirmado: O BSI não comunicou inicialmente explorações bem-sucedidas em larga escala confirmadas. A Huntress não viu ataques em ambientes de parceiros à data do seu comunicado.
- Desconhecido: Não há Indicators of Compromise confirmados e publicados. Quem quiser verificar se um servidor foi afetado tem de estar atento a padrões de comportamento.
Sobre a dimensão circulam dois números. Os investigadores da Unit 42, da Palo Alto Networks, chegaram a mais de 22,6 milhões de instâncias potencialmente vulneráveis acessíveis a partir da rede. A CybelAngel indica cerca de 2,24 milhões de hosts PHP acessíveis, dos quais, segundo a sua própria análise, 59 por cento em versões sem futura correção oficial. Ambos medem coisas diferentes e não são diretamente comparáveis. Um enquadramento é fornecido pelo artigo Interpretar corretamente os números.
O que continua em aberto
Três perguntas determinam as próximas semanas:
- Versões antigas: Uma grande parte das instalações PHP acessíveis corre, segundo as análises referidas, em ramos sem correção oficial. Se as ofertas comerciais de suporte de longo prazo cobrem o PHP2Shell tem de ser confirmado por escrito junto de cada fornecedor.
- Atualizações incompletas: Os novos pacotes só produzem efeito quando todos os processos PHP foram reiniciados. A Red Hat chama expressamente a atenção para o facto de um simples recarregamento não bastar.
- O tempo antes do patch: Entre 17 e 21 de outubro, os servidores estavam vulneráveis enquanto já decorriam tentativas de ataque. Um patch não prova que nada tenha acontecido nesse período.
Guarde os registos do servidor web e do PHP desde 20 de outubro, como recomenda a imprensa especializada. Sem registos, a mais importante pergunta em aberto para o seu servidor não poderá ser respondida mais tarde.
O que os operadores devem verificar agora
Para a sua própria avaliação da situação bastam quatro pontos de verificação por servidor: o PHP está numa versão corrigida ou num backport confirmado? Todos os processos estão a correr desde a atualização? O session.upload_progress.enabled está desativado no servidor enquanto o aviso sobre a CVE-2026-115560 estiver pendente? Há anomalias desde 17 de outubro?
Para o último ponto, ajuda a página Será que já fui comprometido?. Um processo do servidor web que inicia uma shell, novos ficheiros PHP em pastas de uploads, tarefas cron ou chaves SSH desconhecidas são sinais de alerta que justificam uma investigação mais exata.
Como ajuda concretamente a PHP SOS?
- Avaliamos o nível de patch de cada servidor com base no estado dos pacotes, no registo de alterações e nas horas de arranque dos processos.
- Onde não há patch disponível, aplicamos as medidas provisórias do php.net e esclarecemos o caminho para a versão suportada.
- Guardamos registos desde 20 de outubro e procuramos vestígios do período anterior ao patch.
- Com a ajuda imediata PHP2Shell, reunimos estes passos para empresas que precisam de clareza depressa.
Perguntas frequentes
O PHP2Shell já está a ser explorado ativamente?
A Cloudflare e a Patchstack reportaram tentativas de ataque. Ataques bem-sucedidos em larga escala confirmados não foram inicialmente comunicados pelo BSI (Gabinete Federal Alemão para a Segurança da Informação). A Huntress não viu ataques em ambientes de parceiros à data do seu comunicado.
O perigo passou depois dos patches?
Não. Os patches só protegem os servidores que os instalaram e reiniciaram todos os processos PHP. Os sistemas com PHP 8.1 e anterior continuam vulneráveis sem backport confirmado, e um patch não remove software malicioso introduzido antes.
Porque estiveram offline os sites de autoridades?
Segundo notícias dos media, entre outras a cidade de Mogúncia (Mainz) e vários organismos do Hessen desligaram os seus sites por precaução. Isto corresponde à recomendação do BSI para servidores que não podem ser atualizados de imediato. Um desligamento não significa que tenha havido um ataque.
Existem indicadores para reconhecer um ataque PHP2Shell?
Até agora não existem Indicators of Compromise confirmados e publicados. A deteção baseia-se na análise de comportamento, por exemplo em processos PHP que iniciam uma shell ou em novos ficheiros PHP em pastas de uploads.