Vulnerabilidades críticas PHP em outubro 2026: RCE, correcções, mitigações e deploy

Entre 21 e 26 de outubro de 2026, o projeto PHP publicou um conjunto de advisories que equipas europeias de segurança e plataforma devem tratar como evento de resposta coordenada, não como patch Tuesday rotineiro. Duas vulnerabilidades críticas de execução remota de código (CVE-2026-109618 e CVE-2026-109619), discutidas colectivamente na imprensa sectorial como PHP2Shell, afetam essencialmente todos os deployments PHP que servem pedidos web. Um problema separado de progresso de upload de sessão (CVE-2026-115560) requer mitigação por configuração até correção completa num release bugfix posterior. Builds PHP Windows também exigiram rebuilds de dependências pela falha do descodificador Brotli CVE-2026-111497. Este guia resume mecanismos técnicos, versões afetadas, releases corrigidos, mitigações defensivas, fluxo de inventário e patching e orientação de monitorização para CTOs, SREs e donos de aplicação. Escrito apenas para operações defensivas.

Índice

• Resumo executivo para liderança
• Cronologia de advisories (outubro 2026)
• Versões PHP afetadas e releases corrigidos
• CVE-2026-109618: RCE via corrupção OOM
• CVE-2026-109619: RCE via estado global obsoleto
• CVE-2026-115560: vetor de progresso de upload de sessão
• CVE-2026-111497: descodificador Brotli (builds Windows)
• Modos de deployment e risco relativo
• Mitigações temporárias (não substituem patching)
• Exemplos de configuração (php.ini, FPM, Apache)
• Inventário e gestão de patches
• Deteção e triagem forense
• Endurecimento de aplicação e plataforma
• Comunicação com fornecedores e hosting
• FAQ
• Referências

Resumo executivo para liderança

Todas as organizações que executam PHP para tráfego HTTP devem assumir exposição até upgrade para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou pacotes vendor/LTS com correções equivalentes). CVE-2026-109618 e CVE-2026-109619 são classificadas críticas (CVSS v4.0 9.2 no pré-anúncio PHP) e permitem execução remota de código não autenticada em configurações realistas. A CISA adicionou ambas CVEs ao catálogo Known Exploited Vulnerabilities em 26 de outubro de 2026. Material proof-of-concept público aumenta a probabilidade de scanning generalizado.

Ação principal: identificar cada runtime PHP (incluindo cópias embebidas em appliances, painéis e VMs legacy), patch ou isolar, depois verificar que processos worker reiniciam em versões corrigidas.

Ações secundárias: aplicar mitigações documentadas onde patching imediato é impossível, desativar configurações arriscadas de progresso de upload de sessão, atualizar rebuilds Windows PHP -1 para Brotli, monitorizar processos filho anómalos de workers PHP.

Equipas que mantêm produtos PHP de longa duração, incluindo plataformas de faturação e integração, devem priorizar endpoints expostos à Internet e padrões de hosting partilhado (Apache mod_php) primeiro. A Damascode aplica estas práticas ao operar stacks PHP para sistemas de clientes e engenharia de produto interna; este artigo não implica qualquer papel na descoberta das falhas subjacentes.

Cronologia de advisories (outubro 2026)

Fontes primárias oficiais permanecem arquivo de notícias PHP.net 2026 e o advisory de segurança no site ligado à entrada de 21 de outubro.

Versões PHP afetadas e releases corrigidos

Branches PHP 8.1 e anteriores não recebem manutenção rotineira php.net. Alguns vendors Linux e fornecedores LTS comerciais enviam backports; outros exigem migração. PHP também publicou backports mínimos de código-fonte para 7.4, 8.0 e 8.1 para equipas a compilar de fonte sem suporte vendor, o que é paliativo, não estratégia de longo prazo.

Nota Windows: Para CVE-2026-111497, use rebuilds de pacote -1 que incluem Brotli 1.2.1 mantendo o mesmo sufixo de número de versão patch PHP.

CVE-2026-109618: RCE via corrupção OOM

Identificadores: CVE-2026-109618, GHSA-w8hw-w9fx-j79w.

Mecanismo (resumo defensivo): PHP usa fluxo de controlo estilo longjmp() quando alocação de memória falha (out-of-memory, OOM). Alguns contextos de execução não contabilizam totalmente saída abrupta. Memória de pedido pode permanecer parcialmente não inicializada. Limpeza posterior do pedido pode tratar dados inválidos como fiáveis, levando a corrupção de memória e, em casos demonstrados, execução remota de código.

