Em resumo: quem quer ter hoje fechada a vulnerabilidade PHP2Shell precisa de quatro coisas: a atualização certa, o reinício de todos os processos PHP, a verificação de código malicioso já introduzido e uma prova. Está afetado? Ligue-nos. Nós ajudamos. Tratamos disso remotamente, desde a primeira mensagem.
Não apague nada nem reinstale nada agora. Também ao aplicar patches vale: primeiro preservar, depois alterar. Se algo já tiver entrado, precisamos do estado dos ficheiros e dos registos. Comunicar uma emergência; esclarecemos consigo a ordem dos passos.
Porque é que a vulnerabilidade não pode esperar
As duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio PHP e permitem a execução remota de código malicioso, sem autenticação. O BSI (Gabinete Federal Alemão para a Segurança da Informação) declarou o nível de alerta 3 (laranja) e recomenda a atualização imediata. Se esta não for possível de imediato, os servidores web devem ser retirados temporariamente da rede. Segundo notícias dos meios de comunicação, houve as primeiras tentativas de ataque observadas já antes da publicação dos patches, a 21/10/2026. A Cloudflare observou tentativas e disponibilizou regras de proteção, mas avisa que regras baseadas apenas nos dados do pedido não bastam.
Importante para os operadores: uma atualização do CMS não fecha a vulnerabilidade do PHP. Também o WordPress.org, segundo relatos, não planeia nenhuma atualização contra ela, porque a vulnerabilidade está no interpretador. Só se fecha ao nível do PHP, ou seja, naquilo que o seu servidor realmente executa.
O que fazer já
- Conhecer a versão de destino. Estão corrigidas as versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.2 atinge o fim do suporte a 31/12/2026; tenha isso em conta no planeamento.
- Registar todos os sistemas. Também servidores de teste, imagens de contentor e sistemas antigos que sejam acessíveis a partir da Internet.
- Esclarecer a responsabilidade. Nos pacotes de alojamento e nos servidores geridos, é o fornecedor que aplica a atualização. Pergunte por escrito pela versão e pelo reinício.
- Conservar os registos. A partir de 20/10/2026, segundo a imprensa especializada.
- Combinar a janela. Um reinício interrompe brevemente os pedidos em curso. Defina um momento em que alguém possa tomar decisões.
- Não esperar, se estiver aberto. Se não for possível aplicar o patch de imediato, avalie connosco o isolamento ou as medidas provisórias.
Como ajuda concretamente a PHP SOS?
- Levantar a situação: registamos sistemas, versões do PHP, modos de operação, fornecedores de alojamento e acessibilidade, e definimos a ordem: primeiro os sistemas mais expostos.
- Preservar e fechar: preservamos o estado atual, aplicamos a atualização ou levamos o alojamento ao estado comprovadamente com patch e reiniciamos todos os processos. Nos contentores, reconstruímos a imagem e publicamo-la.
- Verificar e limpar: como um patch não remove código malicioso, verificamos se há sinais de uma intrusão anterior e limpamos, se necessário.
- Reforçar e relatar: recebe uma prova escrita por sistema e recomendações para que a próxima atualização seja mais rápida. O âmbito do serviço é descrito pelo serviço de patches PHP.
Atualização, reinício, prova: o que importa
O erro mais frequente é uma atualização sem reinício. Enquanto processos antigos estiverem em memória, o código vulnerável continua ativo, mesmo que os ficheiros sejam novos. As instruções estão na página Reiniciar o PHP-FPM e todos os workers. O segundo erro é acreditar no que é apresentado: as distribuições e os fornecedores de alojamento fornecem muitas vezes backports, e então o número de versão mantém-se. Tem valor probatório o changelog do pacote com os números CVE, na família Debian com apt-get changelog <paket>.
Além disso, segundo o manual do PHP, desde as versões de segurança existe a nova diretiva memory_hard_limit_percent. Se uma versão do PHP não a conhece, está afetada. O teste é curto:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Tem de ser feito por versão e por modo de operação, porque a linha de comandos pode usar uma versão do PHP diferente da do servidor web. No final, registamos o resultado para que o possa mostrar ao seu fornecedor de alojamento, à seguradora ou ao cliente.
Se a atualização não for possível de imediato
Há razões pelas quais uma atualização não é possível hoje: uma aplicação antiga que não corre em versões mais recentes do PHP, um fornecedor de alojamento sem autorização, uma imagem de contentor num pipeline fixo. Para estes casos, o php.net indica medidas provisórias que, expressamente, não são uma proteção completa: definir memory_limit=-1 de modo que as aplicações o não possam sobrepor, limitar o post_max_size, session.upload_progress.enabled=0 e, no PHP 8.5, fatal_error_backtraces=0, sempre com reinício. A isto juntam-se regras de proteção na periferia, que não substituem uma atualização. Uma dica em circulação, bloquear todos os pedidos com PHPSESSID, é expressamente rejeitada pelos autores especializados.
Que medidas se adequam ao seu sistema e o que podem estragar, discutimos antes. Mais informação na página Medidas imediatas se ainda não puder aplicar o patch e no tema WAF e patching virtual. Para o PHP 8.1 e anteriores aplica-se uma situação própria, descrita em PHP 8.1 e anteriores: o que se aplica agora.
O que nos deve enviar
- Lista dos servidores e dos fornecedores de alojamento, se existir
- Resultado de
php -vpor sistema e indicação do modo de operação - Indicação de se estão em uso contentores, Plesk, cPanel ou uma oferta gerida
- Janela de tempo pretendida e pessoa de contacto para os reinícios
- Indícios de anomalias desde 17/10/2026
Porquê a PHP SOS
Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor que acompanha a atualização, verifica o reinício e entrega a prova. Trabalhamos remotamente, sem deslocações, e documentamos cada passo. Não prometemos milagres: um patch fecha a vulnerabilidade, mas não prova que nada aconteceu antes, e dizemos-lho assim mesmo.
Está afetado? Ligue-nos. Nós ajudamos.
Não deixe a vulnerabilidade aberta por mais tempo. Ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem e ficamos até o incidente estar encerrado e documentado. Comunicar já uma emergência.
Perguntas frequentes
Posso fechar sozinho a vulnerabilidade de segurança do PHP ou preciso de ajuda?
Uma atualização é exequível para administradores, mas propensa a erros: tem de aplicar-se à versão que realmente serve o site e todos os processos têm de ser reiniciados. Quem tem vários servidores, imagens de contentor ou um fornecedor de alojamento com particularidades poupa tempo e erros com apoio.
O PHP tem de ser reiniciado depois da atualização?
Sim. Ficheiros novos não bastam enquanto processos PHP antigos estiverem em memória. Todos os workers, ou processos, têm de ser reiniciados; no mod_php, o servidor web.
O que fazer se ainda não existir atualização para a minha versão do PHP?
Para o PHP 8.1 e anteriores, o projeto PHP já não disponibiliza atualizações oficiais. São então necessários um backport do fornecedor comprovadamente com patch, uma migração para uma versão mantida ou medidas provisórias, que no entanto não oferecem proteção completa.
Basta definir session.upload_progress.enabled como 0?
Não. Segundo relatórios especializados, esta definição, por si só, não fecha as duas vulnerabilidades; a atualização do PHP continua a ser obrigatória. Defina-a apenas no php.ini, no pool FPM ou na configuração do servidor, não através de ini_set() nem de .user.ini.
Como sei que a vulnerabilidade ficou mesmo fechada?
Através de uma prova no sistema em funcionamento: versão ou changelog do pacote, um teste da nova diretiva memory_hard_limit_percent e a confirmação de que todos os processos foram reiniciados depois da atualização.