O sequestro do checkout da HulkApps: como apps confiáveis do Shopify se tornaram um funil de phishing

Resumo: o sequestro do checkout da HulkApps no Shopify

• O que aconteceu: a partir de 2026-10-10, compradores de várias lojas Shopify que clicavam em Checkout eram levados a uma página de pagamento falsa em biliing[.]top, que capturava os dados do cartão e depois os encaminhava para o checkout real.
• Como entrou: o arquivo do app Hulk Product Options em cdn.shopify.com estava limpo. O código do ataque voltava da API de configuração da HulkApps num campo de JavaScript personalizado e era injetado em tempo de execução. Swym Wishlist Plus e Selleasy foram atingidos da mesma forma.
• Por que passou despercebido: só disparava num clique real em Checkout, uma vez por sessão do navegador, para domínios que nenhuma lista de bloqueio conhecia. Scanners, CSP e a maioria dos testes manuais viam uma loja normal.

Sem tempo? Veja o monitoramento de scripts client-side da cside. Cobre tudo o que se segue numa única implementação.

Em 2026-10-10, o desenvolvedor Roman Zipp fazia compras numa loja Shopify popular. Colocou um teclado no carrinho, clicou em Checkout e chegou ao que parecia um checkout normal do Shopify. O único sinal foi o gerenciador de senhas oferecendo preencher o campo "Nome" com o nome do cartão de crédito. Ele olhou a barra de endereços: biliing[.]top/check-out/.

O pedido teria sido concluído. Assim que a página falsa obtinha os dados do cartão, enviava-o direto para o checkout verdadeiro da loja. O cartão estaria comprometido, e nada nos dados de pedidos do lojista pareceria fora do normal.

O código não estava no tema da loja, e o checkout do próprio Shopify nunca foi tocado. Ele chegou pelo Hulk Product Options, um app de personalização de produtos da HulkApps com muitas instalações, como um bloco de "JavaScript personalizado" devolvido pela própria API do fornecedor. Em poucos dias, lojistas que nunca tinham instalado um produto da HulkApps relatavam o mesmo checkout falso, rastreado até apps de outros fornecedores. É um ataque à cadeia de suprimentos client-side na sua forma mais pura: um terceiro a quem os lojistas tinham dado acesso legítimo aos navegadores dos clientes virou o canal de entrega.

Como o ataque funcionava

Cada elo dessa cadeia parecia legítimo isoladamente. Zipp o rastreou passo a passo no Chrome DevTools.

1. Um arquivo confiável é carregado. O Hulk Product Options inclui uma extensão de tema que carrega hulkcode.js nas páginas da loja. O arquivo é servido a partir de cdn.shopify.com como parte do pacote da extensão. Ele não foi modificado.
2. O arquivo pede sua configuração. Ao carregar a página, hulkcode.js envia uma requisição POST para productoption.hulkapps.com/api/v2/store/get_all_relationships com o ID da loja e o produto visualizado.
3. A configuração traz código. A resposta JSON inclui um campo advanced_users.custom_js, um recurso que permite aos lojistas adicionar o próprio JavaScript. Nas lojas afetadas, ele continha cerca de 22,7 KB de código de ataque não minificado.
4. O código é injetado em tempo de execução. O app escreve essa string na página como script. No DevTools ele aparece como um script VM anônimo sem arquivo de origem, o que o torna justamente difícil de achar.
5. O clique em Checkout é sequestrado. O script registra um listener de cliques. Quando o comprador clica em Checkout, uma função chamada literalmente hijack cancela a navegação real e redireciona para um checkout falso num domínio do atacante.
6. O checkout falso coleta o cartão. A página falsa imita um checkout do Shopify e pede dados de pagamento e pessoais.
7. Os dados saem. O formulário envia tudo para /api/submissions no domínio do atacante, que responde com um ID de registro.
8. O comprador é devolvido. A página falsa encaminha o comprador ao checkout verdadeiro do Shopify, onde o pedido é concluído normalmente. O script também grava __ctf_shim_handoff_done_v1 no armazenamento de sessão para nunca disparar duas vezes na mesma sessão.

As etapas 1 e 2 são exatamente o que o app faz em todas as lojas, todos os dias. Todo o ataque estava nos dados que a API do fornecedor devolvia.

As escolhas de design são deliberadas. Redirecionar apenas no clique em Checkout faz os carregamentos passivos de página parecerem limpos. Disparar uma vez por sessão faz com que o lojista, o fornecedor do app e qualquer pessoa que investigue a reclamação de um cliente normalmente vejam um checkout normal ao tentar reproduzir. E como o pedido roubado é concluído no checkout real, os painéis de receita não mostram nada estranho.

