O que exige resposta
A CVE-2026-109618 envolve o processamento de requisições e uma condição de estado parcial em cenários de limite de memória. A CVE-2026-109619 envolve estado global residual e uso após liberação. Em condições específicas, ambas podem levar à execução remota de código sem autenticação.
O risco depende do modo de execução e da configuração: mod_php tem o cenário mais exposto documentado; PHP-FPM também requer atenção, pois a exploração pode depender do ciclo da aplicação. CGI, FrankenPHP e LiteSpeed também devem entrar no inventário. Não trate FPM como uma barreira suficiente.
- Priorize servidores PHP acessíveis pela internet.
- Atualize para uma versão corrigida ou para o backport do fornecedor.
- Reinicie o serviço PHP e recicle os workers.
- Revise logs de erro, acesso e processos em busca de comportamento anômalo.
Versões upstream corrigidas
Use a matriz abaixo para builds oficiais do PHP. Distribuições Linux, painéis de hospedagem e imagens de contêiner podem publicar backports com uma numeração de pacote diferente: confira o boletim do fornecedor.
| Ramo PHP | Vulnerável antes de | Versão corrigida | Ação |
|---|---|---|---|
| 8.5 | 8.5.12 | 8.5.12 | Atualizar |
| 8.4 | 8.4.27 | 8.4.27 | Atualizar |
| 8.3 | 8.3.36 | 8.3.36 | Atualizar |
| 8.2 | 8.2.35 | 8.2.35 | Atualizar |
| 8.1 e anteriores | Fim de vida upstream | Backport do fornecedor ou migração | Planejar correção imediata |
Frameworks: o que está corrigido, de fato?
Essas CVEs estão no núcleo do PHP, não em WordPress, Laravel, Symfony, Drupal ou Magento. Portanto, não existe uma versão específica do framework que corrija esta vulnerabilidade. A correção é executar o framework sobre um runtime PHP corrigido.
WordPress e WooCommerce
Atualize o PHP do servidor para a matriz acima. Atualizações de core, temas e plugins continuam necessárias, mas não corrigem PHP2Shell.
Laravel e Symfony
Atualize o PHP-FPM/CLI usado pelo pool real da aplicação. composer update por si só não altera o binário PHP.
Drupal, Magento e MediaWiki
Valide a versão do PHP do processo web, não apenas a versão mostrada pelo painel. Confirme compatibilidade antes da mudança de ramo.
Hospedagem gerenciada
Peça a confirmação do pacote corrigido e da reinicialização do pool. Em cPanel/EasyApache, valide o pacote da versão de PHP ativa.
Hardening enquanto o patch é aplicado
Estas medidas reduzem exposição operacional; nenhuma substitui o patch de estado completo.
- Reduza a exposição: limite temporariamente endpoints públicos não essenciais, uploads e superfícies administrativas.
- Evite configuração por requisição: remova ou restrinja alterações de configuração PHP por
.htaccesse caminhos equivalentes quando usarmod_php. - Mitigações documentadas: no PHP 8.5,
fatal_error_backtraces=0reduz o caso confirmado;session.upload_progress.enabled=Offreduz um caminho demonstrado. Ambas exigem reinício e são incompletas. - Aplique no nível certo:
session.upload_progress.enabledéINI_PERDIR. Defina-o nophp.iniou na configuração do servidor/pool e reinicie o PHP. Não dependa deini_set(): o progresso de upload é tratado antes de o script da aplicação executar. - Isole o legado: mantenha aplicações sem patch em rede segregada, com mínimo privilégio, filesystem somente leitura quando possível e credenciais rotacionadas.
- Observabilidade: preserve logs de acesso, erros do PHP, WAF e processo; procure picos de falhas, uploads incomuns e execução inesperada.
- Controle de borda: aplique limites de requisição e tamanho de upload no proxy/WAF, sem depender disso como correção.
- Comprove a mudança: registre versão antes/depois, pacote do fornecedor, reinício do serviço e verificação pós-deploy.
Verificação local
Analise um arquivo de inventário
Envie um phpinfo() exportado, saída de php -v, lista de pacotes ou configuração. A leitura ocorre somente neste navegador; o arquivo não é enviado ao Vulcan Atlas.
O arquivo permanece no seu dispositivo.
O resultado identifica versões reconhecíveis e sinais de mitigação. Ele não executa o arquivo, não testa exploração e não comprova que o serviço em produção usa a mesma configuração.
Local Scan
Inventarie o PHP no próprio ambiente
Quando o cabeçalho público não revela a versão real, execute o agente no host autorizado. Ele compara o runtime local com a matriz PHP2Shell, gera evidência JSON e não transmite dados.
Verificação de exposição
Verifique um domínio com o Vulcan Atlas
O fluxo usa um GET padrão, valida até quatro redirecionamentos públicos e inspeciona cabeçalhos e até 16 KB de HTML público. Não envia payloads e não explora a vulnerabilidade.
Uma versão oculta ou um resultado sem alerta não confirma segurança. Valide pacote, backport, reinício do PHP e logs do ambiente.