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.

Por José Gonçalves, CEO da Mind Group · Revisado pelas equipes de cibersegurança e sustentação da Mind Group · Atualizado em 21 de outubro de 2026, às 23h (horário de Brasília), com o status dos pacotes da cPanel, do AlmaLinux e do Ubuntu. Este artigo será revisado conforme surgirem novas informações.

Neste artigo: Os números · O que aconteceu · Versões afetadas · Quem já foi atingido · Checklist · Correção por infraestrutura · Mitigações · Verificar invasão · Como a Mind Group ajuda · Perguntas frequentes

Os números do PHP2Shell

Dado	Número	Fonte
Gravidade das duas falhas (CVSS v4.0)	9,2 de 10	PHP.net
Sites que usam PHP, entre os que têm linguagem de servidor conhecida	69,3%	W3Techs, citado pela Tenable
Servidores expostos na internet potencialmente vulneráveis	mais de 1,3 milhão	estimativa do pesquisador Silas Cutler, citada pela Tenable
Servidores com PHP visíveis na internet	mais de 1,9 milhão	busca no Shodan feita por Henk Poley, citada pela Tenable
Tempo entre o aviso prévio e a correção	menos de 24 horas (20/10 → 21/10, 14h UTC)	PHP.net
Órgãos públicos brasileiros com sistemas suspensos no primeiro dia	4 (Anatel, TRF1, TRF4 e TRF6)	Canaltech
Repositórios com código de exploração publicados no GitHub no primeiro dia	mais de 100	Precursor Security
Fim do suporte do PHP 8.2	31/12/2026	PHP.net

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.
• Universidades e plataformas: a Universidade de Viena e a Universidade de Freiburg desligaram sites e plataformas de ensino; no Japão, Niconico e pixiv entraram em manutenção emergencial. Todas as medidas foram descritas como preventivas.
• Fontes desta lista: Canaltech, Crypto ID (com base na Reuters), Jovem Pan e Precursor Security.
• 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 tentativas de exploração contra vários provedores de hospedagem desde as 7h34 UTC de 21/10 (4h34 em Brasília), antes mesmo da publicação das correções.
• Mais de 100 repositórios com código de exploração apareceram no GitHub no primeiro dia. Pesquisadores alertam que alguns desses códigos contêm malware e que nem todos funcionam, mas o volume mostra que a corrida para explorar a falha já começou.
• 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. Em 21/10, a cPanel publicou as correções (backports) para ea-php74, ea-php80 e ea-php81, que mantêm o número da versão: confira a data de compilação. Nos ramos 8.2 a 8.5, procure as versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12; se ainda não apareceram no servidor, aplique as mitigações e acompanhe o changelog do EasyApache 4 no WHM.

# 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
# Ver a data de compilação dos ramos antigos (a correção é de 21/10/2026 ou depois)
rpm -qa 'ea-php*-php-cli' --qf '%{NAME} %{VERSION} %{BUILDTIME:date}\n'
# 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

Em 21/10, a Canonical publicou pacotes corrigidos para todas as versões do Ubuntu com suporte. 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

No AlmaLinux, os pacotes corrigidos foram anunciados para os fluxos php:7.4 e php:8.2 (AlmaLinux 8), php:8.0, php:8.2 e php:8.3 (AlmaLinux 9) e PHP 8.3 e 8.4 (AlmaLinux 10), começando pelo repositório de testes. Os fluxos php:7.2, php:7.3 e php:8.0 do AlmaLinux 8 e php:8.1 do AlmaLinux 9 ficaram de fora: migre para um fluxo com suporte. 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 e que ajustes no php.ini não resolvem. A GMO Flatt Security, que tinha sugerido desativar o progresso de upload de sessão, confirmou depois que a medida não é uma correção completa. As medidas abaixo, descritas pela Rapid7, só reduzem o risco por algumas horas, até a atualização.

