Vulnerabilidade PHP2Shell: atualizar o PHP hoje, falhas RCE já exploradas
Duas falhas críticas do PHP, CVE-2026-109618 e CVE-2026-109619, permitem executar código sem autenticação e já estão a ser exploradas. As versões corrigidas saíram a 21 de outubro.
A vulnerabilidade PHP2Shell são, na verdade, duas falhas críticas da linguagem PHP, CVE-2026-109618 e CVE-2026-109619, que permitem a um atacante sem credenciais executar código num servidor web. O projeto PHP lançou as versões corrigidas a 21 de outubro de 2026 e os primeiros ataques foram observados no mesmo dia. Se um servidor seu, ou de um cliente, executa PHP, deve ser atualizado hoje.
O projeto PHP recebeu os primeiros relatórios a 11 de agosto de 2026. A Amazon Threat Intelligence reportou uma tentativa de exploração a 17 de outubro, antes da divulgação pública. A 20 de outubro, os detalhes vazaram na internet antes da data acordada, e o PHP antecipou a versão de emergência para 21 de outubro. Nesse dia, a watchTowr observou exploração ativa na sua rede de honeypots.
A CVE-2026-109618 está na gestão dos erros de falta de memória: se o PHP fica sem memória ao preparar os dados do pedido, esses dados ficam parcialmente inicializados e a limpeza final trata-os como válidos. A CVE-2026-109619 é um erro de estado global não reposto que conduz a um use-after-free no heap, com leitura de memória e execução de código. Ambas permitem a execução remota de código, sem autenticação, com os privilégios da conta do servidor web. Os avisos dos fornecedores de segurança classificam-nas com 9,2 no CVSS v4.0.
Todas as instalações de PHP que servem pedidos web estão abrangidas: Apache com mod_php, PHP-FPM, php-cgi, LiteSpeed e FrankenPHP. O projeto PHP considera o risco mais elevado no mod_php, porque o ataque pode ter êxito antes de qualquer código da aplicação ser executado. Pela mesma razão, uma firewall aplicacional ou um agente RASP dentro do processo PHP pode não o travar.
Vulnerabilidade PHP2Shell: que versões do PHP são seguras
PHP 8.5: atualizar para a 8.5.12.
PHP 8.4: atualizar para a 8.4.27.
PHP 8.3: atualizar para a 8.3.36.
PHP 8.2: atualizar para a 8.2.35.
PHP 8.1, 8.0 e 7.4: sem versão oficial. Existem backports mínimos apenas como código-fonte, ou como pacotes de distribuições e de fornecedores LTS.
PHP 7.3 e anteriores, incluindo o PHP 5: sem correção, é preciso migrar para um ramo suportado.
As distribuições Linux corrigem muitas vezes uma falha sem alterar o número da versão: convém consultar o changelog do pacote, e não apenas o resultado de php -v.
Rumor
O que se diz
As fontes divergem quanto ao estado do exploit. Alguns investigadores afirmam que as duas falhas já estão encadeadas num único script funcional e que existem análises e uma ferramenta públicas. A Huntress escreveu que não reproduziu uma prova de conceito, e a JFrog avisou que circulam falsos exploits. Quem descarregar de um fórum um suposto exploit do PHP2Shell arrisca-se a instalar malware.
A 22 de outubro, as falhas não constavam do catálogo KEV da CISA, segundo a watchTowr. O Centro Nacional de Cibersegurança do Reino Unido (NCSC) pediu às organizações que atualizem de imediato ou que desliguem os sistemas expostos. A VirusTotal estima que mais de 5,1 milhões de hosts PHP estejam acessíveis a partir da internet.
Porque é importante
Quem gere a informática de uma PME ou de vários clientes sabe que o PHP não está apenas nos sites que desenvolveu. Está no WordPress, no Joomla, no Magento, no PrestaShop, em webmails, em antigas aplicações de gestão e em qualquer contentor cuja imagem de base inclua PHP. Um contentor mantém o PHP com que foi construído: é preciso reconstruí-lo, ou obter uma imagem corrigida, e voltar a fazer o deploy.
O que fazer hoje
Fazer o inventário: php -v em cada host e docker exec <container> php -v em cada contentor que serve PHP.
Atualizar para a versão corrigida, ou para o pacote corrigido do fornecedor, e reiniciar o PHP-FPM ou o Apache.
Se não for possível atualizar de imediato, retirar esse sistema do acesso direto à internet.
Como medidas provisórias, que não protegem totalmente: session.upload_progress.enabled=0 e reinício dos workers, um post_max_size baixo (8M, ou 32M se forem necessários uploads) e limites de memória ao nível do contentor.
Rever os registos de acesso desde 17 de outubro e, havendo suspeita de que a memória dos processos foi lida, rodar palavras-passe, tokens e chaves de API.
O projeto PHP é claro: nenhuma configuração mitiga totalmente estas falhas e a atualização é a única defesa duradoura. Para obter ajuda na definição de prioridades e na correção rápida, consulte os nossos serviços de cibersegurança.
Em 5 minutos, veja se a sua empresa está abrangida pela NIS2 e avalie a preparação em gestão de risco e notificação de incidentes. Gratuito, no navegador.
Usamos cookies técnicos para que o site funcione. Com o teu consentimento, usamos também cookies de análise e marketing para melhorar o produto. Podes mudar de ideia a qualquer momento.
01
NecessáriosSempre ativo
Indispensáveis para o funcionamento do site (sessão, preferências, segurança). Sempre ativos.
02
Ajudam-nos a perceber como o site é usado, de forma agregada e anónima.
03
Permitem-nos medir o desempenho das nossas campanhas. Desativados por defeito.
