PHP expõe uma vulnerabilidade de alto risco 'nível internet'; como resolver o 'ponto fraco fora da cadeia' do Web3?

Título original: «PHP expõe vulnerabilidade crítica 'nível internet': como corrigir o 'ponto fraco fora da cadeia' do Web3?». Autor original: Equipe de Segurança SlowMist

O que aconteceu

Em 21 de outubro, o projeto PHP lançou uma atualização de segurança de emergência para corrigir duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, que podem levar à execução remota de código não autenticado (RCE); ambas receberam classificação CVSS v4.0 9,2. O PHP afirmou oficialmente que, antes da correção, todas as instalações PHP que fornecem serviços web externos poderiam ser afetadas.

Em 20 de outubro, detalhes da vulnerabilidade vazaram antes da divulgação oficial, e o patch ainda não havia sido lançado. A equipe de segurança do PHP precisou antecipar o lançamento de emergência, originalmente marcado para 22 de outubro, para 21 de outubro às 14h00 (UTC).

Mais alarmante ainda é que os ataques podem ter ocorrido antes da divulgação. A equipe de inteligência de ameaças da Amazon relatou que, em 17 de outubro, observou tentativas de exploração direcionadas ao php2shell em sua rede de honeypots MadPot, quatro dias antes da divulgação pública.

A SlowMist também emitiu alertas e recomendações de segurança imediatamente após o aviso prévio oficial do PHP.

Quais são as duas vulnerabilidades?

CVE-2026-109618 (Corrupção de memória por estouro): quando o PHP esgota a memória, o fluxo de processamento é interrompido e os dados em tratamento estão apenas parcialmente preparados. Durante a limpeza, o PHP trata esses dados incompletos como se estivessem prontos, causando corrupção de memória.

CVE-2026-109619 (Estado global obsoleto): após o processamento de uma requisição, a memória é liberada, mas o estado relacionado 'permanece ativo'. Quando o mesmo processo worker recebe a próxima requisição, pode usar esse estado expirado antes da inicialização normal. As autoridades confirmaram que isso pode ser explorado contra o PHP-FPM para obter execução remota de código.

Do ponto de vista do caminho de ataque, o perigo desse tipo de vulnerabilidade reside no fato de que os invasores não precisam primeiro obter uma conta no site, nem contornar verificações de login, permissões ou chaves de API na camada de negócios. Enviar uma requisição elaborada a uma aplicação PHP exposta na internet pública pode permitir execução arbitrária de código com os privilégios do processo do serviço web.

Escopo de impacto: PHP 5.4 até 8.5.11 estão todos afetados. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Versões PHP 8.1 e anteriores deixaram de receber suporte upstream regular; portanto, não se espera correções por canais regulares, devendo-se migrar para versões ainda suportadas.

Por que o mundo inteiro está nervoso?

Porque o PHP é simplesmente onipresente. Segundo estatísticas do W3Techs, entre os sites cuja linguagem de servidor pode ser identificada, 69,3% usam PHP. Sistemas conhecidos como WordPress, WooCommerce e Magento rodam sob ele.

As reações de diversos países também ilustram o problema: o Centro Nacional Holandês de Segurança Cibernética chegou a desligar preventivamente sites; o Gabinete Presidencial da Coreia do Sul convocou uma reunião de cibersegurança de emergência, elevando o nível de alerta cibernético governamental.

Além disso, segundo relatos, quase todos os sites oficiais da Coreia do Norte — incluindo mídias oficiais e portais governamentais — permaneceram fora do ar por mais de 24 horas, sem que ainda se saiba se isso está relacionado ao incidente de vulnerabilidade.

Impacto no Web3

Este não é um problema que afete apenas operações e manutenção tradicionais de sites. Para o Web3, mesmo que os contratos em cadeia não tenham vulnerabilidades, o grande número de 'componentes fora da cadeia' que cercam as operações dos contratos — incluindo páginas front-end, APIs, carteiras custodiais, serviços de assinatura, páginas de resgate de airdrops, back-ends operacionais e serviços de dados — costuma ser desenvolvido em PHP (WordPress, WooCommerce, Magento etc.). A ausência de vulnerabilidades nos próprios contratos não garante que esses componentes sejam seguros.

