Em 21 de outubro de 2026, o projeto PHP publicou um alerta de segurança pedindo que todos os usuários atualizem a linguagem imediatamente. Ele trata de duas falhas críticas, registradas como CVE-2026-109618 e CVE-2026-109619 e apelidadas de PHP2Shell, que podem permitir execução remota de código sem autenticação no servidor. No mesmo dia, a CISA, agência de cibersegurança dos Estados Unidos, recomendou a aplicação imediata da correção.

O PHP está por trás de WordPress, WooCommerce, Laravel, Magento, Drupal, Joomla, Moodle e de muitos sistemas feitos sob medida. Se o site da sua empresa roda em PHP, este artigo explica o que aconteceu, como descobrir se você está exposto e o que fazer hoje, inclusive quando não é possível atualizar de imediato.

Resumo para quem precisa decidir rápido

  • O que é: duas vulnerabilidades críticas no próprio interpretador PHP, com nota 9,2 de 10 na escala CVSS 4.0 atribuída pelo projeto.
  • Impacto: um atacante remoto, sem login, pode conseguir executar comandos no servidor. Uma das falhas também pode expor conteúdo da memória.
  • Quem está em risco: toda instalação de PHP que atende requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.
  • Correção: PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
  • Situação: segundo a Amazon Threat Intelligence, citada pela Tenable, houve tentativa de exploração em 17 de outubro, antes da divulgação, e novas tentativas a partir de 21 de outubro.

Atualizar o WordPress, o tema ou os plugins não corrige este problema. A falha está no PHP, a camada que executa o código do site. A correção precisa acontecer no servidor.

O que são as falhas PHP2Shell

As duas vulnerabilidades envolvem a forma como o PHP gerencia a memória durante o processamento de uma requisição. Os detalhes técnicos estão nos avisos oficiais; para quem administra um negócio, o importante é entender o mecanismo em linhas gerais.

CVE-2026-109618 — execução remota por falta de memória. Quando a memória se esgota no meio do processamento, o PHP pode ser interrompido enquanto dados internos da requisição ainda estão incompletos. Na limpeza que acontece em seguida, esses dados inválidos podem ser tratados como válidos. O aviso técnico no GitHub do PHP descreve o problema.

CVE-2026-109619 — execução remota por estado reaproveitado. Parte do estado interno de uma requisição pode continuar referenciando uma área de memória que já foi liberada. Uma requisição seguinte, atendida pelo mesmo processo, pode usar esse estado antes da reinicialização normal. Os detalhes estão no segundo aviso técnico.

O projeto PHP considera o risco mais alto em servidores Apache com mod_php, pois houve demonstração de ataque disparado por uma requisição sem autenticação antes de qualquer código da aplicação ser executado. Por isso, nem um site bem programado escapa enquanto o PHP estiver desatualizado.

Quem precisa agir

Qualquer empresa com site, loja virtual, portal, intranet ou API em PHP exposta à internet. Na prática, isso inclui:

  • sites e blogs em WordPress, inclusive lojas em WooCommerce;
  • aplicações em Laravel, Symfony, CodeIgniter ou PHP puro;
  • plataformas como Magento, Drupal, Joomla, PrestaShop e Moodle;
  • sistemas internos acessíveis pela internet, como painéis, áreas de clientes e integrações.

Hospedagem compartilhada ou gerenciada: em geral, a versão do PHP é instalada pelo provedor, mas a escolha entre as versões disponíveis costuma ficar com você no painel. Confirme com a hospedagem se os pacotes corrigidos já foram aplicados e verifique se o seu site não está preso a uma versão antiga sem suporte.

VPS, servidor dedicado ou nuvem: a atualização é responsabilidade de quem administra o servidor. Se ninguém na empresa tem esse papel definido, este é o momento de definir.

Versões corrigidas e versões sem suporte

Ramo do PHP Situação após o alerta
8.5 Corrigido na versão 8.5.12
8.4 Corrigido na versão 8.4.27
8.3 Corrigido na versão 8.3.36
8.2 Corrigido na versão 8.2.35 (correções de segurança até 31/12/2026)
8.1, 8.0 e 7.4 Sem versão oficial. Há apenas correções mínimas no código-fonte, publicadas pela equipe de segurança do PHP
7.3 e anteriores Sem correção do projeto PHP

