1 Encontre cada PHP no servidor

Muitos servidores executam mais de um PHP: o pacote do sistema, versões instaladas por um painel de controle (cPanel EA-PHP, Plesk, CWP/CloudLinux alt-php, DirectAdmin), contêineres e builds de linha de comando usados pelo cron. Cada um que atende requisições web precisa ser atualizado.

Execute php -v, liste os processos php-fpm com ps aux | grep php-fpm e confira o seletor de PHP do seu painel.

2 Atualize para uma versão corrigida

As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Pacotes de distribuição podem trazer a correção com um número de versão mais antigo — verifique no changelog as CVE-2026-109618 e CVE-2026-109619.

PHP 8.1 e anteriores não recebem release do projeto PHP. Backports mínimos do código-fonte foram publicados para 7.4, 8.0 e 8.1 para quem compila a partir do código-fonte, mas a solução duradoura é migrar para um branch com suporte.

Debian / Ubuntu (pacotes da distribuição)

Instale a atualização de segurança da sua distribuição e reinicie o PHP. O número de versão pode continuar o mesmo; o changelog do pacote lista a CVE.

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

Aplique as erratas do fornecedor para o stream de módulo do seu PHP e reinicie.

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / imagens oficiais do php

Baixe ou reconstrua com a tag corrigida e recrie os contêineres.

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel, Plesk, CWP, DirectAdmin

Use a ferramenta de atualização do painel para cada versão do PHP instalada (EA-PHP, handlers PHP do Plesk, alt-php, CustomBuild) e reinicie o PHP-FPM. Painéis costumam manter versões antigas instaladas para sites específicos — atualize-as ou remova-as também.

Hospedagem compartilhada ou gerenciada

Normalmente você não consegue atualizar o PHP por conta própria. Use a mensagem do cartão de resultado para pedir ao seu provedor a versão exata, a data da correção e a confirmação de que os workers foram reiniciados.

Windows / IIS

Baixe o build corrigido em windows.php.net, substitua o diretório do PHP e recicle os pools de aplicativos do IIS.

3 Reinicie todos os processos PHP

Instalar um pacote não altera o código que já está em execução. Reinicie o PHP-FPM, o Apache (para mod_php), o LiteSpeed, o FrankenPHP, os workers de filas e os supervisores. Para contêineres, reconstrua ou baixe a nova imagem — reiniciar a mesma imagem não instala correção alguma.

4 Verifique

Execute php -v para cada binário e confirme que os processos em execução usam o novo build (por exemplo, ls -l /proc/$(pgrep -o php-fpm)/exe não deve mostrar “deleted”). Depois, execute este verificador novamente.

5 Se não puder atualizar hoje

Aplique as mitigações parciais abaixo e restrinja quem pode acessar o site até poder atualizar. Elas reduzem o risco; não o eliminam.

6 Procure sinais de comprometimento — e troque os segredos

Se um site vulnerável estava acessível pela internet, revise a atividade a partir de 20 de outubro de 2026: falhas de workers PHP (SIGSEGV) no log de erros do PHP-FPM ou do Apache, arquivos PHP novos ou modificados na raiz web, novos cron jobs, novas contas de administrador e conexões de saída inesperadas.

Como a CVE-2026-109619 pode expor a memória do processo PHP sem executar código algum, um sistema de arquivos limpo não prova que nada vazou. Troque as senhas de banco de dados, as chaves de API e as credenciais de pagamento e de e-mail, e invalide as sessões de usuários dos sites que ficaram expostos.

7 Depois de atualizar

A correção introduz um novo limite rígido de memória: um processo que o atinge é encerrado imediatamente e os shutdown handlers não são executados. Verifique como sua aplicação se comporta sob pressão de memória, revise o memory_limit junto com post_max_size e max_input_nesting_level, e desfaça qualquer memory_limit = -1 temporário que você tenha definido antes de aplicar a correção. Ocultar a versão com expose_php = Off é um reforço opcional, não uma correção.

Mitigações parciais (do php.net e dos avisos)

Elas apenas estreitam os caminhos de ataque conhecidos. O php.net afirma que atualizar é a única opção segura.

; php.ini / FPM pool (php_admin_value) — reinicie todos os workers depois
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M se uploads forem necessários
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

Defina estas configurações no php.ini, no pool do PHP-FPM (php_admin_value) ou na configuração do servidor — não com ini_set() ou .user.ini — e reinicie os workers. Outras medidas dos avisos e da equipe de pesquisa:

memory_limit = -1 bloqueia alguns caminhos que dependem do próprio limite de memória do PHP, mas transfere o esgotamento de memória para o sistema operacional — use-o apenas junto com um limite cgroup v2 memory.max. Não use RLIMIT_AS nem RLIMIT_DATA; eles podem acionar os mesmos caminhos vulneráveis.
Reduza max_input_nesting_level o quanto seus formulários permitirem.
Reduza o pm.max_requests do PHP-FPM para que os workers sejam reciclados com mais frequência (com custo de desempenho).
Limites de tamanho de requisição, de quantidade de campos e de aninhamento no servidor web ou proxy; remova configurações INI por requisição inválidas ou obsoletas.
Políticas de SELinux ou AppArmor podem limitar o que um worker comprometido consegue executar — elas reduzem o impacto, mas não impedem o vazamento de memória.

Referências

Fonte: aviso de segurança do php.net, 21 de outubro de 2026. Última verificação em 2026-10-23.