Várias versões do PHP num servidor: aplicar o patch a cada uma

Em resumo: Se correm várias versões do PHP num servidor, depois do PHP2Shell cada uma tem de ser verificada, atualizada e reiniciada individualmente. As fontes típicas são o sistema operativo, painéis de alojamento como o Plesk ou o cPanel, fontes de terceiros como sury.org ou Remi, CloudLinux, LiteSpeed e versões compiladas por si. Só uma lista completa, feita a partir de pacotes, ficheiros e processos em execução, mostra se nenhuma versão foi mesmo esquecida.

A versão esquecida

Um servidor que funciona há alguns anos acumula versões do PHP como um sótão acumula móveis velhos. O painel trouxe três ramos, para um cliente veio uma versão mais antiga de uma fonte de terceiros, o sistema operativo tem a sua própria. Cada uma foi instalada um dia por boas razões. Só que hoje ninguém sabe qual ainda é necessária.

Depois do PHP2Shell, é precisamente isso o problema. As correções surgiram a 21 de outubro de 2026 para o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Cada instalação no servidor recebe-as, contudo, pelo seu próprio caminho, do seu próprio responsável pelo pacote e no seu próprio momento. Para o PHP 8.1 e anteriores, existem apenas backports mínimos do código-fonte. Quem atualiza só a versão principal deixa as outras em aberto.

De onde vêm as muitas versões

A visão geral seguinte indica fontes típicas e caminhos de exemplo. Os caminhos exatos variam consoante a versão e a distribuição.

Os pacotes do sury.org são particularmente traiçoeiros, porque usam os mesmos caminhos que a distribuição. Se um php8.3 vem do Debian ou do sury.org, só a fonte do pacote o mostra. As particularidades estão descritas nos artigos O repositório sury.org e O repositório Remi. Como o Plesk gere as suas versões está descrito na página Servidores Plesk: verificar e aplicar patches às versões do PHP.

Encontrar todas as instalações do PHP

Uma lista fiável resulta de três perspetivas. Os comandos são apenas de leitura e, consoante o servidor, podem demorar algum tempo.

# 1. Pacotes: o que o gestor de pacotes conhece
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Ficheiros: binários PHP executáveis, também fora do gestor de pacotes
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Processos: o que está realmente a correr neste momento, com hora de arranque
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Compare as três listas. Um ficheiro sem pacote indica uma versão compilada por si ou copiada manualmente. Um processo sem ficheiro correspondente pode apontar para uma instalação apagada mas ainda em execução. No Apache, verifique ainda se está carregado um módulo PHP, por exemplo com apache2ctl -M ou httpd -M. Os contentores e os pods do Kubernetes só aparecem em parte nestas listas e precisam de uma verificação própria das imagens.

Aplicar o patch a cada versão

Quando cada instalação tem uma linha na sua lista, segue-se para todas o mesmo procedimento:

1. Esclarecer a responsabilidade: o patch vem da distribuição, do painel, de uma fonte de terceiros ou de si mesmo?
2. Avaliar o estado: versão corrigida oficial, backport confirmado, por esclarecer ou em aberto.
3. Atualizar: pelo caminho da respetiva fonte, não por outro.
4. Reiniciar: o serviço dessa versão, não só o serviço principal. No caso do mod_php, o servidor web. Os pormenores estão em Reiniciar o PHP-FPM e todos os workers.
5. Controlar: comparar a hora de arranque dos processos com o momento da atualização.
6. Documentar: versão, estado do pacote, comprovativo, hora do reinício.

Para as versões para as quais não existe patch, valem até à migração as medidas provisórias do php.net. Aplique-as a cada versão em separado, porque cada instalação tem o seu próprio php.ini e os seus próprios pools.

Que versão usa a linha de comandos, qual usa o contentor?

Duas áreas escapam com particular frequência à busca. A primeira é a linha de comandos. No Debian e no Ubuntu, é o sistema de alternativas que decide que binário está por trás do comando php. O update-alternatives --display php mostra que versões estão registadas e qual vale neste momento. As tarefas cron que chamam um caminho fixo como /usr/bin/php7.4 contornam, no entanto, esta definição. Por isso vale a pena olhar para os crontabs de todos os utilizadores e para a configuração dos painéis que criam tarefas cron próprias.

A segunda área são os contentores. Um contentor Docker no servidor traz a sua própria versão do PHP, que não aparece em nenhuma lista de pacotes do anfitrião. O docker ps mostra os contentores em execução; se há PHP lá dentro e em que versão, revela-o um olhar à imagem ou um php -v no contentor. O patch aí não se faz no anfitrião, mas reconstruindo a imagem e substituindo o contentor.

Menos é mais seguro

A melhor verificação é a que não é preciso fazer. Cada versão do PHP instalada duplica o esforço na próxima vulnerabilidade. Depois do PHP2Shell vale por isso a pena uma regra clara: cada versão no servidor precisa de uma finalidade e de um responsável. O que não tem é primeiro desativado e, após um período de observação, removido. Mais sobre isto no artigo Desativar versões antigas do PHP no painel de alojamento.

Como ajuda concretamente a PHP SOS?

• Elaboramos para os seus servidores uma lista completa de todas as instalações do PHP, a partir de pacotes, ficheiros, processos e contentores.
• Esclarecemos, por versão, a origem, a responsabilidade e o estado do patch.
• No âmbito do serviço de patch PHP, atualizamos cada versão, reiniciamos cada serviço e comprovamos o estado.
• Em conjunto consigo, definimos que versões ficam e removemos as restantes de forma controlada.

Perguntas frequentes

Fontes

• php.net: avisos de segurança
• php.net: versões suportadas
• Red Hat Security Bulletin RHSB-2026-013