PHP2Shell (CVE-2026-109618, CVE-2026-109619): você atualizou o PHP, agora verifique seu checkout

Resumo: PHP2Shell (CVE-2026-109618, CVE-2026-109619)

• O que aconteceu: em 2026-10-21 o PHP lançou 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir duas falhas com CVSS 9.2 no próprio motor. Ambas podem dar a um atacante sem conta execução de código em qualquer servidor web PHP, abaixo de WordPress, Magento ou Laravel.
• Os ataques começaram antes da correção: os identificadores CVE vazaram cerca de 23 horas antes do lançamento. A Cloudflare viu tráfego de ataque antes do patch, e a watchTowr relatou tentativas de exploração 19 minutos depois.
• Corrigido não é limpo: atualizar o PHP fecha a porta, mas não expulsa ninguém. Em lojas online, o acesso ao servidor muitas vezes termina num skimmer no checkout, e isso só aparece no navegador.

Sem tempo? Veja o monitoramento de scripts client-side da cside. Ajuda você a monitorar as mudanças e o comportamento dos scripts no navegador descritos abaixo.

Em 2026-10-21 o projeto PHP lançou correções de emergência para duas falhas críticas no motor do PHP, registradas como CVE-2026-109618 e CVE-2026-109619 e apelidadas de PHP2Shell. Como as falhas estão no runtime e não em algum CMS ou plugin, todos os sites WordPress, WooCommerce, Magento, Shopware e Drupal rodando numa versão do PHP sem correção estavam em risco ao mesmo tempo.

Quase toda a cobertura até agora fala do servidor, e com razão: atualize o PHP e reinicie todos os workers. Este artigo trata da parte que costuma ficar de fora. Quando um atacante consegue executar código numa loja online, o servidor raramente é o prêmio. O prêmio são algumas linhas de JavaScript adicionadas ao checkout e entregues a cada comprador até que alguém olhe o que o navegador realmente executa.

O que aconteceu: um bug antigo e uma divulgação que vazou

A causa raiz não era nova. Segundo a PHP Foundation, um desenvolvedor do núcleo viu os primeiros sinais do problema de falta de memória por trás da CVE-2026-109618 durante a auditoria externa do PHP em 2024. Ninguém encontrou na época um caminho real até a execução de código, cada correção possível tinha custos de compatibilidade ou de negação de serviço, e o trabalho travou. A Fundação chama esse atraso de falha estrutural do seu próprio processo.

Isso mudou em agosto de 2026, quando auditorias da Calif, da OpenAI e da Wiz transformaram o bug antigo em exploits funcionais. O lançamento coordenado estava marcado para 2026-10-22. Não se manteve.

O intervalo que importa para quem defende são essas cerca de 23 horas entre o vazamento e o lançamento. Quem rodava PHP passou essa janela exposto a um bug cuja existência os atacantes já conheciam, sem nenhum patch para instalar.

As duas vulnerabilidades, em termos simples

Os dois bugs estão em código que quase toda requisição PHP atravessa: gerenciamento de memória e tratamento de erros. Ambos têm nota 9.2 no CVSS v4.0, e ambos podem dar a um atacante não autenticado execução de código com os privilégios do worker web.

Dois detalhes tornam isso pior que um bug comum de CMS. Primeiro, a falha age abaixo da sua aplicação, então uma instalação de WordPress ou Magento totalmente atualizada numa versão vulnerável do PHP continua exposta, e os plugins de segurança nunca veem a requisição. Segundo, segundo os pesquisadores, um atacante também pode ler a memória do worker do PHP sem antes obter execução de código. Essa memória pode conter tokens de sessão, senhas, chaves de API e certificados de outros usuários.

As descrições oficiais são o aviso sobre corrupção na falta de memória e o aviso sobre estado obsoleto.

Quem é afetado, e está sendo explorado?

Qualquer instalação de PHP que atenda requisições web está no escopo, seja qual for a interface de servidor: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. Pesquisadores demonstraram execução de código sem autenticação em instalações padrão de Magento 2.4.9, WordPress, Drupal, Joomla, Nextcloud, phpMyAdmin, Laravel e outros. A Sansec destaca as lojas Magento, Shopware e WooCommerce.

Três coisas confundem as pessoas. Os pacotes das distribuições receberam o patch com antecedência e podem trazê-lo com um número de versão que parece antigo, então procure a CVE no changelog do pacote em vez de confiar na versão. O repositório do Remi, comum em servidores baseados em RHEL, não publicou atualizações em 2026-10-21. E atualizar WordPress, Magento ou Laravel não adianta nada aqui: a correção vem do pacote do servidor, da sua hospedagem ou da sua imagem de contêiner.