Nunca foi só a HulkApps

A HulkApps foi o primeiro nome ligado a esta campanha, mas a história não termina aí. Vários apps populares de fornecedores diferentes entregaram o mesmo redirecionamento para a mesma família de domínios, e em todos os casos a carga estava em dados de configuração que o app buscava nos servidores do fornecedor.

É tentador ler isso como a violação de um único fornecedor. As evidências apontam para algo mais desconfortável: alguém percorrendo sistematicamente apps do Shopify que permitem que dados de configuração virem código executável na loja. Ainda não se sabe se isso aconteceu por uma fraqueza comum, credenciais roubadas ou várias invasões separadas. Em 2026-10-16, as páginas da App Store do Hulk Product Options, Swym Wishlist Plus e Selleasy apareciam como indisponíveis, e uma lojista australiana disse ao iTnews que o Shopify a aconselhou a manter a loja fechada.

Por que escapou das defesas habituais

O ataque não era código sofisticado. Era um posicionamento sofisticado. Quase todos os controles em que um lojista poderia confiar olhavam para a camada errada.

• O arquivo do script nunca mudou. hulkcode.js vinha de cdn.shopify.com com o mesmo conteúdo de sempre. Verificações de hash e o Subresource Integrity teriam passado, porque a parte maliciosa chegava como dados, não como arquivo.
• As origens já eram confiáveis. O CDN e a API do fornecedor são exatamente os hosts que a Content Security Policy de uma loja permitiria. Nada novo apareceu nas listas de scripts ou de conexões. Permitir esses hosts não basta, por si só, para que uma loja execute uma string de código vinda de uma API: um script-src restrito sem 'unsafe-inline' ou 'unsafe-eval' a teria recusado. Mas os temas e apps de loja dependem muito de scripts inline, então poucas lojas conseguem adotar uma política tão restrita.
• O roubo acontecia fora do site. O formulário do cartão ficava no domínio do atacante, então nenhum dado saía da própria página da loja. A CSP não controla a navegação de nível superior, e o connect-src da loja nunca viu a requisição de exfiltração.
• O gatilho exigia um clique real. Scanners sintéticos que rastreiam páginas, ou até carregam o carrinho, não clicam em Checkout como um comprador. Para eles, a carga ficava inativa.
• Rodava uma vez por sessão. Os testes manuais de lojistas e equipes de suporte muitas vezes voltavam limpos, o que atrasou os relatos e fez as primeiras reclamações parecerem casos isolados.
• As listas de bloqueio foram lentas. Em 2026-10-10, nenhum dos três domínios que Zipp encontrou estava no Google Safe Browsing ou no URLhaus, e seus bloqueadores de anúncios e filtros DNS os deixaram passar. Uma publicação no Reddit tinha relatado o mesmo domínio cerca de 18 dias antes.
• O checkout do Shopify estava bem. O checkout do Shopify nunca foi comprometido, e esse é o ponto. O ataque rodava na loja, antes da página de pagamento, onde as proteções da plataforma não chegam.

O único lugar confiável para ver este ataque é onde ele realmente rodava: dentro do navegador de um comprador real, no momento em que o script religava o botão de checkout.

Indicadores de comprometimento

Os domínios estão neutralizados. Não os visite.

Se encontrar qualquer chave __ctf_ no armazenamento de sessão da sua loja, trate como um caso confirmado desta campanha.

O que os lojistas devem fazer agora

Se você tem uma loja Shopify com apps de terceiros, parta do princípio de que precisa verificar, mesmo que nunca tenha instalado nada da HulkApps.

