PHP2Shell: RCE Crítico no PHP e Como Corrigir

Índice

• 1. O que é o PHP2Shell
• 2. Quem está exposto
• 3. Verificar a versão do PHP
• 4. Aplicar a correcção
• 5. Se ainda não pudes actualizar
• 6. Saberes se tentaram atacar
• 7. Linha temporal
• Veredicto

1. O que é o PHP2Shell

O nome PHP2Shell vem do script de exploração que os investigadores da Wiz Research montaram para provar RCE sem autenticação contra o WordPress, o Drupal e o Joomla mais recentes. O tema, porém, é da linguagem: são duas CVEs no interpretador PHP, causadas por erros de segurança de memória quando o PHP lida com erros fatais — sobretudo o esgotamento de memória (OOM) — durante o processamento de pedidos.

A mecânica essencial: um erro fatal pode deixar estado interno corrompido para trás quando o pedido termina abruptamente. O próximo pedido servido pelo mesmo worker reutiliza esse estado velho como se fosse vivo. Pedidos multipart (formulários e upload de ficheiros) sabem disparar a condição, e a funcionalidade de progresso de upload de sessão — activa por omissão — pode consumir o estado velho mesmo que a aplicação nunca chame session_start().

Na via da divulgação de memória, o que sai pode ser tudo o que o worker do PHP tem em memória: palavras-passe de base de dados, chaves de API, cookies de sessão, dados de pedidos de outros utilizadores, certificados. Não precisa de execução de código, por isso é mais silenciosa e mais difícil de notar.

A parte mais recente da história: o código vulnerável existia há mais de uma década (o Wiz aponta ao menos até ao PHP 5.4). Tinha sido visto e descartado porque transformar os bugs num exploit real exigia encadear várias falhas e adaptá-las ao mapa de memória de cada versão e aplicação — um esforço que a Wiz diz ser quase proibitivo para humanos, e que os seus modelos fronteira (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol) encurtaram para dias. A Calif e a OpenAI Codex Security chegaram às mesmas falhas de forma independente, e a equipa do PHP juntou tudo em duas CVEs.

2. Quem está exposto

Toda a instalação de PHP que sirva pedidos web numa versão afectada — o bug está no interpretador, não na aplicação. O WordPress, o Joomla, o Drupal, o MediaWiki, o Nextcloud, o Moodle, o Magento, o Laravel e o Symfony aparecem na lista, mas qualquer site serve. O que muda de caso para caso é a via de exploração:

3. Verificar a versão do PHP

Nota importante antes de actualizar: no Debian, no Ubuntu, no RHEL e no SUSE, os backports de segurança não mudam o número de versão do upstream — um PHP «8.3.6-0ubuntu0.24.04» corrigido fica com o mesmo número. Consulta o changelog do pacote pelo CVE:

# Debian / Ubuntu: número de versão + changelog
php -v
apt list --installed | grep -E '^php8'
zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -ai -A2 109618

# RHEL / AlmaLinux / Rocky: o changelog do RPM
rpm -q php
rpm -q --changelog php | grep -ai -A2 109618

# Docker/containers: versão no runtime de cada serviço
docker exec meu-wordpress php -v

Se o changelog do pacote mencionar CVE-2026-109618 ou 109619, a tua distro já mandou a correcção — só precisas do restart. Nos hosts partilhados, pergunta à operadora qual build de PHP está activa e confirma que o restart do worker foi feito.

4. Aplicar a correcção

No Debian/Ubuntu:

sudo apt update
sudo apt install --only-upgrade php8.3 php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm
sudo systemctl reload apache2    # reinicia os workers do mod_php

No RHEL/AlmaLinux/Rocky (ou o pacote da tua distro, com o nome do teu runtime):

sudo dnf update 'php*'
sudo systemctl restart php-fpm
sudo systemctl reload httpd

Se os sites correm em containers, o princípio é o mesmo: puxa a imagem base com o PHP fixado e recria os containers — actualizar o pacote dentro de um container vivo só toma efeito no reinício:

docker compose pull && docker compose up -d

