Em resumo: Se o seu pacote PHP no Debian ou Ubuntu tem patch contra o PHP2Shell reconhece-se pelo estado exato do pacote, e não pela versão do PHP. O Ubuntu publicou a 21 de outubro de 2026 pacotes corrigidos para todos os lançamentos suportados, os mais antigos através do Ubuntu Pro. O Debian corrigiu o php8.2 no bookworm e o php8.4 no trixie. Compare o estado instalado com dpkg --compare-versions e reinicie depois todos os serviços PHP.
A pergunta por trás da pergunta
“O meu pacote PHP tem patch?” soa a uma pergunta de sim ou não. Na prática, a resposta depende de três coisas: de que fonte vem o pacote, que estado está instalado e se esse estado também está em execução. Este artigo responde aos dois primeiros pontos para os pacotes oficiais do Debian e do Ubuntu. Como verificar em geral a versão e os processos em execução está em Verificar corretamente a versão do PHP e o nível de patch.
Consultámos as indicações nos avisos de segurança oficiais do Ubuntu e no Debian Security Tracker a 25 de outubro de 2026. Ambas as CVE, CVE-2026-109618 e CVE-2026-109619, constam aí com os mesmos estados corrigidos.
Estados de pacote corrigidos no Ubuntu
O Ubuntu publicou as correções em dois avisos. A USN-8948-1 cobre os lançamentos atuais, a USN-8948-2 os mais antigos, que só recebem atualizações de segurança através do Ubuntu Pro. Para 16.04 e 14.04, o Ubuntu indica adicionalmente a oferta Legacy Support.
| Lançamento Ubuntu | Pacote-fonte | Estado corrigido |
|---|---|---|
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 LTS (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 LTS (Ubuntu Pro) | php7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |
Chama a atenção o facto de todos os estados manterem a versão original do PHP. O Ubuntu 24.04 continua na 8.3.6, embora a correção tenha sido tirada da 8.3.36. Porque é assim e como lidar com isso é explicado no artigo Porque é que o php -v mostra o mesmo número. Estão afetados em cada caso, entre outros, os pacotes binários para FPM, CLI, CGI e o módulo Apache, por exemplo php8.3-fpm e libapache2-mod-php8.3.
Estados de pacote corrigidos no Debian
O Debian segue aqui outro caminho e entrega as novas versões upstream. Segundo o Security Tracker, o estado é este:
| Lançamento Debian | Pacote-fonte | Estado anterior | Estado corrigido | Aviso |
|---|---|---|---|---|
| 12 bookworm | php8.2 | 8.2.32-1~deb12u1 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| 13 trixie | php8.4 | 8.4.24-1~deb13u1 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| forky, sid | php8.4 | 8.4.27-1 |
O aviso para o bookworm saiu como DLA, ou seja, através do Debian LTS. Para o php8.2 no unstable, o Tracker não indica, na consulta, ainda nenhum estado corrigido. Quem opera sistemas de teste no unstable deve ter isso debaixo de olho.
Lançamentos mais antigos do Debian não aparecem, na consulta, nas duas entradas CVE. Se um servidor ainda corre num desses lançamentos, por exemplo o Debian 11 com PHP 7.4, não pode contar com uma atualização de segurança do arquivo oficial. Então restam três caminhos: subir o sistema operativo para um lançamento suportado, usar uma oferta comercial de suporte de longo prazo cuja cobertura para o PHP2Shell mande confirmar por escrito, ou proteger o servidor até à migração com medidas provisórias e limitar a sua acessibilidade. A longo prazo, só o primeiro caminho é sustentável.
Como comparar exatamente o estado instalado
Um olhar ao número de versão não basta, porque as versões do Debian são ordenadas segundo regras próprias. O dpkg --compare-versions compara corretamente. Os comandos seguintes são apenas de leitura; adapte os nomes dos pacotes e o estado de destino ao seu lançamento.
# Estado instalado e origem do pacote
apt policy php8.3-fpm
# Todos os pacotes PHP instalados com versão
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null
# Comparação exata com o estado corrigido (exemplo Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"
Na saída do apt policy, preste atenção à linha com a origem do pacote. Se aí não estiver o arquivo de segurança da sua distribuição, mas por exemplo packages.sury.org ou um PPA, as tabelas acima não se aplicam. Então conta o estado dessa fonte de terceiros, que tratamos no artigo O repositório sury.org.
Vale ainda a pena consultar o registo de alterações fornecido. Como encontrar aí os números CVE e guardá-los como comprovativo é descrito no artigo Comprovar números CVE no registo de alterações do pacote.
Armadilhas típicas na verificação
Verificado apenas um pacote: O PHP é composto por muitos pacotes binários. Se o php8.3-cli está atual mas o php8.3-fpm não, o site continua aberto. Verifique todos os pacotes de um ramo, em especial FPM, CGI e o módulo Apache.
Pacote retido: Os pacotes fixados com apt-mark hold ficam parados na atualização. O apt-mark showhold mostra-os.
Ubuntu Pro não ativo: No 20.04 e anteriores, as correções só chegam se o Ubuntu Pro estiver configurado. Sem o Pro, o sistema continua vulnerável apesar da execução da atualização.
Espelho desatualizado: Se o servidor obtém os pacotes através de um espelho ou proxy interno, só vê novas atualizações de segurança quando este estiver atualizado. Em caso de dúvida, verifique se o apt update alcança efetivamente a fonte de segurança.
Reinício esquecido: Os novos pacotes só produzem efeito após o reinício de todos os serviços que carregaram PHP. O needrestart, se instalado, mostra os serviços com código desatualizado.
Um estado de pacote corrigido comprova apenas que a vulnerabilidade está agora fechada. Se o servidor foi atacado antes, não o responde. Guarde os registos desde 20 de outubro.
Como ajuda concretamente a PHP SOS?
- Apuramos, para cada servidor, a origem de todos os pacotes PHP e comparamos o estado com os avisos oficiais.
- Aplicamos atualizações, também através do Ubuntu Pro, e reiniciamos todos os serviços afetados.
- Com o serviço de patches PHP, recebe por servidor um comprovativo com o estado do pacote, a correspondência no registo de alterações e a hora do reinício.
- Em sistemas com fontes de terceiros ou versões antigas, esclarecemos que caminho leva a um estado comprovadamente corrigido.
Perguntas frequentes
Que versão do Ubuntu contém a correção do PHP2Shell?
Segundo a USN-8948-1, o Ubuntu 22.04, 24.04, 26.04 e 26.10 estão abastecidos com atualizações regulares. Para 14.04, 16.04, 18.04 e 20.04, o Ubuntu entrega as correções, segundo a USN-8948-2, através do Ubuntu Pro.
Porque é que o Ubuntu 24.04 continua a mostrar PHP 8.3.6?
O Ubuntu incorpora as correções de segurança como backport na versão existente. O número upstream mantém-se 8.3.6, apenas o estado do pacote muda. Segundo a USN-8948-1, o estado corrigido é 8.3.6-0ubuntu0.24.04.13.
O Debian 12 bookworm ainda está abastecido?
Sim. Segundo o Debian Security Tracker, para o php8.2 no bookworm existe o estado corrigido 8.2.35-1~deb12u1, anunciado como DLA-4848-1 no âmbito do Debian LTS.
Isto vale também para o PHP do repositório sury?
Não. Os pacotes de fontes de terceiros como o sury.org têm estados de versão próprios e registos de alterações próprios. As indicações do Debian e do Ubuntu valem apenas para os seus pacotes oficiais.
Basta um apt upgrade?
Instala os novos pacotes, mas os processos PHP-FPM ou Apache em execução mantêm o código antigo na memória. Só um reinício de todos os serviços que carregam PHP torna o patch eficaz.