PHP2Shell (CVE-2026-109618 e CVE-2026-109619): o que fazer agora no seu PHP

Resumo (atualizado em 23/10/2026): PHP2Shell é o nome de duas falhas críticas no próprio PHP, a CVE-2026-109618 e a CVE-2026-109619, ambas com CVSS v4 9,2. Elas permitem execução remota de código sem autenticação e, no caso da 109619, vazamento de memória do processo, o que pode expor senhas, tokens e chaves de API de outras requisições. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Depois, rotacione segredos: o patch fecha a porta, mas não desfaz o que pode ter vazado. Já houve tentativas de exploração antes da divulgação.

Na terça-feira, 21 de outubro de 2026, o projeto PHP publicou correções de emergência para duas vulnerabilidades encontradas pela Wiz Research, pela Calif e pela OpenAI, em coordenação com o time de segurança do PHP. O apelido PHP2Shell resume o problema: o caminho vai do interpretador PHP direto para uma shell no servidor.

Este texto é para quem precisa decidir rápido: CTOs, times de infraestrutura, donos de sites WordPress e gestores de risco. Não há detalhe de exploração aqui, só o que fazer, em que ordem e como provar que foi feito.

O que aconteceu

São duas falhas distintas no núcleo do PHP, não em um plugin ou framework:

• CVE-2026-109618 (corrupção por falta de memória). O tratamento de out-of-memory pode interromper o PHP enquanto os dados internos da requisição estão só parcialmente inicializados. A limpeza da requisição trata esses dados inválidos como válidos, e isso leva a execução de código com os privilégios do usuário do servidor web.
• CVE-2026-109619 (estado global obsoleto). Um estado interno da requisição pode sobreviver depois que a memória dele foi liberada (use-after-free no heap). Uma requisição seguinte atendida pelo mesmo worker pode usar esse estado antes da reinicialização. Resultado: vazamento de memória do processo e execução remota de código, sem autenticação.

A Wiz demonstrou execução remota de código sem autenticação contra instalações de WordPress, Drupal e Joomla, além de leitura de memória sensível do processo. Segundo a Help Net Security, a rede de honeypots da Amazon registrou uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação. O CTO da Cloudflare confirmou ataques iniciais, conforme o BleepingComputer. Até 23/10/2026 as CVEs não constavam do catálogo KEV da CISA, mas isso não significa ausência de risco: tentativas já foram vistas.

Quem está mais exposto

Toda instalação de PHP que atende requisições web é afetada: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco maior está no Apache com mod_php, onde o interpretador vive dentro do processo do servidor web.

Versões corrigidas:

Branch	Versão corrigida	Situação
8.5	8.5.12	Suportada
8.4	8.4.27	Suportada
8.3	8.3.36	Suportada
8.2	8.2.35	Suportada
8.1, 8.0, 7.4 e anteriores	Sem release oficial	Fora de suporte; o projeto publicou backports mínimos de código-fonte para 7.4, 8.0 e 8.1, e algumas distribuições aplicam correções próprias

Um ponto importante: em Debian, Ubuntu, RHEL e derivados, o pacote pode estar corrigido sem mudar o número da versão, porque a distribuição faz backport do patch. Por isso, olhar só o X-Powered-By ou o php -v pode enganar nos dois sentidos. Confira o changelog do pacote.

Também ficam em situação mais delicada:

• sites com PHP 8.1 ou anterior, que dependem de backport;
• hospedagem compartilhada, onde você não controla quando o PHP é atualizado;
• servidores que guardam segredos em variáveis de ambiente ou na memória do processo (praticamente todos).

Faça agora: checklist em ordem

1. Descubra a versão real no servidor, não pela web. Rode php -v e php-fpm -v (ou o binário equivalente) em cada host. Nunca publique um phpinfo() para conferir.
2. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se usa pacote da distribuição, confira no changelog se as CVE-2026-109618 e CVE-2026-109619 constam como corrigidas.
3. Reinicie PHP-FPM, Apache e workers. Patch instalado com processo antigo rodando não protege.
4. Se não puder atualizar hoje, aplique as mitigações parciais recomendadas pelo time do PHP (elas reduzem, mas, nas palavras do próprio projeto, nenhuma bloqueia totalmente os ataques):
   • Para a 109618: memory_limit=-1 via php_admin_value na configuração do FPM ou Apache; post_max_size baixo (8M sem upload, 32M com upload); limites de memória por container ou cgroup.
   • Para a 109619: session.upload_progress.enabled=0; no PHP 8.5, fatal_error_backtraces=0; remova configurações inválidas que geram mensagens de diagnóstico.
