Pular para o conteúdo

Bilgi Bankası

PHP2Shell: falhas críticas no PHP (CVE-2026-109618 e CVE-2026-109619) e o que fazer  Bu dökümanı yazdır

ALERTA CRÍTICO SEGURANÇA

PHP2Shell: duas falhas críticas no PHP que ameaçam boa parte da web

CVE-2026-109618 e CVE-2026-109619 · CVSS 9.2 · Execução remota de código sem login

⏰ Atualizado em 22/10/2026 com as informações públicas disponíveis até esta data.

‼️ Resumo em 30 segundos

  • Duas falhas no núcleo do PHP permitem que um invasor execute comandos no servidor sem precisar de login.
  • Afetam praticamente toda instalação PHP que atende páginas web, independentemente do site usar WordPress, outro CMS, framework ou código próprio.
  • Já existem ataques reais. Houve tentativa registrada 4 dias antes da divulgação oficial.
  • Correção: atualizar para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou versões mais novas).
  • FBI, CISA, NSA e NCSC (Reino Unido) recomendam atualizar imediatamente ou tirar o sistema do ar até corrigir.

*️⃣ Em números

9.2
nota de gravidade (CVSS v4.0) de cada falha
~70%
dos sites usam PHP, segundo a Cloudflare
2,6 mi
servidores PHP expostos na internet (VulnCheck)
60 mil+
requisições suspeitas bloqueadas pela Pantheon

ℹ️ O que aconteceu

Pesquisadores da Calif, da OpenAI e da Wiz (empresa do Google) encontraram, de forma independente e com ajuda de ferramentas de inteligência artificial, duas falhas graves no núcleo do PHP. Elas foram reportadas em agosto de 2026 e corrigidas em sigilo pela equipe do PHP.

O sigilo não durou até o fim. Os códigos das falhas (CVEs) vazaram em 20 de outubro, um vídeo de prova de conceito circulou e uma empresa publicou pacotes já corrigidos horas antes do combinado, o que permitiu que atacantes estudassem a correção. Por isso a PHP Foundation antecipou a atualização em um dia, para 21 de outubro.

▪️ As duas falhas, em linguagem simples

CVE-2026-109618: quando o PHP fica sem memória no meio de uma requisição, alguns dados internos ficam “pela metade”. Na limpeza, o PHP trata esses dados como válidos, e isso pode ser usado para executar código.

CVE-2026-109619: restos de uma requisição anterior continuam na memória depois de liberados. Uma requisição seguinte pode reaproveitar esse “lixo” antes da limpeza normal, abrindo espaço para execução de código.

⏳ Linha do tempo

11 e 24/08/2026 · Calif e OpenAI (e depois a Wiz) reportam o problema à equipe do PHP.

17/10/2026 · A rede de armadilhas (honeypot) MadPot, da Amazon, registra uma tentativa de exploração, 4 dias antes da divulgação.

20/10/2026 · Os CVEs vazam (com nota errada, 10.0), a PHP Foundation publica um aviso prévio e antecipa a correção. Um vídeo de prova de conceito é publicado por engano.

21/10/2026, 07:41 UTC · A Chainguard publica imagens já corrigidas antes da hora combinada, quebrando o embargo.

21/10/2026, 08:36 UTC · A ELLIO registra a primeira requisição maliciosa, menos de 1 hora depois.

21/10/2026, 14:00 UTC · Lançamento oficial das versões corrigidas. Cloudflare, Pantheon e outras empresas confirmam ataques contra clientes.

⬆️ Qual versão instalar

Atualize para a versão corrigida da sua série (ou mais nova):

PHP 8.5 → 8.5.12 PHP 8.4 → 8.4.27 PHP 8.3 → 8.3.36 PHP 8.2 → 8.2.35
PHP 8.1 ou mais antigo? O projeto PHP não atualiza mais essas versões. Existem correções mínimas (backports) para 7.4, 8.0 e 8.1, e fornecedores como distribuições Linux e a CloudLinux (pacotes ea-php e alt-php do cPanel) liberaram pacotes corrigidos. O ideal é migrar para o PHP 8.2 ou superior.

ℹ️ O que dizem as autoridades

