Falha no Funnel Builder permite injeção de JavaScript em checkouts do WooCommerce

Exploração ativa usa configuração global de scripts do plugin para carregar skimmer em páginas de pagamento e capturar dados de cartão antes do envio ao gateway.

Componente	Plugin Funnel Builder para WordPress, usado em lojas WooCommerce, com impacto em checkouts criados ou controlados pelo plugin.
Vetor	Requisição não autenticada a um endpoint público de checkout capaz de acionar método interno sem validação de permissão nem lista restrita de métodos permitidos.
Impacto	Injeção de JavaScript arbitrário na configuração External Scripts, com execução em páginas de checkout e roubo de números de cartão, CVV, endereços de cobrança e outros dados pessoais inseridos pelo usuário.
Prioridade	Atualizar o plugin para 3.15.0.3 ou versão posterior e inspecionar imediatamente Settings > Checkout > External Scripts em busca de tags desconhecidas.
Versões	Todas as versões anteriores a 3.15.0.3 são afetadas; a correção foi disponibilizada na versão 3.15.0.3.
Artefatos	Skimmer disfarçado como carregador de Google Tag Manager, JavaScript remoto e conexão WebSocket para obtenção de código adaptado à loja comprometida.
IoCs	Endpoint de comando e controle observado: wss://protect-wss[.]com/ws.
Mitigação	Remover scripts não reconhecidos da configuração de checkout, validar integridade do site, revisar transações recentes e acionar procedimentos de resposta para possível exposição de dados de pagamento.

Resumo técnico

Uma vulnerabilidade crítica no plugin Funnel Builder para WordPress está sendo explorada em lojas WooCommerce para inserir JavaScript malicioso em páginas de checkout. A falha não possui identificador CVE oficial no material analisado, mas tem uma condição técnica objetiva: versões anteriores a 3.15.0.3 expõem um caminho de execução no checkout que permite a um atacante não autenticado alcançar lógica interna do plugin e gravar dados controlados pelo atacante nas configurações globais. Como essas configurações são usadas para renderizar scripts externos no fluxo de pagamento, o resultado prático é a execução persistente de código em cada página de checkout afetada.

O abuso observado consiste em adicionar uma tag que se apresenta como carregador de Google Tag Manager ou outro componente analítico esperado em comércio eletrônico. Essa escolha reduz a chance de detecção por revisão visual, porque tags de mensuração são comuns em páginas de compra. A carga, porém, não se limita a telemetria: ela busca JavaScript externo e estabelece comunicação por WebSocket com infraestrutura de comando e controle, incluindo o endereço wss://protect-wss[.]com/ws, para receber um skimmer ajustado à vitrine comprometida. O código passa a atuar no navegador do comprador, antes que o formulário seja submetido ao gateway, o que torna a exposição possível mesmo em lojas que não armazenam dados completos de cartão no servidor.

A superfície é relevante porque o Funnel Builder é usado em mais de 40 mil lojas WooCommerce. A exploração não depende de credenciais administrativas, conforme o comportamento descrito, e o ponto de persistência fica dentro da própria configuração do plugin, não necessariamente em um arquivo PHP recém-criado ou em um tema modificado. Isso muda a forma de resposta: além de atualizar o plugin, é necessário verificar opções gravadas no banco de dados, revisar scripts configurados para checkout, procurar conexões de rede iniciadas pelo navegador do cliente e avaliar possível exposição de dados de pagamento digitados durante o período em que o skimmer esteve ativo.

Fluxo técnico

O ponto vulnerável está em um endpoint público relacionado ao checkout do Funnel Builder. Esse endpoint aceita uma requisição capaz de indicar qual tipo de método interno deve ser executado. Em versões vulneráveis, o plugin não aplicava duas barreiras essenciais: validação de autorização do chamador e restrição explícita dos métodos que poderiam ser invocados a partir de uma entrada externa. Sem essas proteções, uma requisição anônima podia alcançar um método interno não especificado no material analisado e usá-lo para gravar conteúdo controlado pelo atacante nas configurações globais do plugin.

A gravação maliciosa tem valor porque o plugin oferece uma área legítima para scripts externos de checkout, identificada como External Scripts. Esse recurso normalmente serve para inserir tags de analytics, mensuração de conversão, integrações de marketing ou componentes de acompanhamento do funil. O atacante explora a confiança operacional nesse campo e adiciona um trecho que aparenta ser uma tag comum. Quando a loja renderiza o checkout, o próprio plugin injeta o conteúdo configurado na página, fazendo com que todos os usuários que acessarem o fluxo de pagamento executem o JavaScript no navegador.

