Resumo: duas falhas críticas no PHP, chamadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619, nota 9,2 de 10), permitem que um atacante execute código no servidor sem login. A única correção completa é atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, versões lançadas em 21 de outubro de 2026. Atualizar WordPress, plugins ou temas não resolve.

Atualizado em 21 de outubro de 2026. Este artigo será revisado conforme surgirem novas informações.

O que aconteceu

• 20/10/2026: a equipe do PHP publica um aviso prévio de atualização de segurança crítica para o dia seguinte. Os números das falhas circulam em fóruns e redes sociais antes da data combinada para divulgação.
• 21/10/2026, 14h UTC (11h em Brasília): saem as versões corrigidas 8.5.12, 8.4.27, 8.3.36 e 8.2.35. No mesmo dia, órgãos públicos no Brasil e na Europa tiram sistemas do ar de forma preventiva, e agências de segurança de vários países emitem alertas.

O que são as duas falhas

As duas permitem execução remota de código sem autenticação, com as permissões do processo do PHP no servidor (o mesmo usuário que lê arquivos e acessa o banco de dados do site).

• CVE-2026-109618: quando o PHP fica sem memória no meio de uma requisição, partes dos dados podem ficar só parcialmente preenchidas, e a limpeza posterior opera sobre dados inválidos. Um atacante pode provocar essa falta de memória com requisições de formulário ou upload preparadas para isso, mesmo dentro dos limites configurados.
• CVE-2026-109619: um processo do PHP que atende várias requisições pode reaproveitar, numa requisição nova, informações que ficaram na memória de uma requisição anterior interrompida por erro fatal. O recurso de progresso de upload de sessão, ativado por padrão, é um dos caminhos de exploração.

Segundo a Rapid7, o modo mais exposto é o PHP rodando como módulo do Apache (mod_php), mas PHP-FPM, php-cgi, FrankenPHP e LiteSpeed também estão na lista de configurações afetadas.

Versões afetadas e corrigidas

Ramo do PHP	Afetado	Versão corrigida
8.5	anterior a 8.5.12	8.5.12
8.4	anterior a 8.4.27	8.4.27
8.3	anterior a 8.3.36	8.3.36
8.2	anterior a 8.2.35	8.2.35 (o 8.2 chega ao fim do suporte em 31/12/2026)
8.1, 8.0 e 7.4	sim	sem atualização regular. Há correções pontuais (backports) e pacotes de fornecedores. Em pacotes de distribuição e de painéis, o número da versão pode continuar igual, então confira a data da compilação
7.3 ou anterior	sim	sem correção oficial: migrar para uma versão com suporte

Quem já foi atingido

Até o momento da publicação, as suspensões abaixo foram preventivas. Não há confirmação pública de invasão nesses órgãos.

No Brasil
– Anatel: tirou do ar o SEI (Sistema Eletrônico de Informações) e outros serviços digitais. A agência informou que o motivo é a vulnerabilidade do PHP, não uma falha do SEI. As redes de telefonia e internet não foram afetadas.
– Justiça Federal da 4ª Região (TRF4, com RS, SC e PR): interrompeu o acesso externo aos sistemas digitais a partir das 11h de 21/10.
– TRF1: suspendeu o acesso externo ao SEI, seguindo recomendação do TRF4.
– TRF6 (Minas Gerais): suspendeu o expediente e os prazos processuais na Justiça Federal do estado por instabilidade nos sistemas.
– CTIR Gov (Gabinete de Segurança Institucional): publicou a Recomendação Técnica nº 19/2026. O texto orienta localizar as aplicações em PHP, priorizar a atualização e, quando não for possível atualizar logo, avaliar a suspensão temporária do acesso externo.

No exterior
– Países Baixos: retirada preventiva de serviços do governo, entre eles Overheid.nl, MijnOverheid.nl e o DigiD (identificação digital), além de serviços do Porto de Roterdã e de páginas de hospitais.
– Alemanha: sites administrados pelo ITZBund, o centro de tecnologia do governo federal.
– França: sites de prefeituras e administrações territoriais ligadas ao Ministério do Interior.
– Finlândia: serviços web do governo administrados pela Valtori.
– Bélgica: sites do Ministério das Relações Exteriores.
– Fundação Wikimedia: desativou alguns sistemas de forma preventiva.
– Alertas oficiais: CERT-EU (União Europeia), NCSC (Reino Unido), NSA e CISA (Estados Unidos), Canadian Centre for Cyber Security (Canadá) e ACSC (Austrália). Todos pedem a atualização imediata. CERT-EU, NCSC e NSA também orientam tirar do ar o que não puder ser atualizado ou protegido.

Exploração em andamento
– A Cloudflare informou que já vê as primeiras tentativas de ataque e publicou regras de proteção no seu firewall de aplicações.
– A Patchstack relatou incidentes de exploração confirmados.
– Há código de exploração circulando publicamente. Pesquisadores alertam que alguns desses códigos podem conter malware.
– Estima-se que mais de 1,3 milhão de servidores expostos na internet estejam potencialmente vulneráveis. O PHP roda em cerca de 69% dos sites cuja linguagem de servidor é conhecida.

