Em resumo: depois da atualização do PHP, tem de reiniciar o PHP-FPM e todos os outros serviços que carregam o PHP. Ficheiros novos no disco não bastam enquanto processos PHP antigos correrem na memória. Só depois do reinício o servidor trabalha com o código corrigido do PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou com o backport do seu fornecedor.
Porque tem de reiniciar o PHP-FPM
Uma atualização de pacotes substitui os ficheiros no disco. Os processos que já estão em execução, no entanto, já carregaram o código do programa antigo para a memória e continuam a trabalhar com ele. O PHP-FPM, o Apache com mod_php ou o LiteSpeed mantêm muitas vezes os seus workers vivos durante dias.
Para o PHP2Shell, isto é particularmente importante. A vulnerabilidade CVE-2026-109619 depende precisamente de estado que persiste entre pedidos no mesmo worker. Um worker com código antigo continua vulnerável, seja qual for a versão que está no disco. Segundo o php.net, por isso, todos os workers e processos devem ser reiniciados.
Alguns gestores de pacotes reiniciam os serviços automaticamente na atualização, outros não. Não confie nisso, verifique o resultado.
Um quadro típico do dia a dia: a gestão de pacotes comunica “PHP atualizado”, a monitorização não mostra erros, o site funciona. Mesmo assim, os workers antigos continuam a atender cada pedido, porque ninguém reiniciou o serviço. De fora, este estado não se reconhece. Por isso, a verificação das horas de arranque dos processos faz parte de cada atualização.
Que serviços carregam o PHP?
| Modo de operação | O que reiniciar | Comando típico (os nomes variam conforme a distribuição) |
|---|---|---|
| PHP-FPM | cada serviço FPM, por versão instalada | systemctl restart php8.3-fpm ou systemctl restart php-fpm |
| Apache com mod_php | Apache | systemctl restart apache2 ou systemctl restart httpd |
| php-cgi | o servidor web que o chama ou o wrapper FastCGI | conforme a configuração |
| LiteSpeed | LiteSpeed e os processos lsphp | através da gestão do LiteSpeed ou do respetivo serviço |
| FrankenPHP | o serviço FrankenPHP ou o contentor | systemctl restart frankenphp ou recriar o contentor |
| Docker, Kubernetes | recriar os contentores a partir de uma nova imagem | ver Aplicar patches ao PHP em contentores Docker |
No mod_php aplica-se: a atualização afeta o próprio Apache, porque o PHP está em cada processo do Apache. Porque este modo de operação é particularmente delicado, vê-se em Porque é que o mod_php tem o risco mais elevado. Para o LiteSpeed, encontra pormenores na página LiteSpeed e LSAPI.
Reiniciar o PHP-FPM: os comandos
Primeiro, encontre todos os serviços PHP no servidor. O Plesk, o cPanel e outras interfaces trazem serviços PHP próprios, com nomes próprios; a lista mostra-os também.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Depois, reinicie cada serviço PHP encontrado, e não apenas o primeiro:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # se estiver instalado um segundo ramo
sudo systemctl restart apache2 # com mod_php; família RHEL: httpd
Recomendamos restart em vez de reload. No reload, o processo principal mantém-se; isso destina-se a alterações de configuração. Depois de uma atualização de segurança, quer ter a certeza de que todos os processos são novos.
Se definiu adicionalmente medidas provisórias como session.upload_progress.enabled=0 ou limites de memória fixos, também estas só produzem efeito depois do reinício. Um reinício resolve ambas as coisas num só passo.
Verificar que já não corre nenhum worker antigo
Compare a hora de arranque dos processos com o momento da atualização. Todos os comandos são apenas de leitura.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # linha “Active: … since …”
needrestart -r l # Debian/Ubuntu, se instalado
Se um processo for mais antigo do que a atualização, não foi abrangido. Causas frequentes são um segundo ramo do PHP esquecido, um serviço de pool próprio de um painel de alojamento ou um contentor que foi apenas reiniciado em vez de recriado a partir da imagem nova. Se corre a versão certa, mostra-o a página Verificar corretamente a versão do PHP e o nível de patch.
Documentar o reinício
Anote, para cada servidor, o momento da atualização e do reinício. Este momento separa o tempo em que o servidor esteve vulnerável do tempo depois. Para uma posterior verificação de vestígios, para as seguradoras e para uma eventual notificação nos termos do RGPD, é o ponto de referência mais importante. Guarde também os registos do servidor desde 20 de outubro, como recomenda a imprensa especializada.
Em servidores com muitos sites, vale a pena uma pequena tabela: servidor, serviço, versão do PHP, versão do pacote, momento do reinício e a pessoa que reiniciou. Assim, as lacunas na cobertura detetam-se depressa, por exemplo um pool que foi esquecido ou um sistema de teste que ninguém tinha na lista.
Como ajuda concretamente a PHP SOS?
No âmbito do serviço de patches PHP, assumimos a atualização e o reinício como um processo coerente:
- Identificar os serviços: encontramos todos os processos que carregam o PHP, também os de painéis de alojamento e contentores.
- Reiniciar de forma controlada, combinado consigo para um momento adequado e com atenção a encomendas ou formulários em curso.
- Verificar depois que nenhum processo é mais antigo do que a atualização e que o site responde normalmente.
- Registar: versões, estados de pacote e momentos de reinício por servidor.
Perguntas frequentes
Basta systemctl reload em vez de restart?
Para o PHP2Shell, recomendamos restart. Um reload costuma reiniciar os workers, mas o processo principal pode continuar a correr. Com restart, garante que não sobra nenhum processo com código antigo. À breve interrupção contrapõe-se um comprovativo claro.
Tenho de reiniciar o servidor inteiro depois da atualização do PHP?
Em regra, não. Basta reiniciar todos os serviços que carregam o PHP: PHP-FPM, Apache no caso do mod_php, LiteSpeed, FrankenPHP ou os contentores afetados. Reiniciar o servidor inteiro é a variante simples quando não tem a certeza de que serviços usam o PHP.
O meu fornecedor de alojamento reinicia o PHP automaticamente após a atualização?
Depende do fornecedor. Pergunte concretamente se, depois do patch, todos os processos PHP foram reiniciados e peça que lho confirmem por escrito.