Situação atual: PHP2Shell. Duas vulnerabilidades críticas do PHP (CVSS 9,2) permitem executar código malicioso sem autenticação. Patches disponíveis desde 21/10/2026.O que fazer agora →

Verificar corretamente a versão do PHP e o nível de patch

A versão do PHP apresentada, por si só, não diz se o PHP2Shell está fechado. O decisivo são o estado do pacote, os backports e se os processos novos estão realmente em execução.

Atualizado em 5 min de leituraPHP2Shell

Em resumo: para verificar a versão do PHP, o php -v não basta. Tem de saber que versão do PHP o servidor web realmente usa, se o pacote contém a correção, também como backport com número antigo, e se todos os processos foram reiniciados após a atualização. O PHP2Shell está corrigido no 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

Porque é que o número de versão, por si só, não basta

Para o PHP2Shell existe uma lista clara de versões corrigidas. Na prática, três situações levam, no entanto, a avaliações erradas:

  • Várias instalações: a linha de comandos mostra o PHP 8.3, mas o site corre através de um pool com PHP 8.1.
  • Backports: as distribuições e os fornecedores de alojamento incorporam por vezes correções em pacotes existentes. Então, o Plesk, por exemplo, continua a mostrar 8.2.34, apesar de o patch estar aplicado.
  • Processos antigos: os ficheiros novos estão no disco, mas os workers em execução ainda são de antes.

Para a administração e para quem não é técnico, ajuda uma regra simples: não pergunte só “Que versão do PHP temos?”, mas “O PHP2Shell está fechado em todos os servidores e como o vemos?”. Uma resposta sólida contém três provas: versão ou backport, estado do pacote e momento do reinício.

A verificação técnica tem, por isso, três passos: versão, estado do pacote, processos em execução. Os comandos abaixo são apenas de leitura. Os nomes de pacotes e de serviços variam conforme a distribuição, a fonte do PHP e a interface de alojamento; os exemplos partem do PHP 8.3.

Verificar a versão do PHP na linha de comandos

php -v                                  # versão da linha de comandos
ls /etc/php/ 2>/dev/null                # Debian/Ubuntu: ramos instalados
php-fpm8.3 -v                           # versão do binário FPM (o nome varia conforme a distribuição)
php -i | grep -E "^PHP Version|Server API|Loaded Configuration File"

No RHEL, AlmaLinux ou Rocky, o binário FPM chama-se normalmente php-fpm; com software collections ou fontes de terceiros, há outras versões em caminhos próprios. O Plesk e o cPanel trazem instalações PHP próprias, que existem ao lado do PHP do sistema. Como proceder aí, descrevemo-lo nas páginas sobre Plesk e cPanel.

A versão do PHP que um site usa no contexto web vê-se de forma mais fiável na configuração do pool ou do VirtualHost ou na interface de alojamento. Uma página phpinfo também a mostra; crie-a apenas por pouco tempo, com proteção de acesso e um nome aleatório, e apague-a logo a seguir.

No alojamento partilhado, não costuma ter acesso à linha de comandos. Então, a interface de alojamento mostra a versão do PHP definida por site. Se um backport foi instalado e reiniciado, raramente aparece aí. Aqui, a confirmação escrita do fornecedor de alojamento é o caminho fiável.

Verificar o estado do pacote e os backports

O estado do pacote mostra o que a sua distribuição realmente entregou:

# Debian/Ubuntu
apt policy php8.3-fpm
apt changelog php8.3-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"

# RHEL, AlmaLinux, Rocky, Fedora
dnf info php-fpm
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"

Se um dos números CVE constar do changelog, o backport está incluído no pacote instalado. Se a entrada faltar, isso ainda não é prova de uma vulnerabilidade: alguns responsáveis por pacotes redigem os changelogs de outra forma. Nesse caso, compare a versão do pacote com os avisos de segurança da sua distribuição ou pergunte ao fornecedor. Um modelo para este pedido encontra-o em Como perguntar ao seu fornecedor de alojamento pelo estado do patch.

Importante: verifique cada pacote PHP instalado, e não apenas o primeiro. Em servidores com vários ramos, é frequente um estar com patch e outro não.

A versão nova está mesmo em execução?

Uma atualização só é eficaz depois de todos os processos PHP serem reiniciados. Compare a hora de arranque dos processos em execução com o momento da atualização:

ps -o pid,lstart,cmd -C php-fpm8.3      # hora de arranque dos processos FPM
systemctl status php8.3-fpm             # desde quando o serviço está em execução
needrestart -r l                        # Debian/Ubuntu, se instalado: mostra processos desatualizados

Se a hora de arranque for anterior à atualização, ainda correm processos antigos. No Apache com mod_php, o mesmo se aplica aos processos do Apache. Como reiniciar corretamente, descreve-o Reiniciar o PHP-FPM e todos os workers.

Dica

Registe o resultado por escrito: servidor, versão do PHP, versão do pacote, CVE no changelog sim ou não, momento do reinício. Esta nota é necessária para a administração, a seguradora e uma posterior verificação de vestígios.

Enquadrar o resultado

Achado Avaliação
Versão oficial 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, processos reiniciados PHP2Shell fechado
Número mais antigo, números CVE no changelog do pacote, processos reiniciados Backport instalado, fechado
Número mais antigo, sem entrada no changelog, sem confirmação pouco claro, esclarecer junto do fornecedor
PHP 8.1 ou anterior sem backport confirmado aberto, são necessárias medidas provisórias e migração
Processos mais antigos do que a atualização falta o reinício, vulnerabilidade continua ativa

Se um servidor ficar no estado “pouco claro”, trate-o como aberto: aplique medidas provisórias e acompanhe o esclarecimento até haver uma prova. A visão geral completa das versões consta de Que versões do PHP estão afetadas?.

Como ajuda concretamente a PHP SOS?

Com o serviço de patches PHP, assumimos a verificação e o comprovativo:

  • Encontrar todas as instalações, também as versões secundárias de painéis de alojamento, software collections ou contentores.
  • Avaliar o estado do pacote: versão oficial, backport ou aberto, com prova do changelog ou do fornecedor.
  • Controlar o reinício, até já não correr nenhum processo com código antigo.
  • Elaborar um protocolo de verificação, que pode usar internamente e perante terceiros.

Perguntas frequentes

Porque é que o php -v mostra uma versão diferente da do meu site?

Em muitos servidores estão instaladas várias versões do PHP. A linha de comandos usa uma delas, o servidor web ou um pool FPM outra. Verifique por isso a versão que realmente corre no contexto web, por exemplo através do binário FPM ou da interface de alojamento.

Como reconheço um backport?

Nos pacotes de distribuições, a correção consta muitas vezes do changelog do pacote, frequentemente com o número CVE. No Debian e no Ubuntu ajuda o apt changelog, nos sistemas da família RHEL o rpm -q --changelog. Se a entrada faltar, esclareça o estado junto do fornecedor.

Posso verificar a versão do PHP no menu de cliente do alojamento?

Sim, a maioria das interfaces mostra a versão definida por site. Se um backport foi instalado e reiniciado, normalmente não o vê aí. Para isso, a confirmação escrita do fornecedor de alojamento é o caminho fiável.

Fontes

Contacto imediato

Cada hora conta. Escreva-nos agora.

Descreva brevemente o sistema, a versão do PHP e o que observou. Entramos em contacto consigo, esclarecemos a situação e trabalhamos remotamente até o incidente estar concluído e documentado.

Ajuda imediata