Em resumo: quem quer mandar instalar uma atualização do PHP precisa de mais do que pacotes novos: o que conta é o estado de pacote correto, o reinício de todos os processos PHP e uma prova disso. É exatamente isso que o nosso serviço de patches PHP entrega. Recebe um comprovativo escrito por servidor, que pode apresentar internamente ou a terceiros.
Porque é que uma atualização do PHP, por si só, muitas vezes não basta
Desde 21/10/2026 existem patches para as vulnerabilidades PHP2Shell CVE-2026-109618 e CVE-2026-109619. O BSI recomenda a atualização imediata. Na prática, vemos três obstáculos típicos.
Primeiro, o número de versão nem sempre mostra o estado real. As distribuições e os fornecedores de alojamento aplicam por vezes backports; então o Plesk, por exemplo, continua a indicar 8.2.34, embora o estado do pacote tenha o patch aplicado. Segundo, depois da instalação continuam muitas vezes a correr processos PHP antigos. Ficheiros novos no disco não protegem enquanto os workers antigos estiverem a trabalhar na memória. Terceiro, num servidor correm frequentemente várias versões do PHP em paralelo, e uma delas é esquecida.
Mandar instalar a atualização do PHP: as versões corrigidas
| Ramo | Corrigido a partir de | Estado anterior | Nota |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | verificar adicionalmente fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | o suporte termina a 31/12/2026 |
| PHP 8.1 e anteriores | sem atualizações oficiais | – | apenas backports mínimos do código-fonte para 7.4, 8.0, 8.1 |
Nos pacotes de distribuições ou de fornecedores de alojamento, não conta o número a seguir a “PHP”, mas o estado do pacote que o fornecedor confirma como tendo o patch aplicado. Como pode verificá-lo por si, vê-se em Verificar corretamente a versão do PHP e o nível de patch.
Como ajuda concretamente a PHP SOS?
- Inventário: registamos todas as instalações PHP no servidor, o modo de operação (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) e que site usa que versão.
- Instalar a atualização: instalamos as versões corrigidas a partir da fonte de pacotes da sua distribuição, do seu painel ou do projeto oficial. Para contentores, construímos consigo novas imagens.
- Reinício de todos os processos: reiniciamos por completo o PHP-FPM, o Apache, o LiteSpeed ou os respetivos workers e verificamos que nenhum processo é mais antigo do que a atualização. Os antecedentes constam de Reiniciar o PHP-FPM e todos os workers.
- Verificação de funcionamento: acedemos às páginas e funções mais importantes, por exemplo a página inicial, o início de sessão, os formulários e o checkout, e verificamos os registos de erros.
- Comprovativo: recebe, por servidor, um protocolo com a versão, o estado do pacote, o momento do reinício e os pontos em aberto.
Um passo de verificação típico depois do reinício é este:
# versão da CLI do PHP e do binário FPM (caminho conforme o sistema)
php -v
php-fpm8.3 -v
# hora de arranque dos processos FPM: tem de ser posterior à atualização
ps -o pid,lstart,cmd -C php-fpm8.3
Casos especiais: painéis, contentores e várias versões do PHP
Em servidores com Plesk ou cPanel, as versões do PHP vêm muitas vezes das fontes de pacotes do painel e não da distribuição. Aí verificamos cada versão instalada individualmente, mesmo as que de momento não estão atribuídas a nenhum site. As versões antigas e não utilizadas, removemo-las após acordo, para que não sejam reativadas por engano.
Em ambientes Docker e Kubernetes, uma atualização no anfitrião não basta. O PHP está na imagem, e só uma imagem reconstruída com a base já corrigida, distribuída por todos os contentores em execução, fecha a vulnerabilidade. Verificamos também se imagens mais antigas continuam a ser usadas em registos ou em deployments. Os pormenores constam de Aplicar patches ao PHP em contentores Docker.
No mod_php, o PHP corre diretamente no processo do Apache. A equipa do PHP classifica aí o risco como o mais elevado. Depois da atualização, o próprio Apache tem por isso de ser totalmente reiniciado; um simples recarregamento da configuração nem sempre basta.
O que recebe de nós
- um protocolo de patch por servidor: pacotes instalados, versões, fonte, momento
- a prova de que todos os processos PHP foram reiniciados
- uma lista dos sites e funções verificados
- indicações sobre sistemas a que não foi possível aplicar o patch, com fundamentação
- uma recomendação para o passo seguinte, por exemplo no caso do PHP 8.2, devido ao fim próximo do suporte
O que precisamos de si
- Acesso: SSH com direitos de administrador ou acesso ao painel (Plesk, cPanel ou semelhante)
- Janela de manutenção: quando é permitido um breve reinício
- Interlocutor: para dúvidas e para a aprovação depois da verificação de funcionamento
- Cópias de segurança: confirmação de que existe uma cópia atual ou a incumbência de criar uma antes
- Indicações sobre desenvolvimentos próprios: extensões PHP ou configurações especiais que devam ser respeitadas
Em alojamento partilhado sem acesso próprio ao servidor, não podemos aplicar o patch nós mesmos. Ajudamo-lo então a colocar as perguntas certas ao fornecedor de alojamento e a avaliar a resposta.
O que não prometemos
O serviço de patches fecha a vulnerabilidade conhecida. Não responde se o servidor já tinha sido comprometido antes da atualização e não remove software malicioso introduzido. Se quiser saber isso, a encomenda adequada é a ajuda imediata PHP2Shell com busca de vestígios.
Para o PHP 8.1 e anteriores já não existem atualizações oficiais. Aqui aplicamos medidas provisórias e recomendamos a migração para uma versão suportada. Não damos uma garantia de compatibilidade para o seu CMS de memória, mas verificamo-la com base nos requisitos de sistema do fabricante.
Perguntas frequentes
Porque é que o meu servidor ainda mostra a versão antiga do PHP depois da atualização?
Pode haver duas razões. Ou a distribuição aplicou um backport, e então o número de versão fica igual, embora o estado do pacote tenha o patch aplicado. Ou ainda correm processos PHP antigos na memória, que têm de ser reiniciados.
Que versões do PHP corrigem o PHP2Shell?
A vulnerabilidade está corrigida no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicados a 21/10/2026. Nos pacotes de distribuições conta o estado do pacote que o fornecedor confirma como tendo o patch aplicado.
A atualização pode deixar o meu site inoperacional?
Uma atualização dentro da mesma versão principal, por exemplo de 8.3.35 para 8.3.36, é em regra pouco crítica. É no entanto necessário um breve reinício dos processos PHP. Combinamos consigo a janela de tempo e verificamos as páginas depois.
Com o patch fica tudo resolvido?
Quanto à vulnerabilidade em si, sim, assim que todos os processos forem reiniciados. Se alguém já tinha entrado antes do patch, o patch não o mostra. Para isso é necessária uma verificação própria.