FBI (Divisão Cibernética), no X, em 21/10/2026

“Duas vulnerabilidades críticas foram identificadas no PHP [...] Elas podem permitir que atores maliciosos executem código remotamente no núcleo do PHP.”

Recomendações do FBI:

  • Atualizar o PHP seguindo as instruções do php.net. Se não der para atualizar já, tirar o sistema do ar até corrigir.
  • Fazer um inventário de onde o PHP roda, começando pelos sistemas expostos à internet e por produtos que trazem PHP embutido.
  • Monitorar processos PHP que abrem um terminal (shell) ou baixam arquivos de forma inesperada.
  • Se houver sinais de invasão: isolar o sistema, preservar os logs do servidor web e do PHP e comunicar o caso (nos EUA, ao escritório local do FBI ou ao IC3). Essa orientação foi reforçada por Brett Leatherman, diretor-assistente da Divisão Cibernética do FBI.
  • CISA (EUA) e NCSC (Reino Unido): atualizar imediatamente ou desligar temporariamente os sistemas vulneráveis.
  • NSA (EUA): as falhas podem dar acesso direto aos arquivos e aos bancos de dados do servidor.
  • CERT-EU e a agência australiana de cibersegurança também emitiram alertas. Segundo a Reuters, sites do governo da Finlândia e da França e o Porto de Roterdã saíram do ar por precaução.

⁉️ Como saber se fui atacado

Segundo a CrowdStrike, esse ataque pode deixar poucos rastros: o servidor continua estável, as páginas respondem normalmente (código 200) e os logs da aplicação podem não mostrar nada. Fique atento a:

  • Erros fatais de limite de memória (memory limit) no log de erros do servidor web.
  • Processos PHP abrindo shells (sh, bash) ou baixando arquivos (curl, wget).
  • Arquivos novos ou alterados que você não reconhece, como scripts PHP em pastas de upload.
  • Requisições com o user agent php2shell-scan nos logs de acesso.

A Amazon recomenda investigar sinais de invasão a partir de 17 de outubro, e não só a partir da data da divulgação.

▶️ O que fazer agora

1️⃣ Descubra sua versão. No terminal, rode php -v. No cPanel, veja em Seletor de versão PHP ou MultiPHP Manager.

2️⃣ Atualize. Instale a versão corrigida da sua série. No cPanel ou CloudLinux, atualize os pacotes ea-php e alt-php.

3️⃣ Reinicie. Reinicie o PHP-FPM, o Apache ou o LiteSpeed para a nova versão entrar em uso.

4️⃣ Verifique. Confira os logs desde 17/10 em busca dos sinais acima.

5️⃣ Se não puder atualizar já, considere tirar o site do ar e use as mitigações temporárias abaixo.

Mitigações temporárias (segundo o php.net, elas reduzem o risco, mas não protegem totalmente. A única correção completa é atualizar):

  • No php.ini ou no pool do FPM: session.upload_progress.enabled=0 e reinicie todos os workers. No PHP 8.5, também fatal_error_backtraces=0.
  • Reduza o post_max_size (8M sem uploads, 32M com uploads) e limite o tamanho das requisições no servidor web ou no proxy.
  • Ative as regras de firewall de aplicação (WAF) da sua CDN. Cloudflare, AWS, Akamai, Fastly e Imperva já publicaram proteções.

Precisa de ajuda?

Se tiver dúvidas sobre a versão do PHP no seu serviço ou encontrar algo suspeito, fale com a nossa equipe.

Abrir um chamado

*️⃣ Fontes

OFICIAIS

PESQUISADORES E EMPRESAS DE SEGURANÇA

IMPRENSA

Este artigo resume informações públicas e pode ser atualizado conforme novos dados forem divulgados. Ele não substitui a análise de um profissional de segurança no seu ambiente.

Bu cevap yeterince yardımcı oldu mu?

İlgili diğer dökümanlar

Falhas e Travamentos
Segue abaixo um tutorial para diagnostico e solução de travas ou congelamentos. 1) Reiniciar...
Correção de falhas no DNS ( Android, MacOSx, Linux e Windows )
Passo a Passo para Resolver o Erro:    “Servidor DNS Não Está...