Quanto à exploração, tudo andou rápido. A Cloudflare diz que viu tráfego de ataque contra seus clientes antes de o patch sair, e que observou atacantes alterando payloads para driblar suas regras. A watchTowr relatou tentativas de exploração ativas contra as duas CVEs às 14:19 UTC. No momento da publicação, nenhuma fonte confirmou publicamente o comprometimento bem-sucedido de um servidor específico. Várias organizações, entre elas serviços do governo holandês e a BambooHR, saíram do ar por precaução em vez de esperar.

Se você não conseguiu aplicar o patch dentro dessa janela, presuma que foi sondado.

Por que um bug no servidor vira um problema no checkout

Numa loja online, uma shell é um meio, não um fim. Isso se repetiu depois de cada onda de exploração em massa contra plataformas de e-commerce em PHP, com o CosmicSting em 2024 como o caso mais conhecido: os atacantes conseguem executar código, deixam um backdoor e depois mudam o que a loja envia aos navegadores dos compradores. O dinheiro está nos números de cartão digitados no checkout, e eles só existem no navegador.

A cadeia costuma ser assim:

1. Exploit. Uma requisição manipulada atinge um worker do PHP sem correção.
2. Execução de código. O código do atacante roda como o usuário web, sem login.
3. Persistência. O atacante planta uma webshell, um cron job ou uma nova conta de administrador. Isso sobrevive à atualização do PHP, porque o patch fecha a porta mas não expulsa quem já está dentro.
4. Injeção. O atacante muda o que o navegador recebe: uma tag <script> num template do checkout, um bundle de JavaScript próprio modificado ou, muito comum em Magento e WordPress, um trecho guardado no banco de dados (configurações de cabeçalho do tema, blocos CMS, opções de widgets) onde as verificações de integridade de arquivos nunca olham.
5. Coleta. O navegador de cada comprador executa o skimmer. Ele lê os campos do cartão, ou exibe um formulário de pagamento falso, e envia os dados para um domínio que parece de analytics ou de CDN.

O lojista costuma descobrir por um aviso de ponto comum de compra de uma bandeira de cartão, semanas ou meses depois de o primeiro cartão ser roubado.

Cada defesa cobre um trecho diferente dessa cadeia:

Skimmers modernos são feitos para ficar invisíveis às ferramentas que verificam o lado do servidor. Eles só disparam na rota do checkout, uma vez por sessão, para certos países ou quando não há ferramentas de desenvolvedor abertas, então um crawler vindo de um data center recebe uma página limpa. Vimos o truque de uma vez por sessão há poucos dias no sequestro do checkout da HulkApps. Um WAF vê o exploit que chega, não o script que sua página entrega três semanas depois. O único lugar onde o skimmer se mostra de forma confiável é a sessão de navegador de um cliente real.

Corrigido não é o mesmo que limpo: o que verificar agora

Se seus servidores PHP estavam expostos à internet com uma versão afetada em qualquer momento depois do vazamento de 2026-10-20, percorra as duas listas abaixo. A primeira trata do servidor. A segunda trata do que os navegadores dos seus clientes recebem, e é a que a maioria das listas de resposta a incidentes deixa de fora.

No servidor

• Preserve as evidências primeiro. Faça uma cópia dos logs do PHP e do servidor web, da configuração e de qualquer arquivo suspeito antes de mudar qualquer coisa.
• Atualize e reinicie. Instale o build corrigido do PHP e depois reinicie o Apache, o PHP-FPM e todos os workers de longa duração. Um pacote atualizado com workers antigos ainda rodando continua vulnerável.
• Procure persistência. Procure arquivos PHP novos ou alterados nas raízes web e nos diretórios de upload, cron jobs inesperados e usuários administradores que ninguém criou.
• Procure nos logs as marcas do exploit. Os pesquisadores sugerem procurar requisições multipart incomuns seguidas de erros de limite de memória ou rajadas de HTTP 500, cookies PHPSESSID de resposta estranhamente grandes e reinícios inexplicados de workers do PHP.
• Observe o comportamento dos processos. Conexões de saída a partir de workers do PHP, ou sh, curl ou wget iniciados pelo php-fpm, são sinais fortes.
• Troque o que vivia na memória. Como a memória dos workers podia ser lida sem execução de código, troque chaves de API, credenciais de banco de dados e segredos do gateway de pagamento que os processos do PHP mantinham, e considere invalidar as sessões ativas.

No navegador

• Inventarie cada script das suas páginas sensíveis. Primeiro checkout, pagamento, login e conta. Inclua seus bundles próprios, não só as tags de terceiros.
• Compare com uma linha de base anterior a 2026-10-20. Qualquer script novo, qualquer hash de arquivo alterado e qualquer domínio novo com o qual o checkout se comunique merece uma explicação.
• Verifique os lugares onde skimmers se escondem fora do seu código. No Magento, as configurações "Scripts and Style Sheets" do cabeçalho HTML e "Miscellaneous HTML" do rodapé, os blocos CMS e os widgets. No WordPress, plugins de injeção de cabeçalho e rodapé, widgets e opções do tema guardadas no banco de dados.
• Não confie num único rastreamento. Um skimmer que dispara uma vez por sessão ou ignora endereços IP de data centers passa num scan. Você precisa de observações de sessões reais, ao longo do tempo.
• Observe as requisições de saída do checkout. Os dados do cartão precisam sair da página de alguma forma: um fetch, um beacon de imagem, um WebSocket. Um destino novo na página de pagamento é o sinal mais claro que você vai ter.
• Revise os relatórios de violação de CSP, se você os coleta. Um relatório que cita um domínio que você nunca usou vale a investigação, mesmo que a página pareça normal.