Porque importa aos operadores: Atacantes podem influenciar pressão de memória via tamanho de pedido, tratamento de upload e limites configurados. Reporting sectorial e advisory PHP assinalam maior preocupação para Apache mod_php, onde um pedido não autenticado pode acionar o caminho vulnerável antes do código da aplicação. Exploração também foi discutida em contextos PHP-FPM com caminhos ao nível da aplicação.

Patch: Upgrade para releases corrigidos listados acima. Mitigações reduzem caminhos de ataque específicos mas não substituem patching.

CVE-2026-109619: RCE via estado global obsoleto

Identificadores: CVE-2026-109619, GHSA-6wmf-4rv5-p3rp.

Mecanismo (resumo defensivo): Tratamento de erro fatal em certos pontos pode deixar estado interno do pedido a referenciar memória que pertenceu a um pedido anterior. Um pedido subsequente tratado pelo mesmo processo worker pode consumir pointers obsoletos (comportamento classe use-after-free) antes da reinicialização normal completar. Demonstrações incluíram crashes de worker e execução remota de código contra deployments mod_php reais.

Implicação operacional: Workers PHP de longa duração (pools FPM, alguns app servers) requerem reciclagem de processos após patch e revisão cuidadosa de opcache e definições de max requests de worker para workers não correrem indefinidamente em runtimes não corrigidos.

Patch: Mesmos releases corrigidos que CVE-2026-109618.

CVE-2026-115560: vetor de progresso de upload de sessão

Estado na publicação: Advisory completo prometido com o próximo release bugfix regular; tratar como risco ativo com mitigação por configuração agora.

Condições: Exploração requer combinação invulgar:

• session.serialize_handler definido para php_binary ou php_serialize na configuração
• Aplicação muda handler para php em runtime via ini_set() antes de session_start()
• session.upload_progress.enabled permanece ativado

Aplicações que nunca alteram serialize handler em runtime estão menos expostas. PHP avalia probabilidade prática como baixa, mas estates PHP empresariais raramente têm inventário de configuração perfeito.

Mitigação: Definir session.upload_progress.enabled=0 e reiniciar todos os workers PHP até instalar release corrigido. Esta mitigação já era recomendada para endurecimento CVE-2026-109619 a 21 de outubro; mantenha se aplicada.

CVE-2026-111497: descodificador Brotli (builds Windows)

Âmbito: Escrita fora dos limites na biblioteca Brotli da Google (alcunha sectorial Brotli2Shell em análise de terceiros). Builds oficiais Windows PHP que incluíam versões Brotli vulneráveis podem alcançar o descodificador via extensão cURL quando descompressão automática de resposta HTTP está ativada (não é default, mas aplicações podem ativar).

Caminho de correção: Instalar pacotes Windows 8.5.12-1, 8.4.27-1, 8.3.36-1 ou 8.2.35-1 com Brotli 1.2.1. Deployments Linux podem depender de libbrotli de sistema ou extensão pecl/brotli; acompanhe essas cadeias de supply chain separadamente dos patches de engine PHP de outubro.

Esta CVE é distinta das falhas de engine PHP2Shell mas pertence à mesma janela de alteração para operadores PHP Windows.

Modos de deployment e risco relativo

O advisory PHP declara que todos os modos que servem pedidos web estão em risco: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed e similares.

Equipas de plataforma devem mapear modo por hostname, não só por linguagem do repositório.

Mitigações temporárias (não substituem patching)

PHP e CERTs nacionais enfatizam: só upgrade remedia totalmente CVE-2026-109618 e CVE-2026-109619. Onde patching de emergência atrasa, combine controlos para reduzir exposição:

Para CVE-2026-109618 (caminho OOM)

• Definir memory_limit=-1 numa camada não sobreponível (php_admin_value em pool FPM ou config Apache). Verificar que aplicações não reintroduzem limites finitos via .user.ini, overrides de pool ou chamadas runtime.
• Definir post_max_size conservador (ex.: 8M sem uploads, 32M com uploads) e manter upload_max_filesize abaixo de post_max_size.
• Impor limites de tamanho de pedido e multipart no reverse proxy ou WAF quando possível, incluindo pedidos sem Content-Length fiável.
• Usar limites de memória de contentor ou cgroup como limites de disponibilidade com políticas que terminam workers afetados, não como correção completa. Evitar substitutos RLIMIT_AS / RLIMIT_DATA que acionam o modo vulnerável de falha de alocação.

Para CVE-2026-109619 e CVE-2026-115560

• Definir session.upload_progress.enabled=0 globalmente; reiniciar workers.
• Auditar código por ini_set('session.serialize_handler', ...) em runtime antes de session_start().

Contenção geral

• Retirar sistemas públicos PHP 8.1 e anteriores não patcháveis até substituídos, conforme tom de orientação CISA para branches não suportadas.
• Regras WAF podem bloquear padrões de exploit conhecidos temporariamente; não trate WAF como suficiente sozinho.