Segundo estatísticas do MistEye, sistema de inteligência de ameaças da SlowMist, dentre os 1.488 domínios relacionados à indústria de cripto que ele analisou, 793 exibiam assinaturas diretas de PHP — cerca de 53,3%. Ressalta-se que isso indica apenas o uso de PHP, não que os sites tenham vulnerabilidades ou já tenham sido comprometidos.

1. Lado da plataforma: caminhos típicos de risco

Alteração maliciosa do front-end para enganar usuários e induzi-los a assinar.

Se os servidores de sites DeFi, carteiras ou páginas de airdrop forem comprometidos, atacantes podem substituir endereços RPC, alvos de autorização, endereços de contratos ou mensagens de assinatura na página, transformando uma transação normal numa autorização maliciosa, interação maliciosa com contrato ou processo falso de depósito. Os atacantes não precisam violar o contrato: basta fazer com que o usuário assine uma autorização maliciosa.

Vazamento de chaves e credenciais.

Após o comprometimento de um servidor, atacantes podem ler arquivos de configuração, senhas de bancos de dados, tokens de API, variáveis de ambiente, entre outros. Se o back-end usar PHP para conectar-se a serviços RPC ou carteiras quentes, o vazamento de chaves de API ou tokens de sessão pode levar à transferência de ativos de carteiras quentes ou ao abuso de permissões de assinatura.

Assunção de controle do back-end e de APIs.

Plataformas de negociação, marketplaces de NFT, pontes entre blockchains, gateways de pagamento e provedores de serviços de nó geralmente possuem back-ends operacionais, além de interfaces de KYC/controle de riscos, alocação de endereços de depósito, revisão de saques, sistemas de tickets etc. Ao obter permissões, atacantes podem adulterar configurações, roubar dados de usuários, criar contas com altos privilégios ou contornar processos comerciais.

Movimentação lateral via cadeia de suprimentos.

Os privilégios de um processo PHP normalmente não equivalem aos máximos disponíveis no servidor, mas, se ele puder acessar chaves de CI/CD, sockets de runtime de contêineres, credenciais de banco de dados ou tokens de acesso à nuvem, o escopo do ataque pode se expandir de um único nó web para bancos de dados, sistemas de build ou até toda a conta de produção.

Plugins de pagamento e serviços terceirizados.

Sabe-se que soluções de pagamento cripto como Binance Pay, Crypto.com Pay, BitPay, CoinGate e CoinPayments possuem integrações com WooCommerce, e servidores sem correções representam riscos graves de exposição. Serviços terceirizados como RPC, exploradores de blocos e plataformas de análise de dados também podem se tornar pontos de entrada caso seus back-ends ou sistemas operacionais rodam em ambientes PHP afetados. É claro que nós RPC, contratos inteligentes, exploradores de blocos e carteiras em si não dependem intrinsecamente de PHP; isso depende da pilha tecnológica específica do produto.

No entanto, é importante observar que um servidor comprometido não implica necessariamente roubo de ativos em cadeia. Do comprometimento de um serviço web até uma perda financeira real, depende se os atacantes conseguem acessar credenciais sensíveis, processos de assinatura, privilégios administrativos ou pontos de interação com usuários. Se carteiras quentes estão isoladas da camada web, se chaves são armazenadas em HSMs/KMSs e se as permissões são minimizadas determina diretamente o limite máximo de perdas potenciais.

2. Usuários comuns: devo retirar minhas moedas?

Não é necessário.

O motivo é simples:

Essa vulnerabilidade afeta ambientes de servidor que atendam a condições específicas; não significa que as carteiras de todos os usuários estejam em risco.

Navegar em um site e conectar uma carteira não equivale à exposição da chave privada. A vulnerabilidade em si não consegue decifrar diretamente carteiras ou assinaturas de usuários.