Distribuições Linux e fornecedores de suporte estendido receberam as correções com antecedência. Por isso, o pacote corrigido da sua distribuição pode ter um número de versão diferente do oficial. Confira o aviso de segurança do fornecedor do sistema operacional.

Se o seu site ainda roda PHP 8.1 ou anterior, a situação é mais séria: esses ramos já não recebem atualizações do projeto. A página de versões suportadas mostra que até o PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. Para quem não consegue atualizar nem aplicar uma correção, a CISA recomenda tirar o sistema do ar até que ele seja atualizado.

Como descobrir a versão do PHP do seu site

Escolha o caminho que corresponde ao seu ambiente:

  1. No WordPress: acesse Ferramentas › Saúde do site › Informações e abra a seção Servidor. A versão do PHP aparece na lista.
  2. No cPanel ou painel da hospedagem: procure por opções como MultiPHP Manager ou Selecionar versão do PHP. O nome varia de acordo com o provedor.
  3. No servidor: o comando abaixo mostra a versão usada no terminal.
php -v

Cuidado com esta verificação. A versão do terminal pode ser diferente da versão que realmente atende o site, principalmente em servidores com mais de uma instalação ou com PHP-FPM. Confirme pelo painel, pela Saúde do site ou com a equipe responsável pelo servidor. Se usar uma página com phpinfo() para conferir, apague o arquivo logo depois: ele expõe detalhes da configuração do servidor.

Como atualizar sem derrubar o site

Atualizar dentro do mesmo ramo, por exemplo da 8.3.30 para a 8.3.36, costuma ter baixo risco de incompatibilidade. Trocar de ramo, como da 7.4 para a 8.3, exige mais cuidado: plugins, temas e códigos antigos podem deixar de funcionar.

Um roteiro seguro:

  1. Faça um backup completo, com arquivos e banco de dados, e confirme que ele pode ser restaurado.
  2. Teste em um ambiente de homologação quando houver mudança de ramo ou quando o site tiver integrações críticas.
  3. Aplique a atualização pelo gerenciador de pacotes, pelo painel da hospedagem ou com o suporte do provedor.
  4. Reinicie todos os processos do PHP, como PHP-FPM e Apache. Processos antigos continuam rodando com o código vulnerável até serem reiniciados.
  5. Valide as funções que geram receita: formulários, login, carrinho, pagamento, área do cliente e integrações.
  6. Confirme a nova versão pelo mesmo caminho que você usou na verificação.

Se o site depende de uma versão antiga por causa de plugins ou código legado, a atualização vira um pequeno projeto de modernização. Mesmo assim, ele precisa começar agora, porque a versão antiga não vai receber a correção.

Se não for possível atualizar hoje: mitigações temporárias

O projeto PHP é claro: só a atualização resolve por completo. As medidas abaixo, descritas no alerta oficial, reduzem caminhos de ataque conhecidos, mas não tornam a instalação segura.

Para a CVE-2026-109619:

  • definir session.upload_progress.enabled=0 no php.ini, no pool do FPM ou na configuração do servidor, e reiniciar todos os processos. Configurações feitas por ini_set() ou por .user.ini não funcionam para essa finalidade;
  • no PHP 8.5, definir também fatal_error_backtraces=0.

Para a CVE-2026-109618:

  • usar memory_limit=-1 aplicado de forma que a aplicação não consiga sobrescrever, como php_admin_value no pool do FPM ou na configuração do Apache;
  • reduzir o post_max_size: o projeto sugere 8M para aplicações sem upload de arquivos e 32M quando há upload;
  • limitar o consumo de memória por contêiner ou cgroup para evitar que um processo comprometa a disponibilidade do servidor.

Essas mudanças afetam o funcionamento do servidor e exigem conhecimento técnico. Um ajuste mal feito pode tirar o site do ar ou abrir outro problema. Um firewall de aplicação web (WAF) também pode reduzir a exposição: a Cloudflare, por exemplo, publicou regras para os vetores conhecidos, mas elas só protegem o tráfego que passa pela rede dela.

Como verificar se o site já foi atacado