5. Coloque um WAF na frente, se ainda não tiver. A Cloudflare publicou regras para os vetores conhecidos, mas trata essas regras como medida temporária.
6. Rotacione segredos. Este é o passo mais esquecido e talvez o mais importante, porque a 109619 permite ler memória de outras requisições. Priorize:
   • senhas de banco de dados;
   • chaves de API de terceiros (pagamento, e-mail, SMS, CRM);
   • chaves de sessão e salts (no WordPress, as constantes AUTH_KEY, SECURE_AUTH_KEY e afins no wp-config.php);
   • tokens OAuth e segredos de JWT;
   • credenciais de nuvem (chaves de acesso de AWS, GCP, Azure).
7. Invalide sessões de usuários e administradores depois da rotação.
8. Revise logs desde ~17/10: picos de erros 500, mensagens de out of memory, uploads multipart incomuns e reinícios de worker fora do padrão.
9. Procure sinais de comprometimento: arquivos PHP novos em diretórios de upload, web shells, usuários administradores criados recentemente, tarefas agendadas desconhecidas.

Notas para WordPress

O WordPress é o caso mais comum no Brasil e foi um dos alvos demonstrados. Três cuidados específicos:

• Hospedagem gerenciada: pergunte ao provedor, por escrito, qual versão e qual build do PHP está em uso e quando foi aplicado o patch. Guarde a resposta como evidência.
• Salts: gerar novos valores no wp-config.php derruba todas as sessões, o que é exatamente o que você quer depois da rotação.
• Plugins não são a causa, mas ampliam o dano. Um invasor com execução de código lê o wp-config.php, então trate a senha do banco como exposta se o servidor ficou vulnerável.

Como priorizar uma frota

Quem tem dezenas de servidores não consegue fazer tudo ao mesmo tempo. Uma ordem razoável:

1. Servidores expostos à internet com mod_php.
2. Sistemas que tratam dados de pagamento, saúde ou credenciais (painéis, APIs de login, checkout).
3. Hosts em PHP 8.1 ou anterior, que precisam de backport ou migração.
4. Ambientes internos e de homologação, que muitas vezes compartilham segredos com produção.

Registre para cada host: versão antes e depois, data do patch, mitigação aplicada e segredos rotacionados. Esse registro é o que auditoria, cliente enterprise ou seguradora vai pedir.

Como a Pentest Machine pode ajudar

Nós mesmos atualizamos nossa infraestrutura para o PHP 8.4.27 e aplicamos a mitigação de session.upload_progress logo após a divulgação. A partir dessa experiência montamos uma resposta PHP2Shell com escopo fechado:

• inventário de versão e SAPI (mod_php, FPM, CGI) de cada servidor indicado;
• revisão de logs em busca de sinais de exploração;
• plano de rotação de segredos priorizado;
• relatório executivo com evidências para auditoria e clientes;
• reteste depois das correções.

Entregamos em até 72 horas depois que o acesso é liberado. A proposta sai com preço fechado em até 24 horas: peça um orçamento.

Quer só uma primeira visão? O Raio-X de Segurança Externa é gratuito e passivo e agora sinaliza indícios de PHP exposto. Ele não envia carga de ataque e não confirma se o patch foi aplicado: serve para saber por onde começar.

Perguntas frequentes

O que é PHP2Shell?

É o nome dado a duas vulnerabilidades críticas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619, divulgadas em 21/10/2026. Elas permitem execução remota de código sem autenticação e vazamento de memória do processo.

Quais versões do PHP corrigem a falha?

PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e anteriores não recebem release oficial; houve backports mínimos de código-fonte para 7.4, 8.0 e 8.1, e algumas distribuições publicaram pacotes corrigidos.

Atualizar o PHP basta?

Não. O patch impede novos ataques, mas a CVE-2026-109619 permite ler memória de outras requisições. Se o servidor ficou exposto, rotacione senhas, chaves de API, salts e tokens e invalide sessões.

Meu site está atrás da Cloudflare. Estou protegido?

Parcialmente. A Cloudflare publicou regras de WAF para os vetores conhecidos, mas trata essas regras como temporárias. Atualizar o PHP continua obrigatório.

Como sei se meu WordPress foi afetado?

Confirme a versão do PHP com o provedor ou no servidor, revise logs desde 17/10 em busca de erros 500 e out of memory, procure arquivos PHP novos em wp-content/uploads e administradores criados recentemente. Na dúvida, rotacione os segredos.

Um scanner externo consegue dizer se estou vulnerável?

Não com certeza. A versão costuma ficar escondida e distribuições corrigem sem mudar o número. Um scanner passivo, como o Raio-X, indica sinais de exposição; a confirmação exige acesso ao servidor.