Plugins, temas e scripts comprometidos: a porta do golpe do Pix

Em lojas legítimas, o golpe do Pix raramente começa no Pix. Começa num plugin, num tema ou num script de terceiro que roda na página de pagamento e passa a ser controlado por criminosos. Como tudo o que a página carrega tem o mesmo poder sobre o que o cliente vê, um único componente comprometido basta para trocar o QR Code, alterar o código copiado ou capturar dados de cartão. Reduzir a exposição significa ter menos componentes no checkout, saber exatamente quais são e perceber quando algo muda.

Por que um componente de terceiro tem tanto poder

A página de pagamento que o cliente vê é montada no navegador dele a partir de muitas peças: o código da plataforma, o tema, os plugins de frete, cupom e avaliações, o chat de atendimento, as ferramentas de análise e de anúncios, bibliotecas buscadas em servidores externos. O navegador não distingue o que é “da loja” do que é “de terceiro”. Qualquer uma dessas peças pode ler e alterar qualquer parte da página, inclusive o QR do Pix, o botão de copiar e os campos do cartão.

Isso cria uma cadeia de confiança longa. A loja confia no fornecedor do plugin, que confia na própria conta de publicação, que depende de senhas, servidores e domínios que a loja nunca vê. Basta um elo ceder.

Três portas de entrada já documentadas

O domínio que mudou de dono. Em junho de 2024, a Sansec alertou que o polyfill.io, um serviço usado por mais de 100 mil sites para carregar uma biblioteca de compatibilidade, havia sido comprado por outra empresa meses antes e passara a injetar código malicioso nos sites que o usavam. Os sites não mudaram uma linha: o script que eles já carregavam é que mudou na origem.

A atualização adulterada. No mesmo mês, segundo o BleepingComputer, a equipe da Wordfence identificou cinco plugins publicados no diretório oficial do WordPress que receberam código malicioso, somando mais de 35 mil sites. A versão adulterada criava contas de administrador para os invasores e enviava os dados a um servidor externo. Quem atualizou em dia recebeu o problema.

O serviço embutido na página de pagamento. O ICO, autoridade de proteção de dados do Reino Unido, multou a Ticketmaster UK em 2020 por não ter adotado medidas adequadas para evitar um ataque a um chatbot instalado na sua página de pagamento online. Segundo o relatório anual do órgão, o vazamento afetou 9,4 milhões de clientes na Europa.

O padrão continua ativo. Em janeiro de 2026, a Malwarebytes repercutiu uma pesquisa da Silent Push sobre uma campanha ativa desde o início de 2022 que inseria código em páginas de checkout para capturar dados de cartões de seis bandeiras, com um script capaz de se remover da página para dificultar a investigação.

Do roubo de cartão à troca do Pix

Os casos acima envolvem cartão, redirecionamentos ou contas de administrador, mas o acesso que permite qualquer um deles é o mesmo: um script com poder sobre a página. Quem consegue ler o número do cartão digitado consegue, com o mesmo acesso, reescrever o QR do Pix e o texto do Copia e Cola.

No Pix, o resultado tem uma característica cruel. O pagamento é instantâneo, válido e no valor certo, só que para a conta de outra pessoa. Não há uma etapa posterior em que alguém revise a transação. A loja não recebe, o cliente acha que pagou, e a recuperação depende de contestação, comprovação da fraude e saldo na conta de destino. Por isso, nos meios instantâneos, a segurança da página de pagamento deixa de ser só um tema de conformidade e passa a ser receita.

O que reduz a exposição

O PCI SSC publicou em março de 2025 um guia sobre os requisitos 6.4.3 e 11.6.1 do PCI DSS, que tratam justamente dos scripts da página de pagamento e de alterações não autorizadas nela. A lógica serve para qualquer meio de pagamento:

• Inventário com justificativa. Liste cada script que carrega no checkout, quem fornece e por que ele precisa estar ali. O que não tiver justificativa sai.
• Checkout enxuto. Chat, pop-ups, widgets de avaliação e ferramentas de remarketing raramente precisam estar na página onde o pagamento acontece.
• Origem sob controle. Evite carregar bibliotecas essenciais de domínios que você não controla e fixe as versões usadas. O caso polyfill.io mostra o risco de depender de um endereço externo.
• Atualização com critério. Aplique correções de segurança, remova plugins e temas parados e nunca use versões piratas, que já chegam com código de origem desconhecida.
• Contas protegidas. Exija verificação em duas etapas no painel da loja, use senhas únicas e revise periodicamente a lista de administradores.
• Vigilância do que chega ao cliente. Monitore a página como ela é entregue ao navegador, não só os arquivos no servidor, com alerta para qualquer script novo ou alterado.
• Plano de resposta. Defina quem desliga o Pix, remove o componente suspeito e avisa clientes se algo for detectado.

Veja como essa conferência funciona na página de proteção do Pix e na de proteção do cartão.

Nenhum inventário impede que um fornecedor confiável seja comprometido amanhã. O Proteside atua no último ponto possível: no navegador do comprador, confere se o QR, o Copia e Cola e o formulário de cartão são exatamente os que a loja emitiu, bloqueia a troca antes do pagamento e gera evidência para o PCI DSS. Dá para testar por 14 dias grátis.