1. Teste o checkout numa sessão nova, mais de uma vez. Abra uma nova janela privada, adicione um produto, clique no botão Checkout normal e observe a barra de endereços. Feche a janela e repita. Faça também pela gaveta do carrinho e num celular. O seu checkout deve permanecer no seu próprio domínio ou no seu endereço myshopify.com.
2. Procure a marca de sessão. Após um teste, abra o DevTools, vá em Application e depois Session storage, e procure chaves que comecem com __ctf_.
3. Audite configurações de apps que aceitam código. Qualquer app com um campo de "JavaScript personalizado" ou "HTML personalizado" é um lugar onde código pode se esconder. Abra cada um e confirme que reconhece tudo o que está lá.
4. Faça o inventário dos seus app embeds. No editor de temas, liste todos os app embeds ativados. Desative e desinstale o que não usa ativamente e depois verifique o tema em busca de trechos remanescentes.
5. Troque as credenciais. Altere sua senha do Shopify e a senha do painel de cada fornecedor de app, e ative a autenticação em dois fatores onde for oferecida. Revise o acesso de colaboradores.
6. Se encontrar, preserve primeiro as evidências. Faça uma captura da página falsa com a URL visível, salve um arquivo HAR na aba Network e anote o horário. Depois desative o app, contate o fornecedor por escrito, abra um chamado no suporte do Shopify e avise o seu processador de pagamentos.
7. Busque orientação sobre notificação. Dados de cartão digitados numa página falsa acessada a partir da sua loja podem gerar obrigações perante clientes ou bandeiras de cartão. Converse com o seu processador e com o seu assessor jurídico.

Um alerta dos lojistas afetados no tópico da Shopify Community: a confirmação do fornecedor de que o código foi removido nem sempre bastou para o Shopify liberar a reabertura de uma loja. Guarde tudo por escrito.

A perspectiva do PCI DSS 4.0.1

Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 existem exatamente para esse tipo de ataque. O 6.4.3 pede que os lojistas inventariem todos os scripts das páginas de pagamento, justifiquem cada um e confirmem que estão autorizados e íntegros. O 11.6.1 pede um mecanismo que detecte alterações não autorizadas nessas páginas tal como o navegador do comprador as recebe. Ambos são obrigatórios desde 2025-03-31.

Muitos lojistas do Shopify presumem que esses requisitos são problema do Shopify. Para o checkout em si, em grande parte são, como explicamos em o Shopify torna você compatível com o PCI?. Mas desde janeiro de 2025, lojistas que validam com o SAQ A precisam confirmar que o site não é suscetível a ataques por scripts que possam afetar os seus sistemas de e-commerce. Um script na loja que troca silenciosamente o seu checkout pelo de outra pessoa é exatamente isso. Confirme com o seu adquirente quais obrigações se aplicam a você.

Este incidente também mostra por que um inventário estático de scripts não basta sozinho. O inventário teria listado hulkcode.js, corretamente, como autorizado. O que mudou foi o comportamento: ele buscou código novo, injetou-o, adicionou um handler de clique e levou o comprador a um domínio que a loja nunca tinha usado. Ver isso exige observar o que os scripts realmente fazem em sessões reais, e não apenas quais arquivos são carregados.

Como a cside aborda esse tipo de ataque

Sessões reais, não rastreamentos sintéticos. A cside monitora scripts de terceiros em sessões reais de compradores em vez de depender de uma varredura periódica. Uma carga que só dispara num clique real em Checkout, uma vez por sessão, continua rodando à nossa frente.

Comportamento, não só origem. Acompanhamos o que cada script faz: o código que injeta, os listeners que adiciona, os dados que lê e para onde os envia. Um script de app confiável que de repente escreve código novo na página e leva compradores a um domínio que a sua loja nunca usou é um sinal por si só, e não algo escondido atrás de um host permitido.

Interrompido 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, ao lado da CSP. Um script não autorizado, ou uma capacidade específica que ele tente usar, é interrompido na sessão em vez de ser reportado depois do fato.

Nenhum controle isolado teria impedido todas as versões desta campanha. Mas a lição é a mesma em todos os fornecedores envolvidos: se código de terceiros roda nos navegadores dos seus clientes, você precisa de visibilidade nos navegadores dos seus clientes. É a mesma lição que o ataque à cadeia de suprimentos da Polymarket deixou no início deste ano, por outro fornecedor e contra outro tipo de vítima.

O que ainda não sabemos

• Como os atacantes entraram. A HulkApps fala em um exploit e a Logbase em acesso a uma ferramenta interna. Nenhuma publicou a causa raiz.
• Se os incidentes estão ligados. Domínios em comum e marcas __ctf_ idênticas sugerem o mesmo operador, mas nem os fornecedores nem o Shopify confirmaram.
• Quantas lojas e compradores foram afetados. O Shopify não publicou números.

Vamos atualizar este artigo à medida que os fornecedores e o Shopify publicarem mais informações. O crédito pela descoberta, pela engenharia reversa e pela linha do tempo pública é de Roman Zipp.

Os detalhes acima refletem as informações públicas e as declarações dos fornecedores em 2026-10-16.

Quer ver o que realmente roda nos navegadores dos seus compradores? Comece grátis ou agende uma demo para conversar com a nossa equipe.