Em resumo: Muitas dicas sobre o PHP2Shell que circulam atualmente em fóruns e redes sociais não protegem ou até prejudicam: bloquear pedidos com cookie de sessão, esconder mensagens de erro, aplicar definições através de .user.ini ou atualizar apenas o CMS. O php.net é claro: não há medidas provisórias completas, e a atualização do PHP com reinício de todos os processos é o único caminho seguro.
Porque são perigosas as falsas dicas nesta situação
Perante uma vulnerabilidade crítica com muita atenção, surge um mercado de soluções rápidas. Os conselhos são partilhados, abreviados e reencaminhados, muitas vezes sem as restrições da fonte original. No PHP2Shell acresce que, segundo notícias, os pormenores se tornaram conhecidos antes da data oficial e que a situação nos primeiros dias era pouco clara.
Uma falsa dica prejudica duplamente. Deixa a vulnerabilidade aberta e cria a sensação de se ter feito algo. É precisamente essa sensação que leva a que a verdadeira atualização fique por fazer. Alguns conselhos paralisam ainda o próprio site.
Nove conselhos em teste de factos
A tabela seguinte resume o que lemos com frequência nos últimos dias e contrapõe-lhe as afirmações das fontes primárias.
| Dica em circulação | Porque não se sustenta | O que vale em vez disso |
|---|---|---|
Bloquear todos os pedidos com PHPSESSID |
Rejeitada expressamente por autores especializados; paralisa autenticações e carrinhos de compras | Atualizar o PHP |
session.upload_progress.enabled=0 basta |
Segundo relatos especializados, não fecha ambas as vulnerabilidades | Medida provisória sensata, a atualização continua obrigatória |
Definir valores através de ini_set() ou .user.ini |
O php.net desaconselha-o expressamente | No servidor, em php.ini, no pool FPM ou na configuração do servidor |
| Esconder mensagens de erro | Segundo o php.net, error_reporting, display_errors ou @ não ajudam |
Atualização; não mostrar a saída de erros ao público, de qualquer modo |
Limitar a memória através de RLIMIT_AS ou RLIMIT_DATA |
O php.net avisa que precisamente isso pode desencadear a situação vulnerável | Limite através do contentor ou cgroup |
| Atualizar o WordPress ou os plugins | A vulnerabilidade está no interpretador PHP, e não no CMS | Atualizar o tempo de execução PHP |
| A Cloudflare ou outra WAF basta | Proteção apenas para o tráfego que passa pelo serviço; servidores diretamente acessíveis continuam abertos | WAF como camada adicional, e não como substituto |
| Recarregar o serviço em vez de o reiniciar | Segundo a Red Hat, um reload não basta, os workers existentes podem manter o estado antigo | Reiniciar por completo todos os workers |
| Com patch significa limpo | Um patch não remove software malicioso introduzido antes | Guardar registos desde 20/10 e procurar vestígios |
Os três equívocos mais frequentes explicados em pormenor
A proibição de cookies
A dica de recusar todos os pedidos com o cookie de sessão PHPSESSID soa técnica e decidida. Autores especializados rejeitam-na expressamente. Na prática, quebra tudo o que precisa de uma sessão: contas de clientes, carrinhos de compras, áreas de administração, formulários com proteção contra falsificação. Não é uma proteção contra a vulnerabilidade.
A única definição que resolve tudo
session.upload_progress.enabled=0 consta das recomendações do php.net e é a medida de atenuação indicada para a CVE-2026-115560. Em alguns artigos, isso transformou-se em “PHP2Shell desligado”. Segundo relatos especializados, esta definição, por si só, não fecha ambas as vulnerabilidades. Também o memory_limit=-1 elimina, segundo o php.net, apenas o gatilho controlável; um erro de memória a um nível mais profundo pode continuar a alcançar o caminho vulnerável. No PHP 8.5, fatal_error_backtraces=0 bloqueia, segundo o php.net, apenas o caminho confirmado através de backtraces.
Como definir a configuração, ainda assim, de forma correta e duradoura é descrito no artigo Desativar o session.upload_progress. A lista completa das medidas provisórias encontra-se em Medidas imediatas sem patch.
O escudo à frente
A Cloudflare tem, segundo as suas próprias declarações, desde 21 de outubro regras de proteção ativas, também para clientes do plano gratuito. A própria Cloudflare chama, no entanto, a atenção para limites: a proteção só atua no tráfego que passa pela Cloudflare. Se o servidor de origem for diretamente acessível, é contornada. Além disso, a Cloudflare verifica também a resposta do servidor, porque o pedido sozinho nem sempre basta. Porque é que uma WAF não substitui a atualização é explicado no artigo WAF ou atualização.
Uma dica com risco: filtrar pedidos de upload na periferia
Nem todo o conselho incómodo é falso. Autores especializados propõem, como medida provisória e não oficial, bloquear pedidos multipart/form-data fora de caminhos de upload genuínos no proxy ou na WAF. Isso pode reduzir a superfície de ataque, mas quebra formulários e uploads se a lista de caminhos permitidos estiver incompleta.
Quem seguir este caminho deve testá-lo antes num ambiente de teste, acertá-lo com os departamentos especializados e documentá-lo como medida temporária. Também não é um substituto da atualização.
Muitas soluções WAF oferecem para isso um modo de observação, em que as regras apenas registam em vez de bloquear. Deixe uma nova regra correr assim durante alguns dias e analise que pedidos legítimos seriam afetados. Só depois mude para bloquear. Assim evita que formulários de candidatura, portais de clientes ou o upload de imagens na loja deixem de funcionar sem que se dê por isso.
Como verificar uma dica antes de a aplicar
Quatro perguntas separam os conselhos utilizáveis dos perigosos:
- Fonte: A recomendação vem do php.net, da sua distribuição, do BSI (Gabinete Federal Alemão para a Segurança da Informação) ou de um autor especializado identificado pelo nome?
- Pretensão: A medida é descrita como transição ou como solução? No PHP2Shell, só a atualização é uma solução.
- Efeito secundário: O que se quebra quando a medida atua? Uma dica sem indicação de efeitos secundários é incompleta.
- Local de aplicação: A definição é feita no servidor e de forma não sobreponível, seguida de um reinício de todos os workers?
Registe que medidas provisórias aplicou e quando. Assim pode verificá-las mais tarde de forma direcionada e reconhecer se uma suposta proteção adiou a verdadeira atualização.
Como ajuda concretamente a PHP SOS?
- Verificamos as medidas que já foram aplicadas no seu caso e separamos as eficazes das ineficazes.
- Aplicamos a atualização do PHP, reiniciamos todos os processos e comprovamos o estado.
- Onde uma atualização ainda não é possível, aplicamos medidas provisórias segundo o php.net, no servidor e de forma documentada.
- Com WAF e patching virtual complementamos a proteção na periferia, sem substituir a atualização.
Perguntas frequentes
Protege bloquear pedidos com PHPSESSID?
Não. Autores especializados rejeitam expressamente esta dica em circulação. Paralisa autenticações, carrinhos de compras e formulários, sem fechar a vulnerabilidade no interpretador.
Basta session.upload_progress.enabled=0 contra o PHP2Shell?
Não. A definição é uma de várias medidas provisórias e, segundo relatos especializados, não fecha ambas as vulnerabilidades. Faz sentido, mas não substitui a atualização do PHP.
Ajuda desativar o display_errors?
Para o PHP2Shell, não. O php.net chama a atenção para o facto de ocultar diagnósticos através de error_reporting, display_errors ou do operador @ não ajudar. Em produção, o display_errors deve, ainda assim, estar desativado por outras razões.
Como reconheço uma dica séria?
Uma dica séria indica a sua fonte, descreve limites e identifica as medidas provisórias como tal. Quem promete que uma única definição torna a atualização dispensável está errado no caso do PHP2Shell.