Depois da execução inicial, o script carregado pelo checkout comprometido atua como etapa de bootstrap. Em pelo menos um caso observado, ele se apresentou como carregador de Google Tag Manager e passou a buscar JavaScript em domínio remoto. Em seguida, abriu uma sessão WebSocket com wss://protect-wss[.]com/ws. Esse canal permite que o operador entregue um skimmer específico para a loja, modifique comportamento sem alterar novamente a configuração local e responda a diferenças de DOM, campos de pagamento, temas ou plugins adicionais. O objetivo final é interceptar valores digitados pelo comprador, incluindo número do cartão, CVV, endereço de cobrança e outros dados pessoais presentes no formulário.

O impacto não deve ser interpretado apenas como comprometimento do painel administrativo. A execução ocorre no lado do cliente, no momento de maior sensibilidade do fluxo de compra. Se o skimmer se registra em eventos de formulário, intercepta campos antes da tokenização ou observa alterações no DOM, ele pode capturar dados antes que o gateway de pagamento receba ou tokenize a transação. A extensão do dano depende de quais páginas usam o checkout do Funnel Builder, de quando a configuração foi alterada e de quanto tráfego de pagamento passou por essas páginas durante a janela de comprometimento.

Superfície afetada

A exposição se concentra em instalações WordPress com WooCommerce que usam o plugin Funnel Builder em versão anterior a 3.15.0.3. A condição de maior risco é a presença de checkouts ativos que renderizam scripts configurados pelo plugin. Lojas com múltiplos funis, páginas de upsell, páginas de checkout segmentadas por campanha ou ambientes clonados para staging devem verificar cada instalação separadamente, porque a configuração maliciosa pode estar em opções específicas do plugin e não em um arquivo visível no diretório do tema.

A ausência de autenticação no vetor descrito aumenta a prioridade de correção. Um atacante não precisa roubar uma sessão administrativa, comprometer credenciais de wp-admin ou obter acesso ao servidor para plantar o JavaScript se a versão vulnerável estiver exposta e o endpoint puder ser alcançado pela internet. Controles como WAF, bloqueios de taxa e regras de rota podem reduzir ruído ou bloquear padrões conhecidos, mas não substituem a atualização, porque a causa está na lógica de autorização e roteamento interno do plugin.

Também entram no escopo ambientes que usam gestão centralizada de plugins, cópias de produção para homologação, cache de página e otimizações de JavaScript. Um cache pode continuar servindo checkout com script já injetado mesmo após a remoção da configuração, se a página afetada tiver sido armazenada indevidamente. Pipelines de implantação que restauram banco de dados ou sincronizam opções entre ambientes podem reintroduzir a configuração contaminada. Por isso, a resposta deve abranger versão do plugin, conteúdo atual das opções, histórico de alterações e invalidação de cache.

• Instalações de WordPress com WooCommerce e Funnel Builder anterior a 3.15.0.3.
• Checkouts que usam External Scripts para carregar tags externas ou código de acompanhamento.
• Páginas de pagamento com scripts que imitam Google Tag Manager, analytics ou tags de conversão sem origem validada.
• Ambientes com cache, otimização de JavaScript ou replicação de banco de dados que possam preservar a injeção após a correção inicial.

Hunting e telemetria

A investigação deve começar pela configuração do plugin. A área Settings > Checkout > External Scripts precisa ser comparada com a lista de tags aprovadas pela equipe responsável pela loja. Qualquer carregador de Google Tag Manager, analytics, pixel ou integração de terceiros que não tenha proprietário interno identificado deve ser tratado como suspeito até validação. O operador deve registrar o conteúdo encontrado antes da remoção para preservar evidência, mas não deve executar manualmente URLs suspeitas em navegador comum.

No servidor, a caça deve buscar requisições ao endpoint público de checkout em períodos anteriores à atualização. Como o método interno exato não foi divulgado no material analisado, a melhor abordagem é procurar chamadas anômalas sem sessão autenticada, com parâmetros que selecionem ação ou método, respostas incomuns e alterações próximas no banco de dados de opções do WordPress. Logs de aplicação, logs de WAF, trilhas de auditoria de plugins e registros de alteração em tabelas de opções podem ajudar a delimitar a primeira gravação maliciosa.

