Em resumo: o PHP2Shell são duas vulnerabilidades críticas no próprio PHP, através das quais os atacantes podem executar código malicioso sem autenticação. Se precisa de ajuda rápida com esta vulnerabilidade do PHP, assumimos remotamente o levantamento, a aplicação do patch ou de uma medida provisória, o reinício de todos os processos PHP e uma primeira busca de vestígios. No fim, recebe um comprovativo escrito do estado.
Ajuda com a vulnerabilidade do PHP: porque é preciso agir já
A 21/10/2026, às 16 horas (hora alemã), o projeto PHP publicou patches para a CVE-2026-109618 e a CVE-2026-109619. Ambas as vulnerabilidades têm CVSS v4.0 de 9,2 e permitem a execução remota de código malicioso, sem que alguém tenha de se autenticar. Estão afetados os modos de operação habituais: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
O BSI emitiu o nível de alerta 3 (laranja). Recomenda a atualização imediata e, se esta não for possível de imediato, desligar temporariamente os servidores web da rede. A Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. Segundo o BSI, não eram inicialmente conhecidos ataques bem-sucedidos em larga escala, mas a Cloudflare já tinha comunicado tentativas de ataque.
Para a administração e os proprietários, isto significa: todo o servidor PHP acessível publicamente é candidato, até prova em contrário. Uma explicação clara da vulnerabilidade encontra-a em O que é o PHP2Shell?.
Para quem se destina a ajuda imediata PHP2Shell?
Para empresas, agências e entidades públicas que operam aplicações PHP e que não conseguem, ou não querem, tratar sozinhas a situação com a profundidade necessária. Isto aplica-se tanto a servidores root e vServers próprios como a servidores com Plesk ou cPanel, a ambientes de contentores e a servidores geridos em que a responsabilidade não está clara.
Mesmo quem tem um fornecedor de alojamento precisa muitas vezes de apoio. Muitos fornecedores aplicam backports; então, o Plesk, por exemplo, continua a mostrar 8.2.34, embora o estado do pacote tenha o patch aplicado. Inversamente, pode ser apresentado um número de versão novo enquanto processos PHP antigos ainda correm na memória. Os níveis considerados corrigidos constam de Que versões do PHP estão afetadas?.
Como ajuda concretamente a PHP SOS?
- Levantamento: registamos todas as instalações PHP, modos de operação e versões nos seus servidores, incluindo o estado do pacote e os processos em execução. O resultado é uma lista de quais sistemas estão afetados, corrigidos ou pouco claros.
- Patch ou medida provisória: sempre que possível, instalamos as versões corrigidas (8.5.12, 8.4.27, 8.3.36, 8.2.35) ou os pacotes da sua distribuição. Se isso não for possível de imediato, aplicamos as medidas provisórias segundo o php.net e dizemos abertamente que não oferecem proteção completa.
- Reinício e controlo: reiniciamos todos os workers e processos PHP e verificamos depois que já não corre nenhum processo antigo. Ficheiros novos, só por si, não fecham a vulnerabilidade.
- Primeira busca de vestígios: guardamos os registos do servidor desde 20/10 e procuramos anomalias, como ficheiros PHP novos, cronjobs desconhecidos ou processos invulgares. Como não existem indicadores de compromisso (IOCs) confirmados e publicados, esta verificação assenta na análise de comportamento.
- Comprovativo e passos seguintes: recebe um relatório escrito. Em caso de suspeita de comprometimento, recomendamos os passos seguintes adequados, por exemplo a remoção de malware ou uma investigação forense.
Um patch não remove software malicioso já introduzido e não prova que antes nada aconteceu. Por isso, a ajuda imediata inclui sempre um olhar sobre o período desde 17/10/2026.
O que recebe de nós
- uma visão geral de todos os servidores verificados, com versão do PHP, estado do pacote, modo de operação e estado do patch
- a documentação das atualizações instaladas ou das medidas provisórias aplicadas
- o comprovativo de que todos os processos PHP foram reiniciados
- uma avaliação da busca de vestígios, separada em comprovado, provável e desconhecido
- uma lista de pontos em aberto, por exemplo sistemas com PHP 8.1 ou anterior
Pode entregar este relatório à administração, ao encarregado da proteção de dados ou à seguradora. Não substitui a avaliação jurídica.
O que precisamos de si
- Acesso: acesso por SSH ou ao painel com direitos suficientes ou, em alternativa, uma autorização para o seu fornecedor de alojamento nos prestar informações
- Interlocutor: uma pessoa com poder de decisão, por exemplo sobre um curto período offline ou um reinício
- Visão geral: que sites, lojas e aplicações correm em que servidores
- Janela de manutenção: as suas indicações sobre quando os reinícios são permitidos
- Cópias de segurança: informação sobre onde estão as cópias de segurança atuais
Para os administradores que queiram verificar primeiro por si, basta muitas vezes esta consulta inofensiva ao estado:
php -v
# Debian/Ubuntu: pacotes PHP instalados, com versão
dpkg -l | grep -i php
# processos PHP em execução e a respetiva hora de arranque
ps -eo pid,lstart,cmd | grep -i php
O que não prometemos
Não prometemos segurança absoluta nem a afirmação de que o seu servidor nunca foi atacado, se as provas não o permitirem. Trabalhamos no incidente até estar concluído e documentado. Se existe obrigação de notificação nos termos do RGPD ou se a sua seguradora tem de ser informada, esclareça-o com o encarregado da proteção de dados, um advogado ou a seguradora. Nós fornecemos os factos técnicos para isso.
Se só precisa da atualização com comprovativo, adequa-se o nosso serviço de patches PHP. Se já existem sinais de um ataque, o ponto de partida certo é a assistência de emergência para sites comprometidos.
Perguntas frequentes
Basta o meu fornecedor de alojamento ter atualizado o PHP?
Pode bastar, se o fornecedor confirmar por escrito o estado do pacote e todos os processos PHP tiverem sido reiniciados. O número de versão apresentado, por si só, não é prova, porque as distribuições aplicam backports. Se o servidor já tinha sido atacado antes, um patch não o esclarece, de qualquer modo.
O meu site tem de ficar offline para a ajuda imediata?
Não necessariamente. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda desligar temporariamente os servidores web da rede quando a atualização não for possível de imediato. Se isso é necessário no seu caso, decidimos em conjunto depois do levantamento.
Uma atualização do WordPress ou do Shopware protege contra o PHP2Shell?
Não. O PHP2Shell está no próprio PHP, não no CMS. Uma atualização do CMS continua a fazer sentido, mas não corrige esta vulnerabilidade.
O que acontece com o PHP 8.1 ou anterior?
Para estas versões já não existem atualizações oficiais do projeto PHP, apenas backports mínimos do código-fonte para 7.4, 8.0 e 8.1. Protegemos o servidor a título provisório e planeamos consigo a mudança para uma versão suportada.