php2shell (CVE-2026-109618 / 109619) não pode ser avaliado com php -v: onde os números de versão divergem entre FPM, Docker e distros

Se o PHP que atende as requisições web (PHP-FPM, mod_php do Apache, php-cgi, FrankenPHP, LiteSpeed) for anterior à 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, ele é afetado pelo CVE-2026-109618 e pelo CVE-2026-109619, conhecidos como php2shell. A correção é atualizar para uma dessas versões (ou, no caso de pacotes de distro, para o pacote corrigido) e reiniciar os processos. O que você precisa verificar não é o php -v local, mas “o PHP que de fato atende a web” e “a versão do pacote instalado”.

Este artigo trata de quatro situações em que julgar apenas pelo número da versão leva a uma conclusão errada. Todos os números e informações de status são de 2026-10-22, e as fontes de cada item estão listadas no final.

O que se sabe em 2026-10-22

O comunicado do PHP afirma que “a única correção completa é atualizar”. As mitigações para o período anterior à atualização são tratadas mais adiante neste artigo.

Armadilha 1: o php -v e o PHP voltado para a web podem ser diferentes

O php -v digitado via SSH informa a versão do PHP da CLI. As requisições web são atendidas por processos do PHP-FPM ou pelo mod_php carregado no Apache, que são binários e pacotes separados. Se você instalou um PHP mais novo apenas para a CLI, executa várias versões lado a lado ou tem um pool do FPM apontando para outra versão, o lado web pode continuar antigo mesmo quando o php -v mostra uma versão corrigida.

Há várias maneiras de ver a versão real do lado web.

# FPM no Debian / Ubuntu (nomeado por versão)
php-fpm8.3 -v

# FPM em sistemas da família RHEL
php-fpm -v

# Verificar se o mod_php está carregado no Apache
apachectl -M | grep -i php

O método mais confiável é fazer o PHP que realmente executa pela web informar a própria versão. Coloque um arquivo temporário com um nome difícil de adivinhar e apague-o assim que terminar a verificação.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Se PHP_SAPI for fpm-fcgi, o PHP está rodando sob FPM; apache2handler indica mod_php; cgi-fcgi indica CGI. Evite deixar o phpinfo() exposto, pois isso por si só vaza informações.

A reinicialização é outra etapa fácil de esquecer. Mesmo depois de o pacote ser substituído, os processos do php-fpm ou do Apache já em execução podem continuar rodando o código antigo. Algumas configurações reiniciam automaticamente nas atualizações de pacote; outras não. Após atualizar, reinicie o FPM / Apache e verifique novamente a versão do lado web pelos métodos acima.

Armadilha 2: com Docker, não dá para julgar pelo nome da tag

A imagem oficial php tem “tags móveis”, como 8.3 e 8.3-fpm, cujo conteúdo é substituído, e tags fixas, como 8.3.30, que fixam a versão.

• Mesmo depois que uma tag móvel passa a apontar para uma versão corrigida no Docker Hub, sua cópia local continua sendo a imagem antiga até você fazer o pull novamente. Os contêineres em execução também continuam usando a imagem antiga até serem recriados. Um Dockerfile com FROM php:8.3-fpm ainda será construído sobre a base antiga se ela permanecer no cache de build.
• Uma tag fixa continua antiga para sempre, até que você mesmo atualize o número.

Você pode verificar se as tags das versões corrigidas foram publicadas usando a API do Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Estes são os resultados da consulta a quatro linhas de lançamento em 2026-10-22 (horários em UTC).

Essa verificação revelou três pontos em que julgar pelos números pode induzir ao erro.

1. “Atualizado recentemente” não significa “corrigido”. A tag fixa 8.3.35 foi reconstruída durante 2026-10-21, mas o PHP_VERSION dentro dela continuava 8.3.35. Olhe a versão interna, não a data de atualização.
2. Digests diferentes podem ter o mesmo conteúdo. 8.3 e 8.3.36 tinham digests de tag diferentes (o valor do índice multiarquitetura), mas a imagem amd64 era idêntica e ambas tinham PHP_VERSION=8.3.36. Da mesma forma, em 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm e 8.2-fpm, o PHP_VERSION da imagem amd64 era uma versão corrigida.
3. Não há imagens oficiais corrigidas para 8.1 e anteriores. A 8.1-fpm foi atualizada pela última vez em 2025-12-31.

Para verificar suas imagens locais e os contêineres em execução:

# Versão do PHP de uma imagem já baixada localmente
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Fazer o pull novamente e recriar os contêineres
docker compose pull
docker compose up -d

# Se você constrói sua própria imagem, refaça o pull da base e depois o build
docker compose build --pull

# Versão dentro de um contêiner em execução
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Substitua app no último comando pelo nome do seu serviço. Cada imagem oficial é construída com um único PHP_VERSION, portanto a versão da CLI dentro de um contêiner coincide com a versão do FPM / Apache desse contêiner (a Armadilha 1 se aplica quando o PHP é instalado diretamente no host).

O FrankenPHP incorpora o PHP, então a versão do FrankenPHP e a versão do PHP embutido são números diferentes. As notas de lançamento do FrankenPHP 1.13.2, lançado em 2026-10-21, informam que as imagens Docker foram construídas com PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 e os binários estáticos com PHP 8.5.12.

Armadilha 3: pacotes de distro são “corrigidos com números antigos”