Uma mudança de comportamento nas versões corrigidas: o limite de memória reforçado termina o processo de imediato quando é atingido, sem correr as shutdown functions. Testa os caminhos com consumo pesado de memória (exportações grandes, relatórios, backups gerados pelo PHP) depois de actualizar.

5. Se ainda não puderes actualizar

O próprio PHP não publicou nenhuma mitigação completa para estas falhas. Mitigações parciais circulam — desactivar o progresso de upload de sessão (session.upload_progress.enabled = 0) é a mais citada, e há quem desligue o OPcache (opcache.enable = 0) — mas nenhuma substitui o patch: cada uma fecha uma via do problema, não as duas (o upload progress não cobre a via do backtrace, nem a confusão de tipos no OPcache). Até instalares a correcção, o que resta é reduzir a exposição e ganhar tempo:

1. Retira o PHP da internet directa ou põe-no atrás de controlos de acesso (VPN, allowlists, regras do firewall) enquanto o patch não chega.
2. Reduz o que um servidor comprometido consegue alcançar: credenciais em memória do worker, acessos a bases de dados, chaves na mesma máquina.
3. Se o teu PHP estiver num branch EOL (7.4/8.0/8.1), verifica se a tua distribuição (RHEL, Ubuntu Pro/ESM, Debian LTS, CloudLinux) tem o pacote corrigido — o CERT-FR francês recomenda isolar sistemas em PHP sem suporte enquanto a migração não chega.

A Cloudflare, a Akamai e a Imperva publicaram regras WAF de emergência (a Cloudflare até activou por omissão no plano gratuito, horas antes da divulgação pública). Os investigadores, porém, registam payloads a mutar para rodear as regras — considera as regras um stopgap que compra tempo, não a correcção.

6. Saber se tentaram atacar

Não há prova de comprometimento público (os grandes players registam tentativas, não invasões confirmadas), mas convém olhar para os sinais. Não podes confiar só nos logs da aplicação: as falhas correm abaixo dela.

• Erros fatais de memória (memory_limit) a seguir a pedidos multipart — sobretudo em datas anteriores ao patch.
• Rajadas de erros HTTP 500 e segfaults nos workers do PHP
• Cookies PHPSESSID invulgarmente compridos ou percent-encoded nos registos de acesso.

E a procura activa vai além da raiz web: novas ou alteradas cron jobs, unidades systemd/timers/init, utilizadores e chaves SSH novas, mudanças no sudoers, LD_PRELOAD, módulos de kernel, e sobretudo mudanças de configuração PHP: auto_prepend_file / auto_append_file definidos, e disable_functions removido.

7. Linha temporal

Veredicto

É raro verem-se duas CVEs no núcleo de uma linguagem que serve cerca de 70% da web, mas o que distingue o PHP2Shell não é o número: a falha já estava vista e descartada há mais de uma década, porque transformá-la em exploit era proibitivo — e os modelos de IA derrubaram essa barreira. O mesmo poder, nota a Wiz, serve a defesa: encontra e valida correcções em dias o que levava meses a equipas inteiras. Para o administrador de PME a leitura é directa: o patch está disponível e só ele resolve. Actualiza hoje o PHP de todos os runtimes (mod_php, FPM, containers, workers), reinicia os processos, e usa a lista de sinais acima para vigiar. Se os teus sites estiverem em PHP sem suporte, a migração para 8.4/8.5 deixou de ser opcional — é o teu caminho de saída.

Artigos Relacionados

• Checklist de Hardening para Servidores Linux (2026)
• CrowdSec: um IPS Comunitário nos Servidores
• Nginx Rate Limiting: Protecção Contra Abusos
• Monitorix: Monitorização Leve em Linux

Fontes Oficiais

• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Wiz Research)
• PHP2Shell FAQ (Last reviewed 2026-10-22)
• Today's PHP security release and how we're strengthening PHP security (PHP Foundation, 21/10/2026)
• Cloudflare: mitigação WAF por omissão para as vulnerabilidades do PHP
• Amazon threat intelligence: exploitation attempts before public disclosure (MadPot, 17/10/2026)
• CERT-EU Security Advisory 2026-018
• CERTFR-2026-ALE-014 — alerta PHP2Shell (CERT-FR, França)
• Orientação operacional PHP2Shell (NCSC NL)