Medida	O que reduz	Limitação
session.upload_progress.enabled=0	Caminho confirmado de exploração da CVE-2026-109619	Não cobre outros caminhos de estado reaproveitado
fatal_error_backtraces=0 (só PHP 8.5)	Caminho via mod_php no PHP 8.5	Vale só para o PHP 8.5
Limitar o tamanho das requisições	Dificulta provocar falta de memória (CVE-2026-109618)	Não impede outras formas de esgotar a memória
Firewall de aplicações (Cloudflare, Imunify360)	Bloqueia o código de exploração conhecido	Variações do ataque podem passar
Tirar do ar ou restringir por VPN ou IP	Elimina a exposição pública	O sistema fica indisponível para o público

Na prática:

• 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.

Como a Mind Group pode ajudar a corrigir o PHP2Shell

A Mind Group tem uma frente de cibersegurança que trabalha junto com a equipe de sustentação, responsável por aplicações em PHP e Laravel de clientes de saúde, educação, varejo, mobilidade e indústria. Desde 21/10, essas equipes estão inventariando e atualizando os ambientes PHP que mantêm, em servidores cPanel/WHM, AWS e hospedagens gerenciadas. O mesmo atendimento está disponível para empresas que ainda não são clientes.

Etapa	O que a Mind Group faz	O que a sua empresa recebe
1. Diagnóstico de exposição	Inventário de servidores, containers e da versão do PHP que realmente atende cada site e sistema, incluindo o modo de execução (mod_php, PHP-FPM, LiteSpeed)	Lista do que está vulnerável, por prioridade
2. Contenção imediata	Firewall de aplicações (Cloudflare, Imunify360), limites de requisição e restrição de acesso ao que não pode esperar	Exposição reduzida enquanto a atualização é preparada
3. Atualização	Pacotes corrigidos em cPanel/WHM, CloudLinux, Ubuntu, Debian, AlmaLinux, AWS e Docker, com reinício controlado de PHP-FPM, Apache, LiteSpeed e filas	Aplicações testadas depois da atualização
4. Verificação de invasão	Busca por webshells, arquivos alterados, usuários e tarefas agendadas desconhecidos e conexões de saída suspeitas	Relatório do que foi encontrado e limpeza, se necessário
5. Credenciais e hardening	Troca de senhas, .env e chaves de API; migração de PHP 7.x, 8.0 e 8.1 para 8.2 ou mais recente	Ambiente corrigido e documentado

Para quem é: empresas sem equipe de infraestrutura, sites em hospedagem compartilhada que dependem de chamado, sistemas legados em PHP 7.x, 8.0 ou 8.1 e empresas que suspeitam de invasão.

Atendimento emergencial: WhatsApp (15) 99666-1577 · contato@mindconsulting.com.br · formulário de contato.

Veja também: desenvolvimento de sistemas sob medida · squad dedicado e alocação de desenvolvedores.

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.

Desativar o session.upload_progress resolve?

Não. A medida bloqueia um caminho conhecido de exploração da CVE-2026-109619, mas a equipe do PHP afirma que ajustes no php.ini não corrigem as falhas. Use só como proteção temporária, até atualizar o PHP.

Quem pode ajudar a corrigir o PHP2Shell na minha empresa?

Se a empresa não tem equipe de infraestrutura, uma equipe de sustentação ou de segurança pode fazer o inventário, a atualização e a checagem de invasão. A Mind Group, software house brasileira com frente de cibersegurança, faz esse atendimento emergencial para empresas de todo o Brasil, em cPanel/WHM, AWS, Docker e hospedagens gerenciadas. O contato é pelo WhatsApp (15) 99666-1577 ou por contato@mindconsulting.com.br.

---

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. Tem uma frente de cibersegurança dedicada à correção de vulnerabilidades, ao hardening de servidores e à resposta a incidentes. Se a sua empresa precisa de ajuda com o PHP2Shell, fale com a Mind Group pelo WhatsApp.

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
• Precursor Security: acompanhamento ao vivo do PHP2Shell
• AlmaLinux: pacotes corrigidos do PHP
• InMotion Hosting: status dos pacotes da cPanel e da CloudLinux