No lado do cliente e na rede, os sinais mais fortes são carregamentos de JavaScript externo não reconhecido em páginas de checkout e conexões WebSocket para wss://protect-wss[.]com/ws ou domínios visualmente próximos. Equipes com monitoramento de navegador sintético podem executar checkouts controlados em ambiente isolado e observar recursos carregados, eventos de rede, listeners adicionados a campos de formulário e alterações dinâmicas no DOM. Em endpoints corporativos usados para administração da loja, vale procurar acessos a páginas de checkout durante validação e possíveis downloads de scripts suspeitos em cache do navegador.

A telemetria de pagamento também deve ser correlacionada. A presença do skimmer não prova, por si só, quais transações foram capturadas, mas qualquer checkout concluído enquanto o JavaScript estava ativo deve entrar em análise de risco. A equipe deve cruzar horário de injeção, período de exposição, volume de sessões de checkout, páginas afetadas e eventuais alertas antifraude. Como o skimmer opera no navegador do comprador, os logs do servidor podem não conter os dados exfiltrados, apenas indícios de carregamento do código e de configuração persistente.

• Conteúdo inesperado em Settings > Checkout > External Scripts, especialmente tags que aparentam ser Google Tag Manager.
• Requisições não autenticadas a endpoint de checkout do Funnel Builder com parâmetros de ação, método ou atualização de configuração.
• Carregamento de JavaScript externo em páginas de pagamento sem correspondência com inventário aprovado de tags.
• Conexões WebSocket para wss://protect-wss[.]com/ws ou infraestrutura relacionada durante sessões de checkout.
• Alterações recentes em opções do WordPress associadas ao plugin, próximas a requisições anônimas ou picos de tráfego incomum.

Mitigação

A primeira ação é atualizar o Funnel Builder para 3.15.0.3 ou versão posterior em todas as instalações. A atualização corrige a falha conhecida, mas não remove automaticamente a necessidade de inspeção forense. Se o atacante já gravou JavaScript em External Scripts, a simples atualização pode deixar a carga persistente até que a configuração seja revisada e limpa. Por isso, a ordem recomendada é inventariar instalações, aplicar a atualização, verificar a configuração, remover scripts não aprovados, limpar cache e validar o checkout em navegador isolado.

Após a contenção, a loja deve tratar o caso como possível comprometimento de dados de pagamento digitados no cliente. Isso inclui identificar a janela provável de exposição, revisar transações realizadas no período, preservar logs relevantes e envolver as áreas responsáveis por antifraude, privacidade, jurídico e relacionamento com o provedor de pagamento conforme a política interna. A rotação de credenciais administrativas pode ser prudente se houver outros sinais de comprometimento, mas ela não corrige o vetor descrito, porque a exploração não depende de conta autenticada.

A validação defensiva deve incluir bloqueios preventivos e monitoramento contínuo. Regras de WAF podem ser ajustadas para restringir padrões anômalos contra endpoints de checkout, mas sem bloquear fluxos legítimos de compra. A configuração External Scripts deve ter proprietário definido e controle de mudança, com revisão periódica das URLs permitidas. Também é recomendável manter inventário de tags autorizadas, registrar hashes ou versões esperadas quando aplicável e usar monitoramento de integridade de página para detectar novos scripts em páginas de pagamento.

Como medida de engenharia, equipes que operam lojas WooCommerce devem reduzir dependência de campos livres para JavaScript em fluxos sensíveis. Quando scripts externos forem necessários, o carregamento deve ser documentado, revisado e restrito ao mínimo operacional. Ambientes de produção, staging e testes precisam ter políticas separadas para evitar que uma configuração contaminada seja promovida ou restaurada. A resposta só deve ser considerada encerrada depois que a versão corrigida estiver implantada, a configuração estiver limpa, a página de checkout não carregar recursos suspeitos e a janela de exposição estiver documentada.

• Atualizar Funnel Builder para 3.15.0.3 ou posterior em produção, staging e demais cópias acessíveis pela internet.
• Revisar Settings > Checkout > External Scripts e remover qualquer JavaScript sem proprietário, origem e justificativa operacional.
• Invalidar cache de página, cache de otimização de JavaScript e CDN para impedir que checkouts antigos continuem servindo a carga injetada.
• Executar um checkout controlado em ambiente isolado e inspecionar recursos de rede, conexões WebSocket e listeners em campos de pagamento.
• Preservar logs e conteúdo removido para investigação, delimitar a janela de exposição e avaliar notificações ou ações antifraude conforme o impacto confirmado.
• Criar inventário de tags permitidas em páginas de pagamento e monitorar alterações futuras na configuração do plugin.