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

> Verificar a versão do PHP, mas bem: veja como reconhecer o nível de patch, os backports da distribuição e os processos em execução e saber se o PHP2Shell está fechado.

Fonte: https://phpsos.de/pt/php2shell/php-version-pruefen/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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

```bash
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](https://phpsos.de/pt/server/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:

```bash
# 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](https://phpsos.de/pt/ratgeber/hoster-patch-status-erfragen/).

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:

```bash
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](https://phpsos.de/pt/php2shell/php-fpm-neustart/).

> **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?](https://phpsos.de/pt/php2shell/betroffene-php-versionen/).

## Como ajuda concretamente a PHP SOS?

Com o [serviço de patches PHP](https://phpsos.de/pt/leistungen/php-patch-service/), 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

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)