Magecart: o que é e como proteger o e-commerce, do cartão ao Pix

Magecart é o nome dado aos ataques que colocam código malicioso na página de pagamento de uma loja virtual legítima para desviar o que o cliente digita ou paga. Durante anos o alvo foi o número do cartão. Em setembro de 2026, uma campanha no Brasil mostrou o mesmo tipo de código trocando o QR do Pix. A loja continua no ar, com a marca certa e o preço certo, e o cliente não vê nada de errado.

De onde vem o nome

O nome junta Mage, de Magento, e cart, carrinho em inglês. Pesquisadores começaram a usá-lo em meados da década passada para os grupos que atacavam carrinhos de compra dessa plataforma. Com o tempo, o termo passou a designar a técnica em si, em qualquer plataforma de e-commerce, em loja própria ou em serviço de terceiros.

O que define um ataque Magecart não é a ferramenta usada, mas o lugar: a página em que o cliente informa como vai pagar.

Como um ataque Magecart funciona

1. Entrada. O código chega por uma falha não corrigida na plataforma, por um plugin ou tema vulnerável, por uma senha de painel vazada ou por um script de terceiro comprometido. Em junho de 2024, um único serviço de scripts usado por mais de 100 mil sites passou a entregar código malicioso depois de mudar de dono.
2. Disfarce. O trecho costuma ter poucas linhas ofuscadas e fica dentro de um arquivo legítimo, de uma imagem ou de um serviço que a loja já considera confiável. Em abril de 2026, pesquisadores encontraram o código escondido em uma imagem invisível em cerca de 100 lojas. Em junho, outra família guardava o código e os dados roubados dentro de um serviço de pagamento conhecido, para que o tráfego parecesse normal.
3. Ação só no checkout. O código fica quieto nas outras páginas. Quando o cliente chega ao pagamento, ele lê os campos do cartão de crédito ou do cartão de débito, ou troca o QR, o Pix Copia e Cola ou a linha digitável do boleto.
4. Saída. No cartão, os dados vão para um servidor do atacante e são usados depois. No Pix, o próprio cliente manda o dinheiro para a conta errada, na hora.

Os casos que definiram o problema

• British Airways, 2018. Um script alterado no site e no aplicativo copiou dados de pagamento durante cerca de duas semanas. O órgão britânico de proteção de dados contou 429.612 pessoas afetadas e aplicou multa de 20 milhões de libras em outubro de 2020.
• Europol, 2023. Uma operação coordenada pela Europol notificou centenas de lojas virtuais em vários países que tinham código de roubo de cartão ativo na página de pagamento, a maioria sem saber.
• 2026. As pesquisas do ano mostram o código migrando para lugares que as defesas comuns não olham: dentro de imagens e de serviços de pagamento legítimos, onde a loja raramente procura.
• Brasil, setembro de 2026. O pesquisador independente conhecido como eremit4 identificou, e a Kaspersky confirmou, 90 lojas de pequeno e médio porte com código que trocava o QR e o Pix Copia e Cola no checkout. Quando o cliente escolhia cartão, o mesmo código copiava os dados. O pesquisador chamou o caso de "o novo magecart brasileiro". Detalhamos esse caso em Magecart no Pix.

Por que a loja demora a perceber

No cartão, a venda é aprovada e o dinheiro entra. O prejuízo aparece semanas depois, na fatura do cliente, e só quando o banco emissor cruza vários casos chega à conclusão de que todos compraram na mesma loja.

No Pix, a venda simplesmente não entra. O painel mostra pedido pendente ou abandonado, e a reclamação chega dias depois, quando o produto não foi enviado. Lojistas atingidos em 2026 relataram primeiro um aumento de desistências, antes de entender o que estava acontecendo.

Em todos os casos, o servidor pode parecer limpo. Se o código vem de fora ou é montado no navegador, a cópia dos arquivos da loja não muda. O que muda é o que o cliente vê.

O que o PCI DSS pede

Desde 31 de março de 2025, os requisitos 6.4.3 e 11.6.1 do PCI DSS são obrigatórios para quem aceita cartão online. O 6.4.3 pede um inventário dos scripts da página de pagamento, com justificativa e garantia de integridade de cada um. O 11.6.1 pede um mecanismo que detecte alterações não autorizadas na página e nos cabeçalhos de segurança, com verificação pelo menos semanal.

Os dois foram escritos por causa do Magecart no cartão. Eles não falam de Pix nem de boleto, embora o código que troca um QR rode na mesma página e pelo mesmo caminho. Explicamos os dois requisitos em PCI DSS 6.4.3 e 11.6.1.

Como proteger o e-commerce contra Magecart

1. Feche as portas de entrada. Atualize plataforma, tema e plugins, e remova o que não usa. A maior parte das campanhas explora falhas conhecidas e já corrigidas.
2. Proteja o painel. Autenticação em dois fatores para todos os administradores, revisão das contas com acesso e troca das senhas de integrações.
3. Reduza o que roda no checkout. Cada script na página de pagamento precisa de um dono e de um motivo. Chat, mapa de calor e pixel de anúncio raramente precisam estar ali.
4. Prefira campos de cartão hospedados pelo provedor. Eles reduzem o risco de cópia direta, mas a página ao redor ainda pode exibir um formulário falso. Veja o que os campos hospedados resolvem e o que não resolvem.
5. Limite para onde a página pode enviar dados. Uma política de segurança de conteúdo bem configurada atrapalha o envio para servidores desconhecidos. Ela não ajuda quando o atacante usa um serviço que a loja já liberou.
6. Monitore a página como o cliente a vê. O arquivo no servidor pode estar certo e a tela estar errada. Veja como monitorar alterações no checkout.
7. Confira o código de pagamento exibido. No Pix, no boleto e na carteira de stablecoins, compare o que a tela mostra com o que a loja emitiu, antes de o cliente pagar.
8. Tenha um plano para o dia do incidente. Quem desliga o meio de pagamento afetado, quem fala com o provedor, como avisar clientes e como guardar a evidência.

Sinais de que a loja pode ter sido atingida

• Aumento de Pix pendente, sem queda equivalente nas visitas ao checkout.
• Clientes dizendo que pagaram e o pedido não foi aprovado, com comprovante em nome de outra empresa.
• Aviso do provedor de pagamento ou do adquirente sobre cartões usados em fraude depois de compras na loja.
• Arquivos alterados sem que ninguém tenha publicado nada, ou um administrador que ninguém reconhece.
• A página de pagamento enviando dados para domínios que a equipe não conhece.

Se dois desses sinais aparecerem juntos, trate como incidente até provar o contrário.

Onde o Proteside entra

O Proteside é uma camada de cibersegurança que confere, na tela de quem paga, se os dados de pagamento são os que o vendedor emitiu, e bloqueia a troca antes da confirmação. Ele faz o inventário de scripts que o PCI DSS pede e vai além: compara o QR, o Copia e Cola, a linha digitável e o formulário de cartão com o que a loja gerou, em cada pedido, e registra cada tentativa como evidência. Veja como funciona para o cartão de crédito e para a conformidade com o PCI DSS.