Nada disso substitui o patch. Responde à pergunta que o patch não consegue responder: algo mudou enquanto a porta estava aberta?

O que isso significa para o PCI DSS 6.4.3 e 11.6.1

O PHP2Shell é um caso de livro para os dois requisitos do PCI DSS 4.0.1 que se tornaram obrigatórios em 2025-03-31.

• O requisito 6.4.3 pede que você gerencie cada script carregado e executado numa página de pagamento no navegador do consumidor: confirmar que cada um está autorizado, garantir sua integridade e manter um inventário com uma justificativa escrita para cada um. Um skimmer injetado depois do comprometimento de um servidor é, por definição, um script não autorizado.
• O requisito 11.6.1 exige um mecanismo de detecção de mudanças e adulterações que alerte você sobre alterações não autorizadas nos scripts das páginas de pagamento e nos cabeçalhos HTTP relevantes para a segurança, tal como o navegador os recebe. É exatamente essa a mudança que um atacante faz no passo 4 da cadeia acima.

Duas perguntas práticas para a sua próxima avaliação. Com que frequência o seu mecanismo de 11.6.1 avalia de fato a página? Se a resposta for semanal, um skimmer injetado em 2026-10-21 pode rodar por dias antes que alguém perceba. E as suas evidências cobrem a janela a partir de 2026-10-20? Se você consegue mostrar que o inventário de scripts das suas páginas de pagamento não mudou, tem uma resposta limpa. Se não consegue, vale fechar essa lacuna agora.

Lojistas no SAQ A que incorporam o iframe de um provedor de pagamento também não estão livres. Desde a revisão do SAQ A de janeiro de 2025, a elegibilidade depende de confirmar que o seu site não é suscetível a ataques de script que possam afetar seus sistemas de e-commerce. Uma página pai comprometida ainda pode trocar ou sobrepor esse iframe.

Onde a cside entra

Para deixar o escopo claro: a cside não corrige o PHP nem bloqueia a requisição do exploit. Esse é o trabalho da sua atualização do PHP e do seu WAF. A cside cobre a camada que vem depois: o que suas páginas realmente executam nos navegadores dos seus clientes.

Sessões reais, não rastreamentos sintéticos. A cside monitora scripts em sessões reais de compradores em vez de depender de um scan periódico, então um skimmer que dispara uma vez por sessão ou se esconde de data centers continua rodando na nossa frente.

Mudanças e comportamento, não só nomes de arquivo. Um script novo no checkout, um bundle próprio modificado ou um script que começa a ler os campos do cartão e a enviá-los para um domínio que sua loja nunca usou gera um alerta, com o conteúdo do script disponível para inspeção.

Bloqueado na sessão. Com o Script Method, a cside busca cada script de terceiros no servidor para gerar o hash, arquivar e analisar, e os bloqueios são aplicados em tempo de execução no navegador, junto com o CSP. Um script não autorizado, ou uma capacidade específica que ele tenta usar, é bloqueado na sessão em vez de ser relatado depois.

Evidências para o PCI. O PCI Shield mantém o inventário de scripts do 6.4.3 e os alertas de mudança do 11.6.1, com relatórios semanais que o seu avaliador consegue ler.

Os detalhes acima refletem as informações públicas e as declarações dos fornecedores em 2026-10-21. Vamos atualizar este artigo conforme os relatos de exploração mudarem.

Se a cside já monitorava o seu checkout em 2026-10-20, revise os dados registrados desde então ou agende uma demo para analisá-los com a nossa equipe. Comece grátis para iniciar o monitoramento a partir da implementação. Novas implementações não podem reconstruir sessões anteriores do navegador.

Fontes

• Aviso de segurança do PHP: RCE por corrupção na falta de memória (GHSA-w8hw-w9fx-j79w)
• Aviso de segurança do PHP: RCE por estado obsoleto (GHSA-6wmf-4rv5-p3rp)
• Anúncio do PHP, 2026-10-21
• The PHP Foundation: Today's PHP security release, and how we're strengthening PHP security
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability
• watchTowr: PHP Remote Code Execution (PHP2Shell)
• Rapid7: CVE-2026-109618 and CVE-2026-109619
• The Hacker News: PHP issues emergency patches for two critical PHP2Shell RCE flaws
• Sansec: PHP2Shell critical PHP RCE
• CERT-EU Security Advisory 2026-018