O fato de um projeto usar PHP não significa que já foi comprometido. Não há motivo para presumir que toda plataforma de negociação foi invadida, muito menos para retirar todos os ativos por causa disso. O que os usuários realmente devem observar é se os sites que visitam foram comprometidos. Como os usuários não conseguem saber se um site foi corrigido, esse incidente serve como lembrete: não confie cegamente nas interfaces dos sites. Atacantes também podem explorar a atenção pública para disseminar páginas falsas de login, portais falsos de compensação e solicitações maliciosas de conexão de carteiras.

Se um projeto confirmar oficialmente que seu site ou backend foi comprometido, os usuários devem seguir o impacto real divulgado para decidir se suspendem interações, verificam transações anômalas e revogam aprovações suspeitas. Se for confirmado que chaves privadas de assinatura ou frases-semente foram vazadas, isso deve ser tratado como incidente de comprometimento de chave — simplesmente alterar senhas ou desconectar do site não é suficiente. Usuários de bots de negociação, ferramentas de execução automatizada ou serviços em nuvem também devem observar se os serviços relevantes divulgaram versões afetadas ou avisos de rotação de credenciais.

Como responder

1. Plataformas e equipes de projetos:

Etapa 1: Inventarie seus ativos e atualize-os imediatamente

Inventarie todos os ativos PHP em redes públicas e internas: servidores, imagens de contêineres, cargas de trabalho no Kubernetes, CMS legados, backends administrativos, ambientes hospedados por parceiros, plugins de terceiros e serviços gerenciados. Assinaturas técnicas servem apenas como pistas e não podem ser tomadas diretamente como conclusão de «vulnerabilidade confirmada».

Atualize para as versões 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 ou aplique os patches equivalentes fornecidos por distribuidores, provedores de nuvem ou prestadores de serviços gerenciados. Para quem usa versões 8.1 ou anteriores, solicite um backport ao fornecedor ou migre o mais rápido possível. Nem «o ambiente legado é estável» nem «o aplicativo raramente é atualizado» reduzem o risco dessa vulnerabilidade.

Após a atualização, recrie as imagens de contêiner, execute reinícios progressivos ou substitua todos os processos worker PHP e verifique a versão em execução que realmente lida com as requisições em produção — não apenas a versão na máquina de build ou na linha de comando.

Etapa 2: O que fazer se não puder atualizar agora

Primeiro, reduza a superfície de exposição para ganhar tempo, mas isso não substitui a correção:

Isole aplicações PHP expostas à internet pública ou adicione autenticação de rede e controle de acesso na camada de ingresso.

Desative uploads de arquivos desnecessários e rejeite requisições multipart/form-data não necessárias na camada de WAF ou servidor web.

Algumas recomendações de segurança também incluem: definir memory_limit=-1, desativar session.upload_progress.enabled e, no PHP 8.5, desativar ainda fatal_error_backtraces. Essas configurações têm impactos colaterais nos negócios e na disponibilidade; teste-as primeiro e reinicie todos os workers PHP após cada alteração.

Etapa 3: Verifique possíveis comprometimentos e rotacione credenciais

Para serviços afetados que estiveram expostos à internet pública, investigue usando logs, monitoramento de endpoints e conexões de rede anômalas — por exemplo, processos PHP subitamente executando comandos do sistema. Se houver suspeita de comprometimento, preserve primeiro as provas e, depois, trate conforme o processo de resposta a incidentes.

Assuma o pior cenário: para servidores não corrigidos a tempo, rotacione chaves de API, chaves de sessão, certificados TLS, senhas de bancos de dados, tokens de acesso à nuvem, credenciais de CI/CD, chaves de RPC/API, segredos de webhooks e tokens de terceiros, além de verificar registros de uso anômalo.

Se uma versão comprometida do software tiver sido instalada ou executada no ambiente, atualizar ou reinstalar sozinho não comprova que o risco foi eliminado; é necessário também investigar vazamentos de credenciais e backdoors persistentes, e, se necessário, reconstruir um ambiente limpo.

Etapa 4: Proteja o plano de controle dos ativos

Corrigir o PHP não deve ser a única ação. Mais importante ainda: garanta que «uma máquina web comprometida não comprometa o sistema de fundos»:

Isole completamente as chaves privadas de carteiras quentes, carteiras de recebimento e serviços críticos de assinatura dos nós web. Use HSMs, MPC, redes dedicadas de assinatura ou políticas de KMS com privilégios mínimos.

Posicione serviços web, serviços de assinatura, nós on-chain, bancos de dados e sistemas de build em segmentos de rede e fronteiras de identidade distintos.

Durante incidentes, restrinja temporariamente operações de alto risco, como saques, alterações na lista de endereços autorizados, elevação de privilégios de administrador, criação de chaves de API e modificações em regras de controle de risco, permitindo revisão manual ou ativação diferida quando necessário.

Para serviços que executam automaticamente na cadeia, adote assinatura independente, aprovação por múltiplas assinaturas, limites de valor nas transações e mecanismos de desligamento de emergência conforme as necessidades do negócio.

Verifique recursos estáticos do site, pacotes JavaScript, configurações de proxy reverso, regras DNS/CDN e serviços de construção de transações para confirmar que nenhum script malicioso foi inserido ou substituído.

2. Usuários comuns:

Use pontos de entrada oficiais: recentemente, acesse plataformas por favoritos ou canais oficiais e desconfie de links enviados sob pretexto de um “incidente de segurança”.

Não confie apenas no domínio e na interface: mesmo em domínios de dApps conhecidos, scripts da página, parâmetros de transação e configurações RPC podem ter sido substituídos por invasores no lado do servidor.

Verifique item por item antes de assinar: endereço de recebimento, cadeia, valor de aprovação, contrato chamado e resultados da simulação de transação. Tenha especial cuidado com approve e setApprovalForAll, e ainda mais com aprovações ilimitadas.

Desconfie de termos como “indenização”, “migração” e “reverificação”: durante incidentes, podem surgir mensagens como “faça login novamente”, “reverifique sua carteira”, “migre seus ativos” ou “reclame indenização”. Não aja apenas com base em pop-ups no site; confirme via múltiplos canais oficiais do projeto.

Separe seus ativos: use carteiras de hardware para grandes volumes, carteiras com limite de capacidade para interações diárias e limpe regularmente aprovações. Assim, mesmo que um frontend ou plataforma seja comprometido, qualquer perda individual terá um teto.

Pare imediatamente ao perceber algo suspeito: se encontrar solicitações incomuns de assinatura, prompts inesperados de aprovação ou comportamentos suspeitos no site, pare primeiro e verifique pelos canais oficiais.

Considerações finais

Vulnerabilidades de execução remota sem login, como PHP2Shell, ao romperem a camada web, podem transformar intrusões tradicionais em servidores em envenenamento de frontend, falsificação de identidade, abuso de permissões de assinatura, riscos à carteira quente e até movimentação lateral no nível da cadeia de suprimentos.

Para plataformas, três ações são prioritárias: atualizar para versões corrigidas, isolar ambientes legados não atualizáveis por enquanto e auditar chaves e planos de controle de ativos. Após a atualização, trate a busca por sinais de intrusão como parte da resposta ao incidente. Para usuários, nesse período, confie menos cegamente na interface da página e revise com atenção cada transação antes de assinar. Mas não entre em pânico excessivo: a existência de uma vulnerabilidade não significa necessariamente que os ativos estejam ameaçados; uma violação de servidor não implica, por si só, perda de fundos na cadeia. O que realmente determina a escala do risco é quais credenciais os invasores obtiveram, qual privilégio essas credenciais conferem e com que rapidez o projeto consegue isolar e revogar tais permissões. Para projetos Web3, a segurança não se limita a impedir ataques, mas também deve considerar: quando um componente for realmente comprometido, o impacto pode ser contido localmente, evitando que o risco se espalhe para operações centrais de negócios e ativos.

Link original