Exemplos de configuração (php.ini, FPM, Apache)

Valide sempre em staging; sintaxe varia ligeiramente por distribuição.

Fragmentos php.ini (baseline defensivo)

; Desativar progresso de upload de sessão até deploy de release corrigido CVE-2026-115560
session.upload_progress.enabled = 0

; Reduzir OOM controlável via memory_limit (caminho mitigação CVE-2026-109618)
; Preferir impor via diretivas admin FPM/Apache para apps não sobrescreverem
memory_limit = -1

; Apertar corpos POST onde o negócio permitir
post_max_size = 8M
upload_max_filesize = 2M

; Garantir reciclagem de workers (boa prática junto com patching)
; FPM: pm.max_requests no ficheiro de pool (ver abaixo)

Ajuste tamanhos de upload se o produto legitimamente requer payloads maiores; compense com limites ao nível do proxy e autenticação.

Pool PHP-FPM (fragmento www.conf)

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock

; Mitigações não sobreponíveis
php_admin_value[memory_limit] = -1
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 2M

; Reciclar workers após rollout de patch (ajustar à carga)
pm = dynamic
pm.max_children = 50
pm.max_requests = 500

Após upgrade de pacotes PHP, reiniciar FPM:

sudo systemctl restart php8.3-fpm
php -v
php-fpm8.3 -tt 2>/dev/null | head -5

Confirmar que php -v reporta 8.3.36 ou a versão corrigida do vosso branch.

Apache com mod_php (ilustrativo)

<Directory /var/www/html>
    php_admin_value memory_limit -1
    php_admin_value session.upload_progress.enabled 0
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 2M
</Directory>

Reiniciar Apache após upgrade de pacote:

sudo systemctl restart apache2
apachectl -M | grep php

Script inicial de inventário (bash)

Descobrir versões CLI em caminhos paralelos:

#!/usr/bin/env bash
set -euo pipefail
echo "hostname,fpm_service,php_cli_version,ini_scanned_files"
for bin in /usr/bin/php /usr/local/bin/php; do
  [[ -x "$bin" ]] || continue
  ver="$("$bin" -v 2>/dev/null | head -1 || true)"
  scanned="$("$bin" --ini 2>/dev/null | awk -F: '/Loaded Configuration/{print $2}' | xargs || true)"
  echo "$(hostname -f),n/a,$ver,$scanned"
done
systemctl list-units 'php*-fpm*' --no-legend 2>/dev/null | awk '{print $1}' | while read -r unit; do
  sock="$(systemctl show "$unit" -p FragmentPath --value 2>/dev/null || true)"
  echo "$(hostname -f),$unit,$(php -v 2>/dev/null | head -1),$sock"
done

Estender com digests de imagens de contentor e base images CI; PHP esconde-se muitas vezes dentro de produtos pai.

Inventário e gestão de patches

Passo 1: Descoberta de ativos

• CMDBs perdem PHP muitas vezes; scan imagens, VMs, pods k8s e runtimes PaaS.
• Incluir hosts WordPress, Drupal, Magento, Symfony, Laravel e monolitos custom.
• Consultar hosting providers sobre versão PHP gerida em infraestrutura partilhada.

Passo 2: Priorização

• Produção exposta à Internet primeiro, depois staging que aceita tráfego tipo produção.
• mod_php e endpoints anónimos antes de CLI só interno.

Passo 3: Execução de patch

• Usar pacotes de distribuição quando disponíveis (Debian/Ubuntu Sury, RHEL Remi, etc.).
• Rebuild imagens Docker custom a partir de tags base oficiais com versões corrigidas.
• Rolling restart de pools FPM em tráfego baixo; drenar load balancers.

Passo 4: Verificação

• Teste automatizado: php -r 'echo PHP_VERSION, PHP_EOL;'
• Smoke tests de integração em endpoints de upload e fluxos pesados em sessão.
• Confirmar que session.upload_progress.enabled resolve para 0 em phpinfo() em contexto de produção (restrito a admins).

Passo 5: Tratamento de exceções

• 8.1 e abaixo não suportados: escalar para aceitação de risco de negócio ou replatform de emergência.
• Appliances vendor: acompanhar SLAs de advisory de terceiros separadamente.

Para organizações que também avaliam parceiros de entrega, alinhe SLAs de patch com contratos de outsourcing de desenvolvimento de software e retainers de consultoria de TI para revisões de arquitetura após alterações de emergência.

Deteção e triagem forense

Mensagens CISA e CERT aliados recomendam monitorizar atividade suspeita após patching, não só antes.

Sinais de log e métrica

