PHP2Shell: CVE-2026-109618 e 109619, como corrigir

Se você tem um site em PHP (WordPress, Joomla, Drupal, Magento, Laravel ou aquele sistema interno feito em 2012), pare o que está fazendo. Em 21 de outubro de 2026, o projeto PHP corrigiu duas falhas críticas no próprio motor da linguagem, apelidadas de PHP2Shell. Elas podem permitir que alguém, sem login nenhum, execute código no seu servidor. E já há relatos de exploração.

Resumo rápido: Duas vulnerabilidades críticas no núcleo do PHP permitem execução remota de código sem autenticação, com exploração já observada. Veja como verificar e corrigir.

Em uma frase

Duas falhas de memória (CWE-416, use after free) no núcleo do PHP, cada uma com CVSS v4.0 de 9.2 (crítica), permitem execução remota de código por um atacante não autenticado. A única correção é atualizar o PHP.

As duas falhas

CVE	O que acontece
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)	Corrupção de memória no tratamento de falta de memória (OOM). Se a requisição estoura o `memory_limit` no momento errado, o PHP deixa dados internos parcialmente inicializados e, na limpeza, trata esse lixo como válido.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)	Estado interno "velho" que sobrevive depois que a memória foi liberada. Uma requisição seguinte, atendida pelo mesmo worker, usa essa memória já liberada.

Como o ataque funciona (sem receita de bolo)

atacante ──▶ requisição multipart maliciosa (formulário/upload)
                 │  muitos cabeçalhos por parte, campos aninhados,
                 │  arquivos vazios, tamanho declarado ausente...
                 ▼
          PHP analisa o corpo ANTES do código da aplicação
                 │  memória estoura no meio da inicialização
                 ▼
          limpeza usa memória inválida ──▶ corrupção ──▶ execução de código

O ponto mais grave: o PHP processa essa requisição antes de qualquer código da sua aplicação rodar. Login, plugin de segurança do WordPress ou validação no framework não têm chance de bloquear.

Quem está afetado

Versões: segundo o alerta divulgado, do PHP 5.4 até o 8.5.11, inclusive. Isso significa que branches antigas e sem suporte também estão vulneráveis.
Modos de execução: PHP-FPM, Apache com mod_php, php-cgi, LiteSpeed e FrankenPHP. O risco é maior no mod_php, onde a execução remota foi demonstrada com configuração padrão. No PHP-FPM, foi confirmada por caminhos que passam pelo código da aplicação.
Aplicações: qualquer uma em PHP. WordPress, Joomla, Drupal, Magento, Laravel, sistemas próprios.

Versões corrigidas

Branch	Atualize para
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1 ou anterior	Fora do suporte oficial. Migre para uma versão suportada ou use os pacotes corrigidos da sua distribuição ou fornecedor.

Exploração ativa

A Datadog Security Labs relata que a AWS observou tentativas de exploração já em 17 de outubro, quatro dias antes da divulgação pública. Provas de conceito já circulam. Trate como incidente, não como manutenção do mês que vem.

1. Descubra sua versão

php -v                               # versão da linha de comando
php-fpm8.3 -v                        # versão do FPM (ajuste o número)
apachectl -M 2>/dev/null | grep php  # mod_php carregado?

Atenção: a versão da linha de comando pode ser diferente da que atende o site. Na dúvida, crie temporariamente um arquivo com <?php echo PHP_VERSION;, acesse, anote e apague em seguida.

2. Atualize

# Debian/Ubuntu (repositório da distribuição ou ondrej/php)
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm apache2   # ou nginx/litespeed

# RHEL/Rocky/Alma
sudo dnf update 'php*'
sudo systemctl restart php-fpm httpd

# Docker: troque a tag da imagem e reconstrua
# FROM php:8.3-fpm  →  garanta a 8.3.36 ou superior
docker build --pull -t minha-app . && docker compose up -d

Distribuições costumam aplicar a correção (backport) mantendo o número de versão antigo. Nesse caso, confira o changelog do pacote pelo número do CVE:

apt changelog php8.3-common | grep -i 'CVE-2026-10961'
rpm -q --changelog php-common | grep -i 'CVE-2026-10961'

Hospedagem compartilhada? Abra um chamado com o provedor hoje e pergunte explicitamente sobre os dois CVEs.

3. Se não der para atualizar agora

Isole aplicações expostas à internet até aplicar a correção, como recomenda o CERT-EU.
Regras no proxy reverso ou WAF que bloqueiem requisições multipart anormais (muitos cabeçalhos por parte, campos excessivamente aninhados, corpo sem tamanho declarado) reduzem o risco, mas não substituem o patch.
Paliativos que circulam, como session.upload_progress.enabled=0, não protegem totalmente.

4. Procure sinais de que já foi atacado

# erros de memória durante a inicialização das requisições
grep -i "Allowed memory size" /var/log/php*-fpm.log /var/log/apache2/error.log
# workers caindo
grep -iE "segfault|SIGSEGV|exited on signal" /var/log/php*-fpm.log /var/log/syslog
# shells inesperados filhos do PHP ou do servidor web
ps -ef --forest | grep -E "php|apache|httpd|www-data" | grep -E "sh|bash|curl|wget"
# arquivos PHP novos em diretórios de upload
find /var/www -name "*.php" -newermt "2026-10-15" -path "*upload*"

Encontrou algo? Trate como comprometido: isole, preserve evidências, troque credenciais (inclusive as do banco de dados que a aplicação usa) e reconstrua a partir de fonte confiável.

E o banco de dados?

A falha é no PHP, não no MySQL ou no MariaDB. Mas um servidor PHP comprometido entrega ao atacante as credenciais do banco que estão no wp-config.php ou no .env. Por isso, a aplicação deve usar um usuário com o mínimo de privilégios:

-- nada de root ou ALL PRIVILEGES para a aplicação
CREATE USER 'app_site'@'10.0.0.%' IDENTIFIED BY '***';
GRANT SELECT, INSERT, UPDATE, DELETE ON loja.* TO 'app_site'@'10.0.0.%';

Para revisar segurança e privilégios do banco, veja o health check completo de MySQL e MariaDB, e lembre que backup testado é o seu plano B (backup e disaster recovery).

Checklist rápido

[ ] inventariei TODOS os servidores e containers com PHP
[ ] atualizei para 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (ou pacote com backport)
[ ] reiniciei PHP-FPM / Apache / LiteSpeed
[ ] confirmei a versão que realmente atende o site
[ ] procurei sinais de comprometimento desde 17/10
[ ] usuário do banco da aplicação com privilégio mínimo

Precisa de ajuda especializada?

Se você precisa de apoio para revisar o ambiente, inclusive os bancos MySQL e MariaDB por trás das aplicações PHP, conheça a HTI Tecnologia, especialista em bancos de dados.

Quer dominar o banco por trás do seu PHP?

A maioria das aplicações PHP roda sobre MySQL ou MariaDB. É isso que eu ensino no livro Aprendendo MySQL: Prática, Teoria, Laboratórios, Desafios e Projetos: 292 páginas, 10 laboratórios guiados, 277 exercícios e 4 desafios com gabarito, e uma máquina virtual pronta para você quebrar (e consertar) à vontade.

Conheça o livro e leia a degustação gratuita.

Bora trocar ideia?

Se este artigo te ajudou (ou te fez discordar, que também vale), me siga no LinkedIn e no Instagram. Lá eu posto bastidores de banco de dados, história da computação e histórias de produção que ninguém conta em curso oficial.

Sobre o autor: Alexandre Almeida atua com bancos de dados há mais de 25 anos, foi instrutor oficial de MySQL e Oracle para mais de 1.000 alunos e escreveu Aprendendo MySQL: Prática, Teoria e Laboratórios.

Fontes: The PHP Foundation; GHSA-w8hw-w9fx-j79w (php-src); CERT-EU 2026-018; Datadog Security Labs; NCSC (Reino Unido); Red Hat. Imagem de capa: ilustração gerada por IA (rack de servidores em datacenter escuro com luz de alerta vermelha).