O que fazer agora: checklist

1. Liste tudo o que roda PHP: sites, sistemas, APIs, painéis, filas e containers. Cada servidor e cada container tem o seu próprio PHP.
2. Descubra a versão real de cada um. O comando php -v mostra a versão do terminal, que pode ser diferente da versão que atende o site (PHP-FPM ou módulo do Apache). Veja como verificar mais abaixo.
3. Atualize para a versão corrigida do seu ramo (tabela acima), seguindo o passo a passo da sua infraestrutura.
4. Reinicie tudo o que usa PHP: PHP-FPM, Apache, LiteSpeed e também os processos de longa duração, como filas, agendadores e Laravel Octane. Eles mantêm o binário antigo na memória até reiniciar.
5. Se não puder atualizar hoje, aplique as mitigações temporárias, coloque um firewall de aplicações na frente do site e avalie tirar o sistema do ar, como recomendam o CTIR Gov, o CERT-EU e o NCSC.
6. Depois de atualizar, verifique se houve invasão (seção final).

Como corrigir em cada infraestrutura

Em todos os casos, confirme depois da atualização que cada versão em uso é 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou mais recente. Nos ramos antigos, confirme a data da compilação.

Hospedagem compartilhada (Hostinger, Locaweb, KingHost, HostGator e similares)

O PHP é atualizado pela empresa de hospedagem, não por você.
– No painel da hospedagem, confira qual versão do PHP o site usa e mude para 8.2 ou mais recente, se estiver em 7.x, 8.0 ou 8.1.
– Abra um chamado e pergunte se os servidores já receberam as versões corrigidas de 21/10.
– No WordPress, a versão aparece em Ferramentas → Saúde do site → Informações → Servidor.

cPanel/WHM (EasyApache 4)

O PHP vem dos pacotes ea-php. A correção chega quando a cPanel publica os pacotes atualizados.

# Ver a versão de cada PHP instalado
for b in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$b -> $($b -r 'echo PHP_VERSION;')"; done
# Atualizar os pacotes de PHP (AlmaLinux/Rocky/CloudLinux 8+; no CentOS 7 use yum)
dnf -y upgrade 'ea-php*'
# Reiniciar o PHP-FPM e o Apache
/usr/local/cpanel/scripts/restartsrv_apache_php_fpm
/usr/local/cpanel/scripts/restartsrv_httpd

Também dá para usar WHM → Run System Update. Contas em ea-php74, ea-php80 ou ea-php81 devem migrar para 8.2 ou mais recente em WHM → MultiPHP Manager.

CloudLinux (alt-php) e Imunify360

• Os pacotes alt-php com a correção estavam em preparação em 21/10. Acompanhe a página de status da CloudLinux e atualize com yum -y update 'alt-php*' quando forem publicados.
• Quem tem Imunify360 com o firewall ativado recebe automaticamente as regras 8.83, que bloqueiam o formato do código de exploração público. É uma proteção temporária, não substitui a atualização.

Plesk

plesk installer update
/opt/plesk/php/8.3/bin/php -v   # repita para cada ramo em uso

Nos ramos antigos (7.4, 8.0, 8.1), o número da versão não muda: o que conta é a compilação de 21/10/2026 ou posterior. O próprio painel do Plesk (sw-engine) precisa de uma correção separada, anunciada pela Plesk.

Ubuntu e Debian

sudo apt-get update
apt-mark showhold | grep -i php   # pacote "segurado" é ignorado sem aviso
sudo apt-get install --only-upgrade $(dpkg-query -W -f='${Package}n' 'php*' 2>/dev/null)
sudo systemctl restart php8.3-fpm   # ajuste para cada versão em uso
sudo systemctl restart apache2      # ou nginx

Se o PHP veio do repositório do Ondřej Surý (ppa:ondrej/php ou packages.sury.org), o mesmo comando atualiza a partir dele. Nos pacotes da própria distribuição, a versão pode manter o número antigo com a correção aplicada, então confira no rastreador de segurança do Ubuntu ou do Debian.

RHEL, AlmaLinux, Rocky e Amazon Linux

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd

Quem usa o repositório Remi: a equipe do PHP informou que os pacotes do Remi não seriam atualizados em 21/10. A orientação é usar pacotes da distribuição ou compilar a partir do código-fonte.

LiteSpeed (lsphp)

# Debian/Ubuntu: sudo apt-get install --only-upgrade 'lsphp*'   |   RHEL: sudo dnf upgrade 'lsphp*'
/usr/local/lsws/bin/lswsctrl restart

Docker

Não atualize o PHP dentro de um container em execução. Reconstrua a imagem a partir da imagem base corrigida:

docker pull php:8.3-fpm            # a tag que você usa
docker compose build --pull --no-cache
docker compose up -d
docker compose exec app php -v     # deve mostrar 8.3.36 ou mais recente

Confira cada container: cada um carrega o seu próprio PHP.

AWS