• Picos 4xx/5xx no web server em corpos POST pequenos ou multipart malformado
• Segfaults de worker PHP-FPM ou contagens rápidas de respawn
• Processos filho inesperados de utilizadores php-fpm ou apache2 (shell, curl para hosts desconhecidos, pipelines base64)
• Novas web shells em diretórios de upload ou árvores vendor/
• Ligações de saída de subnets de app para IPs raros pós-exploit

Indicadores de host

• index.php, .user.ini ou ficheiros autoload modificados
• Entradas cron ou unidades systemd criadas recentemente
• Binários setuid ou ficheiros PHP world-writable

Processo

• Preservar logs antes de rotação; snapshot volumes se incidente suspeito.
• Seguir requisitos organizacionais de triagem forense referenciados em alertas nacionais (ex.: temática CISA BOD 26-04 para contratantes federais define expectativas de patching prioritário e triagem).

Equipas defensivas não devem executar código de exploit público contra produção; use harnesses de teste aprovados pelo vendor em labs isolados se validação for necessária.

Endurecimento de aplicação e plataforma

Para além dos advisories de outubro 2026, reduza superfície de ataque PHP rotineiramente:

• Executar PHP-FPM com utilizadores de pool dedicados por site; evitar mod_php em designs novos quando possível.
• Manter frameworks e dependências Composer atualizados; CVEs não relacionadas permanecem comuns.
• Desativar extensões não usadas em imagens de produção.
• Impor CSP, cookies seguros e proteções CSRF na camada de aplicação (não corrige RCE de engine mas limita abuso subsequente).
• Segregar credenciais de base de dados por serviço; assumir compromisso nos modelos de ameaça.

Equipas a modernizar PHP legacy beneficiam de auditorias de arquitetura antes de refactors grandes. Esquadrões nearshore podem executar remediação sob o vosso change control via desenvolvimento nearshore.

Engenharia de produto em sistemas PHP de faturação e workflow (experiência inclui plataformas como Faturito) reforça validação rigorosa de upload, endurecimento de sessão e cadência de patch como trabalho operacional não negociável.

Comunicação com fornecedores e hosting

Pedidos modelo a fornecedores:

• Confirmar versão de engine PHP por ambiente e timestamp de conclusão de patch.
• Confirmar restart de worker e reload de pool FPM após patch.
• Indicar se mod_php está em uso em frontends partilhados.
• Fornecer timeline para rebuild Windows -1 se aplicável.
• Documentar exposição remanescente para versões PHP embebidas fora do controlo deles.

Escalar SLAs contratuais onde hosting fica atrás de expectativas KEV.

FAQ

Jobs cron CLI são afetados por PHP2Shell?

O advisory crítico de outubro visa instalações que servem pedidos web. Upgrade todos os runtimes por consistência, mas priorização de emergência deve focar pools expostos a HTTP.

Definir memory_limit=-1 aumenta risco de denial-of-service?

Remove um caminho OOM controlado pelo atacante relacionado com CVE-2026-109618 mas não remove todas as falhas de alocação. Combine com limites de corpo no proxy, caps cgroup e patching.

Já patchámos a 22 de outubro; precisamos do rebuild Windows de 26 de outubro?

Se executam PHP oficial para Windows e usam cURL com descompressão Brotli, apliquem rebuilds 8.x.y-1. Estates só Linux podem ainda precisar revisão supply chain libbrotli para CVE-2026-111497.

Devemos desativar PHP totalmente até estar corrigido?

Mensagens CISA para versões não suportadas instam a retirar PHP exposto à Internet vulnerável até remediado. Para branches suportadas, preferir patch rápido mais mitigações a outage prolongado se patch está disponível nas janelas de change.

Como interage com imutabilidade de contentor?

Rebuild imagens com pacotes base corrigidos, roll deployments, verificar PHP_VERSION no arranque do contentor em health checks.

Onde obter ajuda independente de implementação?

Contacto Damascode para planeamento defensivo de remediação, automação de testes em torno de upgrades e capacidade nearshore para backlog de segurança. Não se faz qualquer afirmação sobre descoberta de CVE; sigam orientação primária PHP.net e CERT nacional.

Referências

• Arquivo de notícias PHP.net 2026 (release segurança 21 Out, nota sessão 23 Out, rebuild Windows 26 Out)
• Blog PHP Foundation: visão geral release segurança outubro 2026
• Alerta CISA: vulnerabilidades críticas em PHP exigem patching imediato
• NVD: CVE-2026-109618
• NVD: CVE-2026-109619
• Canadian Centre for Cyber Security: AL26-026 (vulnerabilidades críticas PHP)
• CERT-EU security advisory 2026-018
• Consultoria de TI Damascode
• Auditoria de arquitetura e dívida técnica