Em 21 de outubro de 2026, o projeto PHP publicou uma atualização de segurança fora do calendário para corrigir duas falhas críticas no próprio interpretador: CVE-2026-109618 e CVE-2026-109619, apelidadas de PHP2Shell. As duas têm nota 9.2 no CVSS v4.0 e, em certas condições, permitem execução remota de código sem autenticação, ou seja: alguém na internet pode rodar comandos no seu servidor sem login e sem depender de nenhuma falha no seu site.

Não é um problema do WordPress, do Laravel ou do Magento. É do PHP. Se o seu servidor responde requisições web com PHP, ele está no grupo de risco. Neste artigo reunimos o que as fontes oficiais confirmaram, o que fazer agora e como mitigar se você não puder atualizar hoje.

Resumo para quem tem pressa

  • Atualize agora para PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie todos os processos do PHP.
  • Toda instalação que atende requisições web é afetada: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
  • PHP 8.1 ou anterior não recebe mais correção oficial. Procure o pacote corrigido da sua distribuição ou suporte estendido, ou migre de versão.
  • As mitigações temporárias são parciais. Segundo o próprio time do PHP, só a atualização resolve.
  • Usa WordPress? Não existe atualização do WordPress para isso. Quem precisa ser atualizado é o PHP do servidor.

O que são as falhas

As duas falhas estão no gerenciamento de memória e no tratamento de erros do motor do PHP, código que praticamente toda requisição percorre. Por isso o impacto é tão amplo.

CVEO que aconteceGatilho
CVE-2026-109618Um erro de falta de memória (OOM) interrompe o PHP enquanto dados internos da requisição estão só parcialmente inicializados. Na limpeza da requisição, esses dados inválidos são tratados como válidos.Requisição que leva o processo ao memory_limit no momento certo
CVE-2026-109619Um estado interno de uma requisição sobrevive depois que a memória dele foi liberada (use-after-free). A próxima requisição atendida pelo mesmo worker usa esse estado antigo antes da inicialização normal.Erro fatal ou timeout que o atacante consegue provocar

O cenário mais grave, segundo o anúncio oficial, é o Apache com mod_php: foi demonstrado um exploit que dispara com uma requisição não autenticada antes de qualquer código da aplicação rodar. Ou seja, plugin atualizado, firewall de aplicação dentro do CMS e código limpo não impedem o ataque.

A Sansec, empresa de pesquisa em segurança de e-commerce, informou ter reproduzido a execução remota sem login contra WordPress, Drupal, Joomla, Magento, Laravel, Symfony, Nextcloud, phpMyAdmin, Roundcube, MediaWiki e WHMCS em versões recentes. Segundo a mesma pesquisa, todos os gatilhos conhecidos chegam por requisições multipart/form-data, e o código vulnerável existe desde o PHP 5.4, de 2012.

Por que a correção saiu às pressas

A divulgação não saiu como planejado. Segundo a PHP Foundation, o primeiro indício do problema de memória apareceu em 2024, durante uma auditoria externa, mas a correção ficou travada por meses entre abordagens concorrentes. Entre agosto e setembro de 2026, auditorias e pesquisadores independentes reportaram a mesma causa raiz com exploits funcionais.

  • 20/10, ~15h UTC: os números dos CVEs vazaram, com data e nota erradas (10.0 em vez de 9.2).
  • 20/10, 19h30 UTC: o PHP antecipou o aviso e trouxe o lançamento de 22 para 21 de outubro.
  • 20/10, ~20h UTC: um vídeo de prova de conceito foi publicado por engano e se espalhou.
  • 21/10, 14h UTC: saem as versões corrigidas.

No momento da publicação, o time do PHP disse não ter encontrado exploits funcionais circulando. Já a Sansec repassou um relato da Cloudflare de tentativas de ataque às 7h43 UTC do dia 21, antes do lançamento. Na dúvida, trate como falha sob exploração ativa: é o que justifica a urgência.

Passo 1: descubra qual PHP você roda

O PHP da linha de comando nem sempre é o mesmo que atende o site. Confira o que o servidor web usa de fato:

  • WordPress: em Ferramentas > Diagnóstico > Informações > Servidor.
  • Painel da hospedagem (cPanel, Plesk, aaPanel etc.): normalmente em “Versão do PHP” ou “Seletor de PHP”.
  • Servidor próprio: pelos binários instalados e pelos serviços em execução.
# versões instaladas e serviços FPM ativos
php -v
ls /usr/sbin/php-fpm* 2>/dev/null
systemctl list-units --type=service | grep -i php

# Apache com mod_php?
apachectl -M 2>/dev/null | grep -i php

Atenção às distribuições Linux: Debian, Ubuntu, RHEL e derivados costumam aplicar a correção no pacote sem mudar o número da versão para 8.3.36, por exemplo. Nesse caso, a forma confiável de saber se está corrigido é procurar o CVE no changelog do pacote:

# Debian / Ubuntu (pacote instalado)
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -E "CVE-2026-10961(8|9)"

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961(8|9)"

Passo 2: atualize e reinicie

As distribuições e os fornecedores de suporte estendido receberam as correções com antecedência. Atualize pelo gerenciador de pacotes e reinicie os processos do PHP: enquanto um worker antigo estiver vivo, ele continua vulnerável.