Ubuntu e RHEL portam apenas as correções para versões mais antigas (backporting). O número exibido pelo php -v continua antigo, então uma verificação numérica como “menor que 8.3.36, portanto vulnerável” marcará como vulnerável um sistema já corrigido. Inversamente, também não se pode confiar no número para ficar tranquilo. Decida com base na versão do pacote e no tracker de segurança de cada distro.

Pacotes corrigidos listados em cada tracker em 2026-10-22 (iguais para os dois CVEs):

Esta tabela mostra diretamente por que apenas os números não bastam. O PHP corrigido do Ubuntu 24.04 é uma versão que começa com 8.3.6, muito abaixo da 8.3.36 do upstream. O PHP padrão do RHEL 9 está corrigido mesmo permanecendo na 8.0.30, embora o upstream não publique mais correções para a 8.0. O Debian passou a usar os mesmos números do upstream (8.2.35 / 8.4.27).

Alguns pacotes ainda não estão corrigidos (em 2026-10-22).

• O módulo php 8.4 do RHEL 9 consta como “afetado, sem correção”.
• O Debian forky (testing) tem o php8.4 8.4.26-1, marcado como “vulnerable”. O php8.4 do sid (unstable) é o 8.4.27-1 e está corrigido.

Exemplos de comandos para verificar o seu servidor:

# Debian / Ubuntu: versão instalada e versão disponível
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: se este CVE está corrigido neste servidor
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Família RHEL: se existe uma atualização que corrige este CVE e qual é a versão instalada
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Ajuste o nome do pacote (php8.3-fpm etc.) ao seu ambiente. Compare a versão exibida com a “versão corrigida” da tabela acima ou do tracker; se for igual ou superior, a correção está aplicada. Em seguida, conclua a reinicialização e a verificação do lado web descritas na Armadilha 1.

Se você instala o PHP a partir de um repositório de terceiros, e não dos pacotes da própria distro, é preciso acompanhar as atualizações desse repositório. O comunicado do PHP observa que o rpms.remirepo.net, mantido por voluntários, não teria atualizações no dia da divulgação, e recomenda migrar para os pacotes da distro ou para builds próprios.

Armadilha 4: em hospedagem compartilhada e ambientes gerenciados, você não pode atualizar o PHP por conta própria

Em hospedagem compartilhada e ambientes PHP gerenciados, o provedor substitui o runtime do PHP. Aqui também o número sozinho não basta: se o provedor compila o PHP por conta própria ou faz backport de correções, o número de versão pode continuar antigo.

Há três coisas que você mesmo pode fazer.

1. Verifique a versão do lado web. Use o arquivo temporário da Armadilha 1 para exibir PHP_VERSION e PHP_SAPI e apague-o logo em seguida. Se o painel de controle tiver um seletor de versão do PHP, anote também qual versão você selecionou.
2. Leia o aviso do provedor e pergunte se não houver nenhum. Pergunte: “Para quais versões do PHP do meu plano as correções do CVE-2026-109618 e do CVE-2026-109619 serão aplicadas, e quando (ou já foram aplicadas)?”. Perguntar pelo número do CVE, e não pelo número da versão, gera uma resposta que também cobre backports.
3. Se você selecionou uma versão sem suporte, atualize. O projeto PHP não publica correções para 8.1 e anteriores, e o suporte à 8.2 termina em 2026-12-31. A menos que o provedor tenha feito backport das correções, trocar de versão é o caminho seguro.

Situação por provedor de hospedagem (em 2026-10-22)

Em hospedagem compartilhada, o provedor normalmente atualiza o runtime do PHP, e os avisos de muitos provedores dizem que “nenhuma ação é necessária por parte dos usuários”. O usuário tem duas coisas a fazer: conferir o aviso oficial do seu provedor e, caso tenha selecionado uma versão antiga do PHP no painel de controle, decidir se troca para a versão recomendada no aviso (uma que tenha versão corrigida).

A tabela abaixo resume apenas o que está escrito nas páginas oficiais de cada provedor (comunicados e informações de manutenção), parafraseando o texto dos avisos. Os avisos são atualizados conforme o andamento, então confirme sempre a situação real na página oficial citada.

Onde não consegui encontrar ou abrir um aviso oficial, a tabela diz “não foi possível confirmar” ou “não encontrei”. A ausência de informação ali não significa que o provedor não tenha respondido. Consulte diretamente os comunicados e o suporte do seu provedor.

Mitigações enquanto você não pode atualizar imediatamente

O comunicado do PHP lista configurações que reduzem a superfície de ataque até que você possa atualizar. No entanto, o próprio comunicado afirma explicitamente que elas “não tornam você seguro”. As principais são:

• Para o CVE-2026-109619: defina session.upload_progress.enabled=0 no php.ini, no pool do FPM ou na configuração do servidor e reinicie todos os workers (ini_set() e o .user.ini do FPM não funcionam para isso). No PHP 8.5, defina também fatal_error_backtraces=0.
• Para o CVE-2026-109618: defina memory_limit=-1 de uma forma que a aplicação não possa sobrescrever e reduza o post_max_size (8M se não houver uploads, 32M se houver). Não use RLIMIT_AS / RLIMIT_DATA como substituto.

O NCSC do Reino Unido recomenda considerar tirar do ar qualquer sistema que não possa ser atualizado ou mitigado imediatamente, e verificar sinais de comprometimento antes de atualizar ou aplicar mitigações.

Fontes (verificadas em 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: anúncios de lançamento do PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: imagem oficial php
• Notas de lançamento do FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (versões dos pacotes corrigidos, conforme os dados VEX da Red Hat)
• NCSC: Critical security issue affecting PHP