Como houve tentativas de exploração antes da divulgação, a orientação da Amazon, relatada pela Tenable, é investigar a partir de 17 de outubro de 2026. A CISA recomenda observar sinais como processos do PHP abrindo terminais de comandos ou baixando ferramentas. Fique atento a:

  • processos do PHP iniciando sh, bash, curl ou wget;
  • arquivos .php novos em pastas de upload, cache ou temas;
  • usuários administradores que ninguém da equipe criou;
  • alterações inesperadas em .htaccess, tarefas agendadas (cron) ou arquivos de configuração;
  • conexões de saída incomuns, consumo de recursos fora do padrão e envio de e-mails em massa.

Se houver suspeita de invasão, atualizar o PHP não basta. Isole o ambiente, preserve os registros para análise, remova o acesso indevido, restaure a partir de uma cópia limpa e só então troque as senhas e chaves usadas pelo site: banco de dados, painel administrativo, APIs, SMTP e gateways de pagamento.

Checklist das próximas 24 horas

  1. Liste todos os sites, sistemas e servidores da empresa que usam PHP, incluindo projetos antigos que continuam no ar.
  2. Identifique a versão do PHP de cada um e quem é responsável pelo servidor.
  3. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou aplique o pacote corrigido da sua distribuição.
  4. Reinicie todos os processos do PHP e confirme a versão em uso.
  5. Aplique mitigações temporárias apenas onde a atualização não for possível hoje.
  6. Planeje a migração de tudo que roda PHP 8.1 ou anterior.
  7. Revise os registros a partir de 17/10 em busca de sinais de comprometimento.
  8. Confirme que existe um backup recente e testado antes e depois da mudança.

A lição que fica: segurança é rotina, não reação

Falhas graves em softwares amplamente usados continuarão aparecendo. A diferença entre um susto e um prejuízo está no que a empresa já tinha organizado antes do alerta: um inventário dos sistemas, um responsável por cada serviço, atualizações frequentes, backups restauráveis, monitoramento e um plano de resposta.

Também vale avaliar o próprio desenvolvimento: sites e aplicações construídos com versões suportadas, dependências controladas, privilégios mínimos e registros de auditoria são mais fáceis de corrigir quando surge um alerta. Para organizar essas frentes, veja nosso checklist de segurança para sites empresariais.

Como a Suddenly pode ajudar

A Suddenly oferece consultoria e manutenção de segurança para sites e aplicações web. Podemos verificar a versão do PHP e a exposição dos seus sites, conduzir a atualização com backup e validação, migrar projetos presos a versões sem suporte e manter uma rotina preventiva de atualizações, backups e monitoramento. Também desenvolvemos sites e aplicações novos com segurança desde o projeto.

Seu site roda em PHP e você não sabe se já está protegido? Fale com a nossa equipe e receba um diagnóstico do seu ambiente.

Perguntas frequentes

Meu site em WordPress está vulnerável?

Se o servidor usa uma versão do PHP anterior a 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou um pacote de distribuição ainda sem a correção), sim. A falha está no PHP, não no WordPress. Por isso, atualizar o WordPress e os plugins é importante, mas não resolve este problema.

Tenho hospedagem compartilhada. Preciso fazer alguma coisa?

Sim. Confirme com o provedor se o PHP já foi corrigido e verifique, no painel, se o site não está configurado em uma versão antiga sem suporte, como 7.4, 8.0 ou 8.1.

Um firewall de aplicação (WAF) é suficiente?

Não. Ele reduz a exposição a ataques conhecidos e ajuda enquanto a atualização não é aplicada, mas não substitui a correção. Novas variantes podem não ser bloqueadas.

Meu sistema só funciona no PHP 7.4. O que faço?

O PHP 7.4 não recebe versão oficial com a correção. O caminho seguro é planejar a migração para um ramo suportado. Enquanto isso, reduza a exposição: restrinja o acesso, aplique as mitigações e avalie um fornecedor com suporte estendido ou a correção mínima publicada no código-fonte pelo projeto PHP.

Depois de atualizar, preciso fazer mais alguma coisa?

Reinicie todos os processos do PHP, confirme a versão em uso e revise os registros desde 17 de outubro. Se encontrar sinais de invasão, trate o caso como um incidente: limpe ou restaure o ambiente e troque as credenciais.

Fontes consultadas

Informações verificadas em 22 de outubro de 2026: