PHP: duas falhas críticas CVE-2026-109618 e CVE-2026-109619 permitem execução remota de código

Em 21 de outubro de 2026, o projeto PHP publicou uma atualização emergencial para duas vulnerabilidades críticas: CVE-2026-109618 e CVE-2026-109619. Ambas podem permitir execução remota de código sem autenticação, com CVSS v4.0 9,2/10 cada. As primeiras versões corrigidas são 8.2.35, 8.3.36, 8.4.27 e 8.5.12. O risco é mais alto no Apache com mod_php, mas PHP-FPM e outras formas de executar PHP também entram no escopo de avaliação.

O que aconteceu

CVE-2026-109618 — corrupção ao faltar memória: o PHP podia abandonar a inicialização de uma requisição após uma falha de alocação de memória e, durante o encerramento, usar estruturas internas parcialmente inicializadas como se fossem válidas. A análise oficial demonstra uma cadeia de execução de código pelo HTTP sem login em mod_php, antes mesmo de o código da aplicação começar. Requisições multipart especialmente construídas podem atingir a condição mesmo dentro de limites aparentes de tamanho. Em PHP-FPM há suscetibilidade indicada pela análise de código após a inicialização, embora o advisory não declare uma exploração completa demonstrada para esta CVE nesse SAPI.

CVE-2026-109619 — estado obsoleto entre requisições: informações de sessão, erro ou extensão, pertencentes à memória de uma requisição, podiam permanecer em variáveis globais de um worker após essa memória ser liberada. Outra requisição atendida pelo mesmo processo podia acessar o ponteiro antigo antes da reinicialização normal, causando use-after-free. O fornecedor confirmou cadeias de execução de código no mod_php e uma cadeia dependente de operação da aplicação no PHP-FPM. A funcionalidade de progresso de upload de sessão, ativada por padrão, participa de uma das rotas confirmadas; no PHP 8.5, o recurso de backtrace de erro fatal participa de outra.

As duas CVEs são falhas no interpretador PHP, não em um plugin WordPress específico. Atualizar o WordPress, trocar de tema ou desativar um plugin não corrige o binário PHP vulnerável. Inversamente, um servidor sem PHP atendendo requisições web não fica exposto por estas rotas HTTP; confirme o inventário antes de concluir.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

O aviso oficial inclui PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed/LSAPI. O exploit demonstrado antes da aplicação torna mod_php especialmente urgente; FPM não deve ser considerado imune, pois há cadeia validada para a outra CVE e cenários condicionais para ambas. Em cPanel/CloudLinux, o mesmo host pode oferecer vários ramos EA-PHP e Alt-PHP, pools FPM e aplicações em versões diferentes. Um pacote com número upstream antigo pode estar corrigido por backport, mas isso exige evidência do advisory e release do fornecedor; o contrário, uma versão CLI nova, não prova que todos os sites usam o binário novo.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Crítico — CVSS v4.0 9,2/10 para cada CVE, segundo os avisos do projeto PHP. A consequência confirmada é execução de código com os privilégios do processo web, potencialmente permitindo leitura de configurações, credenciais e bancos acessíveis à conta, alteração de arquivos e persistência. Isso não equivale automaticamente a root; o alcance depende da identidade do worker, permissões e isolamento entre contas. A exploração completa foi demonstrada em mod_php e, para a segunda CVE, em uma cadeia de PHP-FPM; não é correto afirmar que toda combinação de SAPI, extensão e aplicação já tenha um exploit público funcional. Mesmo sem sinal conhecido de ataque, a superfície HTTP e a ausência de mitigação completa justificam prioridade imediata.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Liste todos os binários e pacotes PHP instalados, compare a linha com a tabela e identifique a versão realmente usada por cada domínio e pool. Em cPanel, confira MultiPHP Manager e EasyApache 4; em CloudLinux, inclua Alt-PHP/Selector e CageFS. O comando php -v consulta apenas o CLI em PATH: não é prova da versão do site. Para pacotes com backport, peça o advisory do repositório e confirme no changelog/release se as duas CVEs foram corrigidas. Não publique um arquivo phpinfo() aberto ao público, porque ele pode expor caminhos e configuração.

php -v
command -v php
rpm -qa | grep -E '^(ea-php|alt-php|php[0-9]*-)' | sort
for bin in /opt/cpanel/ea-php*/root/usr/bin/php; do [ -x "$bin" ] && "$bin" -v | head -1; done
ps -eo user,pid,lstart,comm,args | grep -E '[p]hp-fpm|[l]sphp|[h]ttpd' | head -40
# Exemplo: troque pelo pacote que serve o domínio investigado
rpm -q --changelog ea-php84-php-cli 2>/dev/null | grep -E 'CVE-2026-109618|CVE-2026-109619' | head

Sem backport comprovado, qualquer ramo abaixo do primeiro release corrigido continua no intervalo afetado. Uma linha EOL precisa de migração ou suporte explícito do fornecedor. Se o RPM/changelog não mencionar as CVEs, isso não prova vulnerabilidade nem correção: consulte o advisory do fornecedor e, se necessário, abra chamado. Verifique a versão do SAPI de cada site por uma ferramenta administrativa autenticada ou um diagnóstico temporário restrito, removido imediatamente depois. Confirme também que workers antigos não permaneceram em execução após a instalação.

Como corrigir ou mitigar

A única correção completa é instalar versões que contenham os patches de ambas as CVEs e reiniciar os workers/serviços aplicáveis para carregar o novo binário. Use o repositório oficial do seu sistema, painel ou fornecedor LTS e teste compatibilidade de extensões, aplicações e pools. Para EA-PHP/Alt-PHP, confirme primeiro que o fornecedor publicou um build corrigido; não troque pacotes de origem por RPMs aleatórios nem presuma que upcp sozinho atualiza todas as versões PHP disponíveis. PHP 8.2 deve ter plano de migração antes do fim do suporte upstream em 31/12/2026. Se não puder atualizar imediatamente, as medidas abaixo são contenção parcial, não declaração de segurança: para a CVE-2026-109618, o projeto recomenda impor memory_limit=-1 administrativamente e limitar requisições multipart, post_max_size, campos e cabeçalhos; isso pode elevar consumo de memória e risco de indisponibilidade, exigindo capacidade e limites por cgroup. Para a CVE-2026-109619, desative session.upload_progress.enabled na configuração aplicada antes do parsing e, no PHP 8.5, fatal_error_backtraces; reinicie todos os workers. ini_set() e .user.ini do FPM não são suficientes para a rota pré-inicialização. Elimine diretivas inválidas/obsoletas e erros fatais acessíveis ao atacante. Não use RLIMIT_AS ou RLIMIT_DATA como substitutos de limite: eles podem provocar precisamente a falha de alocação vulnerável.

# Em servidores EL/cPanel/CloudLinux, consulte atualizações dos repositórios oficiais
dnf check-update 'ea-php*' 'alt-php*'
# Após instalar os builds corrigidos pela rotina suportada do fornecedor:
rpm -qa | grep -E '^(ea-php|alt-php|php[0-9]*-)' | sort
ps -eo pid,lstart,comm,args | grep -E '[p]hp-fpm|[l]sphp|[h]ttpd' | head -40

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Valide sites de teste em cada versão/SAPI, uploads, sessão, login, e-commerce, filas e extensões após atualizar e reiniciar. Repita a consulta de versão por domínio, confirme build/release do fornecedor e compare horário de início dos workers com o horário do patch. Revise logs de PHP-FPM/Apache/LiteSpeed e WAF em busca de requisições multipart anômalas, erros de memória, encerramentos de worker, falhas fatais e padrões repetidos; ausência de registros não comprova ausência de exploração. Se houver indicador, preserve evidências, restrinja acesso e investigue arquivos, credenciais, tarefas e bancos alcançáveis pelo usuário do processo web antes de restaurar. Evite executar uma prova de conceito em produção.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Em planos com gerenciamento contratado, a WebinHost prioriza inventário dos SAPIs e ramos PHP, acompanha os pacotes corrigidos do painel/distribuição, agenda atualização e reinício dos workers e valida os sites e serviços cobertos. A equipe pode ajudar a revisar logs e isolar incidentes. Imunify360 acrescenta WAF, detecção de malware e defesa de aplicações; CloudLinux/CageFS ajuda no isolamento entre contas. Essas camadas podem reduzir impacto, mas não demonstram que esta falha do interpretador foi corrigida. KernelCare é tecnologia de livepatch de kernel e não substitui o patch do PHP. Não afirmamos que todos os servidores ou sites dos clientes já foram corrigidos sem validação individual do build e do serviço ativo.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Referências oficiais e técnicas

• PHP.net — aviso emergencial de 21/10/2026 e releases corrigidos
• PHP Security — CVE-2026-109618 (OOM)
• PHP Security — CVE-2026-109619 (estado global obsoleto)

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.