# Debian / Ubuntu (ajuste para a sua versão)
sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # se usar mod_php

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Alguns pontos que costumam ficar para trás:

  • Docker: a imagem não se atualiza sozinha. Puxe a imagem base nova, reconstrua e publique de novo todos os serviços.
  • Repositório Remi: o anúncio oficial avisou que o rpms.remirepo.net, mantido por voluntários, não teria pacotes no dia do lançamento. Use os pacotes da distribuição ou compile a partir do código-fonte.
  • Hospedagem compartilhada e gerenciada: muitas empresas já estão atualizando e aplicando regras de WAF, mas confirme com o suporte. Em painéis com seletor de PHP, cada versão disponível precisa ter sido corrigida.
  • Produtos que embutem PHP: painéis de controle, appliances e sistemas de terceiros dependem do fornecedor. Acompanhe os avisos de cada um.

Passo 3: se usa PHP 8.1 ou anterior

O projeto PHP só dá suporte de segurança a partir do 8.2, e o próprio 8.2 chega ao fim da vida em 31 de dezembro de 2026. Para versões antigas, existem três caminhos:

  1. Pacote corrigido do fornecedor: algumas distribuições e empresas de suporte estendido fizeram backport da correção.
  2. Compilar com o patch: o PHP publicou backports mínimos para 7.4, 8.0 e 8.1 nas branches PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 e PHP-8.1-CVE-2026-109618-109619 do php-src.
  3. Tirar do ar até migrar: é a recomendação do NCSC, a agência de cibersegurança do Reino Unido, para quando a correção imediata não for viável.

Se a sua aplicação não roda em PHP 8.2 ou superior, esta é a hora de planejar a migração. Ela também traz ganho de desempenho, mas o motivo principal agora é ter correção de segurança.

Mitigação temporária: só se não der para atualizar hoje

O anúncio oficial lista medidas que reduzem a exposição a caminhos de ataque específicos, mas deixa claro que elas não tornam a instalação segura. Aplique no php.ini, no pool do FPM ou na configuração do Apache, nunca com ini_set() ou .user.ini, e reinicie todos os workers.

; PHP-FPM: /etc/php/8.x/fpm/pool.d/www.conf
; php_admin_value impede que a aplicação sobrescreva o valor

; CVE-2026-109618 (OOM)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M        ; 32M se precisar de upload
php_admin_value[upload_max_filesize] = 7M  ; sempre menor que post_max_size

; CVE-2026-109619 (estado reaproveitado)
php_admin_value[session.upload_progress.enabled] = 0

; só no PHP 8.5
php_admin_value[fatal_error_backtraces] = 0
# Apache com mod_php
php_admin_value memory_limit -1
php_admin_value post_max_size 8M
php_admin_value session.upload_progress.enabled 0

Cuidados com essas medidas:

  • memory_limit = -1 abre espaço para consumo excessivo de memória. Compense com limites no servidor web ou proxy (tamanho do corpo, número de campos, partes do multipart e cabeçalhos) e com limite de memória por container ou cgroup. O PHP orienta a não usar RLIMIT_AS nem RLIMIT_DATA, que podem disparar justamente a falha.
  • Esconder erros não ajuda. display_errors, error_reporting ou o operador @ não bloqueiam a CVE-2026-109619. O que reduz o risco é corrigir erros fatais e timeouts que um visitante consegue provocar.
  • Medida drástica: a Sansec sugere bloquear requisições multipart/form-data na borda até atualizar. Isso quebra uploads, formulários e, em lojas, pode afetar o checkout. Teste antes.

Assim que o PHP estiver atualizado, desfaça as medidas temporárias, principalmente o memory_limit = -1.

Como verificar se o servidor foi comprometido

Se o servidor ficou exposto com versão vulnerável, atualizar fecha a porta, mas não remove quem já entrou. A Huntress recomenda observar principalmente:

  • Processos do PHP abrindo shells ou ferramentas de rede: php-fpm, php-cgi, apache2 ou httpd iniciando sh, bash, python, perl, curl, wget ou nc.
  • Comandos de reconhecimento como whoami, id e uname -a partindo do servidor web.
  • Arquivos novos na pasta pública (webshells), cron jobs, tarefas agendadas ou usuários que ninguém criou.
# arquivos .php alterados nos últimos 3 dias na raiz do site
find /var/www -name "*.php" -mtime -3 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

# cron jobs do usuário do servidor web
sudo crontab -l -u www-data

Encontrou algo suspeito? Isole o servidor, preserve os logs do servidor web e do PHP antes de mexer em qualquer coisa e troque as credenciais que estavam nele: banco de dados, chaves de API e senhas de administrador. Para sites WordPress, o guia oficial “Meu site foi hackeado” ajuda na limpeza.

Checklist

  • Inventariar todos os servidores, containers e produtos com PHP, começando pelos expostos à internet
  • Atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou confirmar o CVE no changelog do pacote
  • Reiniciar PHP-FPM, Apache e reconstruir imagens Docker
  • Plano para versões 8.1 ou anteriores: pacote corrigido, backport ou tirar do ar
  • Mitigações temporárias só onde não der para atualizar, e removidas depois
  • Busca por sinais de invasão nos servidores que ficaram expostos
  • Planejar a saída do PHP 8.2, que perde suporte em 31/12/2026

Fontes

Precisa de ajuda?

Não sabe qual PHP o seu site usa, roda em versão antiga ou não tem certeza se ficou exposto? Fale com a gente: verificamos a versão, atualizamos sem derrubar o site e procuramos sinais de invasão. E se quiser deixar esse tipo de manutenção com quem cuida do servidor, conheça a hospedagem da CPW.