Em resumo: quem gere por si próprio um servidor root ou vServer tem também de o proteger após o PHP2Shell: levar os pacotes PHP para um nível corrigido, reiniciar todos os processos PHP e verificar o resultado. O operador do centro de dados ocupa-se, em regra, apenas do hardware, da virtualização e da rede. Depois, compensa reforçar o servidor de forma duradoura.
A sua responsabilidade num servidor próprio
Num servidor root ou vServer não gerido, aluga capacidade de computação, não assistência. Sistema operativo, servidor web, PHP, base de dados, firewall, cópias de segurança e monitorização estão nas suas mãos. Para a gerência e os proprietários, isto significa: se ninguém na empresa ou num prestador de serviços assumiu expressamente estas tarefas, ninguém as faz.
O PHP2Shell torna isso visível. As duas vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio PHP e permitem a execução de código sem autenticação. O projeto PHP publicou a 21/10/2026 as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda a atualização imediata e, se isso não for possível, retirar temporariamente o servidor web da rede.
Proteger o vServer: verificar inventário e nível dos pacotes
Obtenha primeiro uma visão geral de que versões PHP estão instaladas e de onde provêm. Muitos servidores usam, além dos pacotes da distribuição, origens de pacotes adicionais. Os comandos seguintes apenas leem. Os nomes de pacotes são exemplos.
# Debian/Ubuntu: pacotes PHP instalados e a sua origem
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm
# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'
# Que binários PHP existem, afinal?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
O número de versão, por si só, não chega. As distribuições entregam muitas vezes as correções de segurança como backport; o número mostrado permanece então mais antigo. A decisão cabe ao registo de alterações do pacote.
# Debian/Ubuntu (nome do pacote como exemplo)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'
# Família RHEL (nome do pacote como exemplo)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
Um guia detalhado está em Verificar a versão PHP e o nível de patch.
Instalar a atualização e renovar todos os processos
Instale as atualizações através da gestão de pacotes e reinicie depois cada serviço que carrega o PHP. Consoante a arquitetura, são o PHP-FPM, o Apache com mod_php, o LiteSpeed ou um servidor de aplicações. Ficheiros novos no disco não bastam enquanto houver processos antigos a correr em memória.
# Encontrar serviços com PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'
# Mostrar processos com a hora de arranque
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep
# Debian/Ubuntu: detetar programas com bibliotecas desatualizadas (se instalado)
needrestart -r l
Todos os processos relevantes devem ter sido iniciados depois da atualização. É útil a ferramenta needrestart nos sistemas Debian, que mostra serviços com bibliotecas desatualizadas. Os pormenores do reinício estão descritos em Reiniciar o PHP-FPM e todos os workers.
Um patch não remove software malicioso introduzido antes da atualização. Guarde os registos do servidor web a partir de 20/10/2026 e verifique se o servidor apresenta vestígios antes de o classificar como limpo.
Para uma primeira busca de vestígios, há algumas verificações que não alteram nada. Procure ficheiros PHP criados ou alterados desde 17/10/2026 nos diretórios web, entradas desconhecidas nos crontabs de todos os utilizadores, novos utilizadores do sistema e chaves SSH, bem como processos do utilizador do servidor web que mantenham ligações de saída.
# Ficheiros PHP alterados desde 17/10/2026 (caminho como exemplo)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
# Ligações de rede com o processo correspondente
ss -tupn
Nenhuma destas verificações prova, por si só, uma intrusão, e um resultado vazio não prova o contrário. Mostram, no entanto, se é necessária uma investigação mais profunda. Trabalhe sobre cópias dos registos e não altere ficheiros suspeitos até o estado estar preservado. Em caso de achados, o caminho seguro é uma investigação ordenada. Neste caso, não se limite a desligar o servidor nem o volte a instalar de imediato, pois perdem-se vestígios que são importantes para avaliar as obrigações de notificação e uma eventual denúncia.
Reforçar o servidor de forma duradoura
Depois da atualização urgente, segue-se a segurança de base. Não evita todas as vulnerabilidades, mas limita os danos e encurta o tempo de reação da próxima vez. Estes pontos têm-se revelado eficazes:
- Acessos: SSH apenas com chave, sem início de sessão direto como root, interfaces de administração acessíveis apenas a partir de redes conhecidas.
- Firewall: abrir apenas as portas realmente necessárias, restringir as ligações de saída do servidor web.
- Configuração do PHP: desativar funções perigosas,
open_basedirpor site, pools e utilizadores próprios por aplicação. - Permissões de ficheiros: o servidor web não pode escrever no código do programa, os diretórios de upload não executam PHP.
- Atualizações: instalar automaticamente as atualizações de segurança, planear de forma fixa o reinício e a verificação.
- Cópias de segurança: cópias segundo a regra 3-2-1, pelo menos uma cópia fora do servidor e protegida contra alterações.
- Registos: recolher os logs de forma centralizada e conservá-los durante tempo suficiente.
Como é uma cópia de segurança fiável descreve-o Cópias de segurança segundo a regra 3-2-1. Como enquadramento para empresas, serve a proteção de base das TI (IT-Grundschutz) do BSI.
Quando um servidor gerido é a melhor escolha
Um servidor próprio compensa quando alguém assume a manutenção de forma fiável: acompanhar atualizações, avaliar situações como o PHP2Shell, poder reagir de noite. Se essa capacidade falta, faz sentido um servidor gerido ou um contrato de manutenção fixo. Em ambos os casos, o importante é registar por escrito as responsabilidades. Mais sobre isto em Servidor gerido: esclarecer a responsabilidade.
Como ajuda concretamente a PHP SOS?
- Levantamos todas as instalações PHP, origens de pacotes e serviços do seu servidor e avaliamos o nível real de patch.
- Instalamos as atualizações, reiniciamos todos os processos e documentamos o resultado.
- Verificamos o servidor quanto a vestígios de comprometimento e preservamos os registos para uma análise posterior.
- No âmbito do nosso reforço de servidores, configuramos corretamente acessos, firewall, pools PHP e permissões.
- Se desejar, assumimos a manutenção contínua através de um contrato de manutenção de segurança.
Perguntas frequentes
O meu centro de dados aplica patches ao vServer automaticamente?
Em servidores root e vServers não geridos, em regra não. O fornecedor disponibiliza hardware ou virtualização e rede; o sistema operativo e todos os serviços nele instalados gere-os você. Em caso de dúvida, consulte o seu contrato.
As atualizações de segurança automáticas bastam?
Ajudam, mas não substituem a verificação. As atualizações automáticas nem sempre reiniciam os processos PHP em execução e muitas vezes não cobrem pacotes de origens externas. Depois de cada atualização de segurança, verifique o nível dos pacotes e as horas de arranque dos processos.
Como descubro se o meu pacote contém um backport?
No registo de alterações do pacote e nos avisos de segurança da sua distribuição. Se o número CVE constar aí, a correção está incluída, mesmo que o número de versão pareça mais antigo. Se a entrada faltar, esclareça o nível antes de classificar o servidor como com patch.
O que faço se não vier nenhum patch para a minha versão PHP?
O PHP 8.1 e anteriores já não recebem atualizações oficiais. Aplique as medidas provisórias segundo o php.net, planeie rapidamente a mudança para uma versão suportada e, segundo a recomendação do BSI, retire o servidor da rede temporariamente, se necessário.