Skimmer no checkout: o que o ataque a uma plataforma brasileira ensina sobre segurança no e-commerce
No dia 26 de outubro de 2026, a Sansec, empresa de segurança especializada em e-commerce, publicou uma pesquisa sobre um ataque a lojas brasileiras. Um grupo de Magecart, ativo desde 2024, colocou um skimmer de cartão dentro do script de analytics de uma empresa de e-commerce brasileira, uma plataforma usada por dezenas de marcas de moda no país.
A partir de 24 de outubro, quem finalizava uma compra nesses checkouts enviava, sem saber, o número do cartão, a validade, o CVV, o nome do titular e o CPF para um servidor do atacante. Em 27 de outubro, a plataforma informou que removeu o código malicioso e corrigiu o servidor, e a Sansec confirmou que o script estava limpo.
O caso é sério, mas a lição mais importante não é sobre uma empresa. É sobre arquitetura.
Como o ataque funcionou
O alvo não foi o checkout em si. Foi um script de analytics que rodava dentro dele.
A plataforma usava uma instalação própria do Plausible, uma ferramenta de analytics de código aberto. Segundo a Sansec, a versão instalada não tinha sido atualizada e tinha uma falha crítica corrigida meses antes, que é a provável porta de entrada, ainda não confirmada. O atacante alterou um único arquivo: o script de rastreamento que todo checkout da plataforma carregava.
Como o script rodava na mesma página do formulário de pagamento, ele tinha acesso a tudo o que o cliente digitava. O código malicioso só era ativado na etapa de pagamento, lia os campos do cartão e mandava os dados para fora. Um arquivo comprometido bastou para atingir todas as lojas da plataforma ao mesmo tempo.
É o que se chama de ataque à cadeia de suprimentos. Em vez de invadir loja por loja, o atacante invade um fornecedor que está em todas elas. Segundo a pesquisa, o mesmo grupo também já tinha atacado lojas em Magento, OpenCart e WooCommerce, quase todas no Brasil.
Por que o CPF piora tudo
Cartão vazado se bloqueia e se troca. CPF, não. No Brasil, o CPF é usado por bancos e serviços para identificar a pessoa, e junto com os dados do cartão ele amplia o risco de fraude bem além daquela compra.
Para o lojista, o prejuízo também não termina no estorno. Fica a desconfiança de quem comprou, o desgaste com o meio de pagamento e o trabalho de explicar o que aconteceu.
A lição: menos gente dentro do checkout
Todo script que roda no checkout é uma porta. Analytics, pixel de mídia, chat, teste A/B: cada um é código de terceiro, hospedado por alguém, que precisa ser atualizado e vigiado. Basta um deles ser comprometido para o formulário de pagamento ficar exposto.
É exatamente por isso que a Shopify trata o checkout como uma área fechada.
- O checkout é da Shopify. Ele é hospedado e operado pela própria Shopify, que é certificada PCI DSS nível 1, o nível mais alto de exigência para quem processa cartão.
- Os dados do cartão ficam isolados. Os campos de pagamento são servidos pela Shopify em um ambiente separado da página. Nem o tema da loja nem os apps instalados leem o que o cliente digita ali.
- Script solto não entra. A Shopify encerrou a personalização do checkout por código livre e passou a exigir o Checkout Extensibility. As extensões e os pixels de rastreamento rodam em um ambiente isolado, sem acesso direto à página nem aos campos de pagamento.
- Não existe checkout paralelo. A Shopify não deixa a loja trocar o checkout dela por um checkout de terceiros. Meios de pagamento externos entram como gateways homologados, dentro do fluxo da Shopify.
- A atualização não depende da loja. O ataque provavelmente explorou uma falha que já tinha correção havia meses. Na Shopify, a infraestrutura do checkout é mantida e corrigida pela própria Shopify, sem servidor próprio esperando atualização.
Para quem está acostumado a mexer em tudo, essas regras às vezes parecem uma limitação. Casos como esse mostram o motivo delas. Quando o checkout não aceita qualquer código, o risco de um script comprometido chegar até o cartão do cliente cai drasticamente.
O que vale revisar na sua loja
Nenhuma plataforma dispensa cuidado. Algumas perguntas que valem para qualquer operação:
- Quais scripts de terceiros rodam hoje nas páginas da sua loja, e quem atualiza cada um?
- Algum deles é hospedado em servidor próprio, sem rotina de atualização?
- Os pixels de mídia e analytics estão configurados pelos recursos nativos da plataforma, ou injetados por código solto?
- Você saberia identificar rápido se um desses arquivos mudasse?
Se você comprou com cartão em uma loja brasileira desde 24 de outubro, a pesquisa da Sansec, listada nas fontes abaixo, mostra como identificar os checkouts afetados. Nesse caso, a recomendação é pedir ao banco o bloqueio e a troca do cartão e ficar atento a fraudes com o seu CPF.
Segurança também é escolha de plataforma
Na Disco, segurança entra no projeto desde o desenho. Na Shopify, isso começa pelo checkout fechado e continua no tracking feito pelos recursos nativos, sem script solto rodando onde o cliente digita o cartão.
Se você quer revisar a segurança da sua operação ou migrar para uma plataforma que trata o checkout com esse rigor, fale com a Disco.
