php2shell: o RCE crítico no PHP e como corrigir
Em 21 de outubro de 2026 o PHP publicou duas correções de falha crítica. Elas permitem execução remota de código sem autenticação em qualquer aplicação que receba requisições web. As falhas ganharam o apelido php2shell e não são problema de WordPress, AlmaLinux ou painel: são do interpretador. Por isso, quem roda PHP exposto precisa atualizar o pacote e reiniciar o processo.
O que é o php2shell: as duas falhas
A CVE-2026-109618 explora o tratamento de out-of-memory. Quando um request estoura o memory_limit, o PHP aborta com longjmp e, em alguns pontos, a memória do request está só parcialmente inicializada. Assim, a limpeza de fim de request lê esse estado inválido. Além disso, multipart sem Content-Length utilizável, com headers e campos vazios em excesso, chega ao OOM sem estourar os limites declarados de upload.
A CVE-2026-109619 vive entre requests. O worker mantém estado global apontando para memória de um request já liberado. Então o request seguinte usa esse estado antes da inicialização. Os caminhos confirmados, aliás, são o backtrace de erro fatal no PHP 8.5 e o session upload progress. As duas falhas, portanto, recebem 9.2 no CVSS v4.0.
Quem está exposto
Toda instalação PHP que atende web: mod_php, PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. O risco maior, contudo, é no mod_php, com exploit completo por HTTP nos limites padrão, antes de qualquer código da aplicação. No FPM a análise aponta suscetibilidade na primeira falha, sem exploit completo demonstrado. Na segunda, o caminho de session foi validado em mod_php e FPM.
Não é preciso formulário de upload: o parser multipart roda antes do script, então qualquer .php serve de entrada. Mas atualizar o CMS não fecha essa porta. O WordPress 7.1.3, por exemplo, corrigiu falhas do core. O PHP, porém, segue exposto se o pacote não for atualizado.
Como corrigir o php2shell: versões e pacotes
O PHP corrigiu nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As branches 8.1 e anteriores estão fora de suporte, mas receberam backports para 7.4, 8.0 e 8.1.
No Ubuntu, os pacotes saíram para todas as releases suportadas:
sudo apt update && sudo apt upgrade apt list '?installed ?name(^php[0-9.]+$)' sudo systemctl restart apache2
Troque apache2 por php8.x-fpm em site com FPM.
No AlmaLinux e na família RHEL:
sudo dnf clean metadata && sudo dnf upgrade 'php*' sudo systemctl restart php-fpm rpm -q php-common
No AlmaLinux 8 com mod_php, reinicie o httpd. Os streams php:7.2, 7.3 e 8.0 no AlmaLinux 8 e o 8.1 no 9 saíram do ciclo. Todos, porém, receberam patch. O 7.2 ainda é o padrão no AlmaLinux 8. No Remi não havia atualização no dia do anúncio, então o PHP recomenda pacote da distro ou build da fonte.
Em contêiner e painel, a versão vem da imagem: rebuild resolve.
Se não der para atualizar agora
Só a atualização é mitigação completa do php2shell, mas algumas configurações fecham caminhos conhecidos.
memory_limit=-1porphp_admin_valueno pool do FPM ou no Apache, sem nenhum pool repor limite finito. –post_max_size=8Msem upload e32Mcom upload, comupload_max_filesizemenor. –session.upload_progress.enabled=0e, no PHP 8.5,fatal_error_backtraces=0, com reinício de todos os workers. Para isso, use php.ini ou pool, nuncaini_set(). – Bloquear multipart no proxy quando a aplicação não usa upload, e não usarRLIMIT_ASnemRLIMIT_DATA, que levam ao caminho vulnerável.
O ISPConfig publicou um guard para nginx e Apache que barra multipart antes do PHP. Serve como emergência, com o custo de derrubar upload nos sites bloqueados.
Como confirmar
Em distro com backport, php -v mostra o número antigo. Por isso, confira pelo pacote: rpm -q php-common no AlmaLinux, dpkg -l | grep php no Ubuntu e Debian. Depois, reinicie o serviço e confirme os workers novos.
Conclusão
O php2shell é falha de infraestrutura, não de CMS, e dispensa autenticação. Atualize o pacote, reinicie o worker e confirme a versão no gerenciador, não no php -v. Mitigação de configuração compra tempo até o patch entrar.
Fonte: https://www.php.net/archive/2026.php#2026-10-21-5
