Em resumo: Para verificar uma CVE no changelog, pesquise no registo de alterações do pacote PHP instalado por CVE-2026-109618 e CVE-2026-109619: no Debian e no Ubuntu em /usr/share/doc/<paket>/changelog.Debian.gz, em sistemas RPM com rpm -q --changelog. Um resultado, juntamente com o estado do pacote, a comparação com o aviso de segurança oficial e a hora do reinício, constitui um comprovativo sólido. A ausência de resultado ainda não prova uma vulnerabilidade em aberto.
Porque é que um comprovativo é mais do que “aplicámos o patch”
Depois do PHP2Shell, muitos querem saber se os seus servidores estão seguros: a administração, o encarregado da proteção de dados, clientes com subcontratação de tratamento de dados, por vezes a seguradora de ciberriscos. “Aplicámos o patch” é pouco para isso. O que se pede é uma prova que um terceiro consiga acompanhar.
O número de versão muitas vezes não serve, porque as distribuições incorporam as correções como backport e o número mantém-se. O changelog do pacote é a melhor base. É escrito pelo responsável pelo pacote e, nas atualizações de segurança, costuma listar os números CVE corrigidos.
Onde estão os changelogs
Cada formato de pacote tem o seu local. A visão geral seguinte ajuda a chegar depressa ao sítio certo.
| Sistema | Local do changelog | Comando para pesquisar |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | arquivo de pacotes da distribuição | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | base de dados de pacotes RPM | rpm -q --changelog <paket> |
| Imagens de contentor | na imagem, como no sistema base | executar o comando no contentor |
No Debian e no Ubuntu, o diretório de documentação de alguns pacotes binários aponta, através de uma ligação simbólica, para um pacote comum, por exemplo php8.3-common. Se o zgrep não encontrar o ficheiro, veja o diretório com ls -l /usr/share/doc/ | grep php.
Verificar a CVE no changelog: como proceder
Os comandos seguintes são apenas de leitura. Adapte os nomes dos pacotes à sua instalação.
# Debian/Ubuntu: localmente, sem rede
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: linha de cabeçalho da entrada mais recente com estado do pacote e data
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Família RHEL: entrada com data e estado do pacote
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
No Debian e no Ubuntu, o estado do pacote está na linha de cabeçalho de cada entrada e a data na linha final. No RPM, ambos estão na linha acima das entradas. Assim vê não só se a CVE é mencionada, mas também com que estado do pacote. Compare esse estado com o instalado, por exemplo através de dpkg-query -W ou rpm -q. Se ambos coincidirem, a correção está incluída no pacote em execução.
Pacotes de painel e contentores
Os painéis de alojamento trazem pacotes PHP próprios, como o Plesk ou o cPanel. Também estes são pacotes DEB ou RPM comuns, e o seu changelog pode ser lido com as mesmas ferramentas. Se os fornecedores nele indicam números CVE ou apenas a nova versão do PHP, varia. Se o pacote indicar a versão upstream 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, isso basta como prova; no caso de backports com número antigo, precisa da informação do fornecedor.
Nos contentores, o comprovativo pertence à imagem, não ao anfitrião. Verifique os pacotes na imagem a partir da qual o contentor em execução foi iniciado e registe também o digest da imagem. Assim fica depois claro que estado esteve realmente em execução, mesmo que a imagem entretanto tenha sido reconstruída sob a mesma tag.
Quando a CVE não aparece no changelog
Uma entrada em falta tem várias causas possíveis. Percorra-as por esta ordem:
- Pacote errado pesquisado: com vários ramos ou fontes de PHP num servidor, a resposta está muitas vezes no changelog de outro pacote.
- Versão upstream em vez da CVE: se a fonte entrega a nova versão upstream, por exemplo 8.4.27, o changelog pode indicar apenas “New upstream version”. Nesse caso o próprio número de versão é a prova, porque o php.net indica as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 como corrigidas.
- Outra formulação: alguns responsáveis indicam números de bug ou identificadores de advisory como GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp em vez da CVE.
- Comparação com o aviso de segurança: se o aviso oficial da sua distribuição, por exemplo um USN ou o Debian Security Tracker, indicar um estado de pacote corrigido e este ou um mais recente estiver instalado, isso também é uma prova. Para o Debian e o Ubuntu, encontra os estados no artigo O meu pacote PHP tem patch?, para a família RHEL em RHEL, AlmaLinux e Rocky Linux.
- Perguntar ao fornecedor: no caso de pacotes de painel, builds do fornecedor de alojamento ou fontes de terceiros, só ajuda a informação por escrito. Um modelo está no guia Perguntar ao fornecedor de alojamento pelo estado do patch.
Se, depois destes passos, não restar nenhuma prova, trate o servidor como sem patch e aplique medidas provisórias até a questão estar esclarecida.
Do resultado ao comprovativo
Um resultado no changelog prova que o pacote contém a correção. Não prova que os processos em execução a utilizam. Um comprovativo completo contém por isso cinco informações por servidor e instalação do PHP:
- servidor, ramo do PHP e modo de operação, por exemplo PHP-FPM ou mod_php
- estado do pacote instalado e fonte do pacote
- local no changelog ou referência ao aviso de segurança oficial
- momento da atualização e hora de arranque dos processos PHP em execução
- nome da pessoa que verificou e data da verificação
Guarde os resultados em bruto dos comandos como ficheiro de texto junto do comprovativo. São mais fáceis de acompanhar mais tarde do que um resumo feito de memória.
Um comprovativo responde apenas à pergunta se a vulnerabilidade estava fechada a partir de um dado momento. Para o período anterior, precisa dos registos a partir de 20 de outubro de 2026 e, se necessário, de uma pesquisa de vestígios. O procedimento geral da verificação da versão está descrito na página Verificar corretamente a versão do PHP e o estado do patch.
Como ajuda concretamente a PHP SOS?
- Pesquisamos os changelogs de todos os pacotes PHP dos seus servidores e comparamo-los com os avisos de segurança oficiais.
- Onde os changelogs são omissos, esclarecemos o estado com a distribuição, o fornecedor do painel ou o fornecedor de alojamento.
- Verificamos que os processos em execução foram reiniciados depois da atualização.
- Com o serviço de patch PHP recebe o comprovativo por servidor numa forma que pode transmitir a terceiros.
Perguntas frequentes
Porque é que a versão do PHP não basta como comprovativo?
Muitas distribuições incorporam as correções de segurança como backport, sem alterar a versão do PHP. O número de versão não diz então nada sobre o patch. O changelog do pacote instalado, em contrapartida, indica os números CVE corrigidos.
O que significa se a CVE não aparece no changelog?
Pode significar que falta a correção. Mas também pode ser que o responsável pelo pacote formule de outra maneira, por exemplo com um número de bug ou a versão upstream. Nesse caso, compare o estado do pacote com o aviso de segurança oficial ou pergunte ao fornecedor.
Durante quanto tempo devo conservar o comprovativo?
Enquanto puder ser relevante para auditorias internas, seguradoras ou eventuais questões de proteção de dados. Arquive-o juntamente com os registos a partir de 20 de outubro de 2026. Esclareça os prazos concretos com o encarregado da proteção de dados ou com aconselhamento jurídico.
Posso verificar o changelog também sem acesso à Internet?
Sim. O Debian e o Ubuntu guardam o changelog de cada pacote localmente em /usr/share/doc, os sistemas RPM guardam-no na base de dados de pacotes. Ambos podem ser lidos sem rede.