• EC2: siga o passo a passo da distribuição instalada (Ubuntu, Debian ou Amazon Linux).
• Elastic Beanstalk: aplique a nova versão da plataforma PHP assim que a AWS publicar. Enquanto isso, aplique as mitigações temporárias.
• Lightsail com imagens Bitnami: verifique a atualização da pilha. Na falta dela, migre para uma imagem com PHP corrigido.
• Containers (ECS/EKS): reconstrua as imagens como em Docker.

Windows (IIS)

Baixe a versão corrigida em windows.php.net, substitua os binários, mantendo o php.ini, e reinicie com iisreset.

WordPress, Laravel, Magento, Drupal, Joomla e Moodle

A falha está no interpretador, não no sistema. Todos ficam vulneráveis se a versão do PHP for vulnerável, e atualizar o sistema, os temas ou os plugins não corrige o problema. No Laravel, depois de atualizar, reinicie também filas (php artisan queue:restart), Horizon e Octane.

Como verificar a versão que atende o site

O php -v no terminal não basta. Para ver a versão que o servidor web realmente usa:
1. Crie na raiz do site um arquivo com nome aleatório, por exemplo verifica-7f3k9.php, com o conteúdo <?php echo PHP_VERSION, ' ', PHP_SAPI;
2. Acesse o arquivo pelo navegador e anote a versão.
3. Apague o arquivo em seguida.

Em servidores com várias versões do PHP, repita para cada site.

Mitigações temporárias (só se não puder atualizar hoje)

A equipe do PHP afirma que não existe mitigação completa. As medidas abaixo, descritas pela Rapid7, reduzem o risco por algumas horas, até a atualização:
– Desativar o progresso de upload de sessão: session.upload_progress.enabled=0 no php.ini ou no pool do PHP-FPM, e reiniciar todos os processos. Configurar pelo ini_set() da aplicação ou pelo .user.ini não funciona, porque é tarde demais.
– No PHP 8.5: fatal_error_backtraces=0, também no nível do servidor.
– Reduzir o tamanho das requisições: post_max_size=8M se o site não recebe uploads (ou 32M se recebe), com upload_max_filesize abaixo disso.
– Bloquear requisições multipart (formulários com arquivo) antes de chegarem ao PHP, se a aplicação não usa esse tipo de envio.
– Firewall de aplicações: Cloudflare e Imunify360 já publicaram regras para o código de exploração conhecido. Elas não cobrem variações.
– Tirar do ar ou restringir o acesso (VPN ou lista de IPs) o que não puder ser protegido. É o que fizeram Anatel e tribunais.

Depois de atualizar: verifique se houve invasão

Com exploração ativa, vale checar os sistemas que ficaram expostos:
– arquivos .php novos ou alterados recentemente, principalmente em pastas de upload e de cache;
– usuários administradores que ninguém criou;
– tarefas agendadas (cron) e processos desconhecidos rodando com o usuário do servidor web;
– conexões de saída incomuns a partir do servidor.

Se houver suspeita, troque as senhas e chaves que o PHP consegue ler: banco de dados, arquivo .env, chaves de API e de pagamento.

Perguntas frequentes

Meu site WordPress está vulnerável?

Sim, se o servidor rodar uma versão do PHP anterior às corrigidas. A falha está no PHP, não no WordPress. Confira a versão em Ferramentas → Saúde do site e confirme com a sua hospedagem se os servidores já foram atualizados.

Atualizar plugins e temas resolve?

Não. O problema está no interpretador do PHP. Só a atualização do PHP para 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou para um pacote com a correção resolve.

Uso PHP 7.4 ou 8.1. O que faço?

Esses ramos não recebem mais atualizações regulares. Use o pacote corrigido do seu fornecedor (distribuição, painel ou suporte estendido), se existir, e planeje a migração para o PHP 8.2 ou mais recente.

Por que órgãos públicos tiraram sistemas do ar?

Porque a falha permite controlar o servidor sem login, e a atualização de sistemas grandes leva tempo. Retirar o acesso externo enquanto se atualiza é a recomendação do CTIR Gov, do CERT-EU e do NCSC para quem não consegue corrigir na hora.

Quanto tempo leva para corrigir?

Num servidor com pacotes já disponíveis, a atualização leva minutos. O trabalho maior é o inventário: descobrir todos os servidores, containers e versões em uso, e testar as aplicações depois.

---

Sobre a Mind Group: a Mind Group é uma software house brasileira fundada em 2016, com mais de 60 desenvolvedores próprios e mais de 500 produtos digitais lançados. Desenvolve e mantém sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil, incluindo a sustentação de aplicações em PHP e Laravel. Se a sua empresa precisa de ajuda para inventariar e atualizar servidores, fale com a Mind Group.

Fontes:
– PHP.net: aviso de segurança e versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35
– Canaltech: Falhas no PHP chegam ao Brasil e fazem Anatel e tribunais suspenderem sistemas
– Crypto ID: Falhas críticas no PHP levam governos a suspender serviços
– Rapid7: análise técnica e mitigações
– Tenable: perguntas frequentes sobre o PHP2Shell
– Patchstack: alerta de exploração ativa
– Plesk: correção no PHP distribuído com o Plesk
– CloudLinux: Imunify360 e alt-php
– Jovem Pan: Países Baixos e recomendação da NSA
– Insurance Journal: alerta do CERT-EU