Mitigação da CVE-2026-109618: medidas temporárias (workarounds) do PHP2Shell e seus limites

Existe uma mitigação para a CVE-2026-109618 e a CVE-2026-109619?

Só parciais, e nenhuma delas é uma correção. O boletim do PHP diz que apenas a atualização é uma solução completa e que as medidas abaixo reduzem a exposição a caminhos de ataque específicos, mas não deixam a instalação segura. Para a CVE-2026-109619, o boletim do GitHub acrescenta que não existe uma mitigação genérica e completa por configuração. Use estas configurações só para ganhar tempo até instalar a correção do PHP2Shell.

Quais são as medidas temporárias oficiais?

Todas essas configurações só valem depois de reiniciar todos os processos (workers) do PHP. O PHP também avisa: não troque por limites RLIMIT_AS ou RLIMIT_DATA, que podem justamente provocar a falha de alocação vulnerável, e esconder erros com error_reporting, display_errors ou @ não ajuda.

Como aplico corretamente a medida do session.upload_progress?

A configuração precisa valer antes de o PHP processar a requisição:

1. Defina session.upload_progress.enabled=0 no php.ini, na configuração do pool do PHP-FPM ou na configuração do servidor web.
2. Não use ini_set() no código nem um arquivo .user.ini do FPM; eles entram em ação tarde demais.
3. Reinicie todos os workers do PHP (todos os pools do PHP-FPM, ou o Apache no caso do mod_php). Workers que não foram reiniciados continuam com as configurações antigas.

Em hospedagem compartilhada, normalmente você não consegue mudar essas configurações; peça ao seu provedor ou instale a correção por meio dele.

“Meu site não tem upload” serve como mitigação?

Não. Os caminhos de ataque estão no tratamento de requisições do próprio PHP, não no formulário de upload do seu site, então um site sem upload não está automaticamente seguro. É por isso que a configuração oficial é uma opção do PHP no nível do servidor, e não uma chave da aplicação.

Um WAF como o da Cloudflare conta como mitigação?

Não. É uma camada extra, não uma correção. A Cloudflare ativou regras de WAF automaticamente em todos os planos com WAF, inclusive o Free, cerca de nove horas antes da divulgação, e relatou que atacantes estavam modificando os payloads para contorná-las. Um WAF só filtra o tráfego que passa por ele, e o PHP do seu servidor continua vulnerável. Mais detalhes em PHP2Shell e Cloudflare e regras de WAF para o PHP2Shell.

Um plugin de modo de manutenção funciona como mitigação?

Não de forma confiável. A própria página de manutenção do WordPress é servida pelo PHP, e alguns caminhos de ataque acontecem antes de o código da aplicação rodar. Para cortar a exposição sem aplicar o patch, bloqueie as requisições antes que cheguem ao PHP ou tire o site do ar, como várias agências nacionais recomendaram para sites que não podem ser atualizados.

Por quanto tempo posso contar com uma mitigação?

Só até conseguir atualizar, de preferência questão de dias. As correções e as análises técnicas são públicas, e a Sansec espera exploração em massa. Planeje a atualização agora. Veja em que pé você está com o verificador PHP2Shell e leia as páginas da CVE-2026-109618 e da CVE-2026-109619 para os detalhes de cada falha.

Quais fontes embasam esta página?

• The PHP Group: boletim de segurança com as mitigações
• Boletim do GitHub GHSA-w8hw-w9fx-j79w
• Boletim do GitHub GHSA-6wmf-4rv5-p3rp
• Cloudflare: proteções do WAF
• Sansec: pesquisa sobre o PHP2Shell