Em resumo: Quando o php -v mostra a mesma versão depois da atualização, isso deve-se em regra a um backport: a distribuição incorpora apenas a correção de segurança na sua versão PHP existente, e o número mantém-se. O Ubuntu 24.04 continua assim a indicar 8.3.6, embora o pacote esteja corrigido contra o PHP2Shell. Esclareça a questão através do estado do pacote e do registo de alterações e verifique ainda se o site corre mesmo com o código novo.
Um momento típico depois do PHP2Shell
O administrador aplicou a atualização, tudo sem erros. Para controlar, escreve php -v e vê a mesma versão de antes. A atualização não funcionou? O servidor continua aberto? Esta pergunta está entre as mais frequentes desde 21 de outubro de 2026.
A boa notícia: na maioria dos casos, está tudo em ordem. A má: há também casos em que o mesmo número indica de facto um problema. Este artigo ajuda a distinguir os dois.
Porque é que as distribuições não alteram o número
As distribuições empresariais e LTS prometem estabilidade. Dentro de um lançamento, o comportamento e as interfaces devem, tanto quanto possível, não mudar. Um salto do PHP 8.3.6 para 8.3.36 traria, porém, numerosas correções de erros e pequenas alterações de comportamento que poderiam perturbar aplicações.
Por isso, muitos responsáveis por pacotes incorporam apenas a correção de segurança concreta na sua versão existente. A este processo chama-se backport. A versão upstream, que o próprio PHP indica através do php -v, mantém-se igual. O que muda é o estado do pacote, atribuído pela distribuição.
No exemplo do Ubuntu 24.04, é assim: o PHP indica 8.3.6. O estado corrigido do pacote é, porém, segundo a USN-8948-1, 8.3.6-0ubuntu0.24.04.13. A parte final é a que conta. O Debian decidiu de outra forma no PHP2Shell e entregou para o bookworm e o trixie as novas versões upstream 8.2.35 e 8.4.27. O resumo por lançamento está no artigo Debian e Ubuntu: o meu pacote PHP tem patch?.
Vale a pena decompor uma vez uma versão de pacote destas. No exemplo 8.3.6-0ubuntu0.24.04.13: a parte antes do hífen é a versão upstream, ou seja, o que o próprio PHP indica. Segue-se a revisão da distribuição. ubuntu0.24.04 remete para o lançamento, o último número conta as revisões. Cada correção de segurança aumenta este número. No Ubuntu Pro aparece ainda um sufixo como +esm5, nas atualizações de segurança do Debian um como ~deb12u1. Quem souber ler estas partes reconhece de relance se um pacote foi alterado depois de um aviso de segurança.
Onde aparece o número antigo
O número inalterado não aparece só no php -v. Está também em locais visíveis do exterior ou analisados por ferramentas:
| Local | O que lá está | Consequência |
|---|---|---|
php -v e php -i |
versão upstream, data de compilação | os administradores duvidam da atualização |
| página phpinfo | versão upstream | o mesmo efeito no navegador |
cabeçalho X-Powered-By |
versão upstream, se o expose_php estiver ativo |
scanners externos comunicam uma vulnerabilidade |
| painéis de alojamento como o Plesk | versão upstream | indicação, por exemplo, de 8.2.34 apesar do patch |
| scanners de vulnerabilidades | comparação por número | falso alarme com backports |
Os scanners externos são um caso à parte. Quem os usa pode receber, depois do PHP2Shell, achados para servidores que há muito estão corrigidos. Não ignore estes achados em bloco; comprove para cada servidor o estado do pacote e registe o achado como verificado. Outra razão para ocultar as indicações de versão para o exterior está no artigo expose_php e cabeçalhos do servidor.
Quando o mesmo número é um sinal de alerta
Há três situações em que o número inalterado indica de facto um problema:
- A fonte de pacotes fornece a versão upstream. Se o PHP vem de uma fonte que normalmente entrega a versão upstream atual, como o Debian no PHP2Shell ou fontes de terceiros como o Remi e o sury.org, depois da atualização devia aparecer 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se aí continuar o número antigo, o pacote não foi atualizado.
- Está a verificar a instalação errada. O
php -vmostra a linha de comandos. Se o site correr através de outra versão, por exemplo de um painel de alojamento ou de uma Software Collection, a saída nada diz sobre o site. - O estado do pacote não mudou. Se também o estado do pacote for o mesmo de antes da atualização, a atualização não chegou a esse pacote, por exemplo porque foi retido ou falta a fonte.
Para não técnicos, pode resumir-se assim: o número da versão descreve o modelo, o estado do pacote o estado de manutenção. Dois servidores com a mesma versão do PHP podem diferir bastante na segurança. Por isso, não pergunte à sua TI ou ao seu prestador de serviços pela versão, mas pelo comprovativo do patch.
Como esclarecer a questão em cinco minutos
Os comandos seguintes são apenas de leitura. Os exemplos partem do Ubuntu ou Debian e do PHP 8.3; em sistemas RHEL, use rpm -q em vez de dpkg-query.
# 1. O que indica o próprio PHP, incluindo a data de compilação?
php -v
# 2. Que estado do pacote está instalado, de que fonte?
apt policy php8.3-fpm
# 3. O registo de alterações contém os números CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Desde quando correm os processos PHP do site?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
A data de compilação na saída do php -v é uma indicação, mas não uma prova. O comprovativo fiável fornece-o a entrada do registo de alterações. Como a encontrar e guardar, quando está formulada de outra forma ou falta, é descrito no artigo Comprovar números CVE no registo de alterações do pacote.
Depois de cada verificação, anote os dois números: a versão upstream do php -v e o estado do pacote. Quem perguntar mais tarde porque é que o servidor “ainda tem 8.3.6” recebe assim uma resposta clara.
A verificação geral através da versão, do pacote e dos processos é resumida na página Verificar corretamente a versão do PHP e o nível de patch.
Como ajuda concretamente a PHP SOS?
- Esclarecemos, para cada servidor, se um número de versão inalterado é um backport ou uma atualização em falta.
- Avaliamos achados de scanners de vulnerabilidades e comprovamos falsos alarmes com o estado do pacote e o registo de alterações.
- Verificamos que instalação PHP o site realmente usa e se os seus processos foram reiniciados.
- No serviço de patches PHP, documentamos lado a lado a versão upstream e o estado do pacote.
Perguntas frequentes
O meu servidor está sem patch se o php -v mostrar o número antigo?
Não necessariamente. Muitas distribuições incorporam correções como backport na versão existente. O Ubuntu 24.04, por exemplo, continua a mostrar 8.3.6, embora o pacote esteja corrigido segundo a USN-8948-1. Decisivos são o estado do pacote e o registo de alterações.
Porque é que o meu scanner de segurança comunica uma vulnerabilidade apesar da atualização?
Muitos scanners leem apenas o número de versão, por exemplo do cabeçalho X-Powered-By. Com backports, isso leva a falsos alarmes. Verifique o estado do pacote e documente o resultado, em vez de simplesmente ignorar o achado.
Pode o php -v mostrar um número novo e o site não?
Sim. O php -v mostra a linha de comandos. O site pode correr através de outra instalação ou de processos iniciados antes da atualização. Verifique por isso também o serviço FPM ou o Apache e a respetiva hora de arranque.
Ajuda a data de compilação na saída do php -v?
É uma indicação, mas não uma prova. Uma data de compilação posterior a 21 de outubro de 2026 é compatível com um pacote corrigido, mas não prova que a correção esteja incluída. A entrada do registo de alterações é o melhor comprovativo.