Blog

Boletim técnico · 22 de outubro de 2026

Respondendo às vulnerabilidades centrais do PHP CVE-2026-109618 e CVE-2026-109619

As duas falhas, divulgadas como PHP2Shell, afetam o interpretador PHP. Atualizar CMS, framework ou dependências do Composer não substitui a atualização do runtime PHP.

Prioridade: corrigir o runtime.

Ambientes expostos à internet devem ser inventariados, atualizados e reiniciados. Trate mitigações de configuração como transitórias; elas não substituem o patch completo.

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.

Primeiras horas
  1. Priorize servidores PHP acessíveis pela internet.
  2. Atualize para uma versão corrigida ou para o backport do fornecedor.
  3. Reinicie o serviço PHP e recicle os workers.
  4. 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 PHPVulnerável antes deVersão corrigidaAção
8.58.5.128.5.12Atualizar
8.48.4.278.4.27Atualizar
8.38.3.368.3.36Atualizar
8.28.2.358.2.35Atualizar
8.1 e anterioresFim de vida upstreamBackport do fornecedor ou migraçãoPlanejar 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 .htaccess e caminhos equivalentes quando usar mod_php.
  • Mitigações documentadas: no PHP 8.5, fatal_error_backtraces=0 reduz o caso confirmado; session.upload_progress.enabled=Off reduz um caminho demonstrado. Ambas exigem reinício e são incompletas.
  • Aplique no nível certo: session.upload_progress.enabled é INI_PERDIR. Defina-o no php.ini ou na configuração do servidor/pool e reinicie o PHP. Não dependa de ini_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.

Sem upload
Selecione ou solte o arquivo aquiAté 1 MB · texto, log, configuração ou inventário

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.

Baixar pacote multiplataformaPacote Linux (.tar.gz)

Verificação de exposição

Verifique um domínio com o Vulcan Atlas

O fluxo valida até quatro redirecionamentos públicos, lê cabeçalhos por GET e, quando necessário, HEAD, além de uma amostra HTML pública limitada a 64 KB. 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.

Referências para validação