Exposição de credenciais da Stripe ameaça dados de centenas de milhares de clientes

O caso divulgado em 18 de agosto de 2026 é mais bem descrito como uma exposição de credenciais de comerciantes do que como uma invasão confirmada da plataforma Stripe. Relatos apontam para um arquivo gratuito de aproximadamente 35 GB, com 17.654 arquivos de 659 contas de comerciantes e informações associadas a uma estimativa de 688.363 clientes em 42 países. Esses números são estimativas divulgadas nas análises, e outras afirmações mais amplas feitas pelo ator ainda não foram verificadas de forma independente.

O que o arquivo teria reunido

Segundo os relatos, os dados cobriam o período de janeiro de 2022 a junho de 2026. Entre os tipos de informação citados estavam:

• objetos de clientes da Stripe e dados de contato;
• cobranças, intenções de pagamento, sessões do Checkout, faturas, reembolsos e disputas;
• repasses e transações de saldo;
• assinaturas, produtos e preços;
• metadados relacionados a pagamentos, como bandeira do cartão, quatro últimos dígitos, validade, tipo de financiamento, país emissor e impressão digital do pagamento.

As análises disponíveis não indicaram a presença de números completos de cartões. Isso reduz algumas formas de uso direto dos cartões, mas não elimina o risco decorrente da exposição de credenciais de API e de informações detalhadas sobre clientes e transações.

Pesquisadores relataram ter encontrado 650 chaves secretas ativas no formato sk_live e nove chaves restritas. Entre as contas afetadas, 573 poderiam receber pagamentos, 531 poderiam fazer repasses e 519 teriam as duas capacidades, de acordo com a análise citada nos relatos.

Por que uma única chave ativa já seria perigosa

Uma chave secreta da Stripe é uma credencial de API, não apenas um identificador. O alcance real depende das permissões da chave e da configuração da conta do comerciante, mas uma credencial comprometida pode abrir acesso a recursos da empresa e permitir atividades de pagamento não autorizadas.

Os testes descritos nas reportagens indicaram que uma única chave ativa poderia ser usada para acessar listas de clientes, criar links de pagamento fraudulentos e realizar cobranças de teste. Os possíveis impactos incluem enumeração de dados de clientes, abuso de pagamentos, reembolsos indevidos, phishing direcionado e engenharia social relacionada a transações. Contas com permissão para repasses também precisam verificar configurações e dados dos destinos de pagamento.

O principal risco prático é a velocidade: uma credencial exposta em um servidor pode transformar uma falha no gerenciamento de segredos em uma investigação de fraude antes que o comerciante perceba movimentações fora do padrão.

Por que o caso não foi classificado como uma invasão da Stripe

As evidências disponíveis sugerem que os criminosos usaram credenciais válidas de comerciantes para obter dados por meio do acesso legítimo à API da Stripe. Pesquisadores que analisaram os arquivos liberados offline disseram que os objetos no formato da Stripe e a estrutura de diretórios eram compatíveis com exportações feitas por endpoints da API. Como parte dessa análise, eles não se autenticaram com as chaves expostas nem acessaram os ambientes ativos dos comerciantes.

Essa distinção é importante. Ela desloca a provável falha de controle dos sistemas centrais da Stripe para os locais onde os segredos dos comerciantes podem ter sido armazenados ou expostos, como:

• infecções por infostealers em computadores de desenvolvedores ou administradores;
• repositórios públicos e histórico do Git;
• arquivos .env e configurações de servidores expostos;
• armazenamento em nuvem, backups e camadas de contêineres;
• sistemas de integração e entrega contínuas (CI/CD) e logs do GitHub Actions;
• servidores mal configurados ou varreduras automatizadas em busca de variáveis expostas.

A origem inicial do roubo das credenciais de 659 comerciantes ainda não foi estabelecida. Essas são rotas plausíveis de exposição, não uma origem única confirmada para todo o conjunto de dados.

O lançamento relacionado e a cautela com os números

Relatos da Hudson Rock atribuíram ao mesmo ator uma publicação relacionada em um fórum criminoso. Esse lançamento teria envolvido 669 pastas de fornecedores e 1.033 chaves de API comprometidas, com tamanho anunciado de 33 GB; o download vinculado seria menor. O ator também afirmou possuir aproximadamente 20 mil chaves adicionais da Stripe e sugeriu que novos lotes poderiam ser publicados.

Esses números não devem ser somados como se formassem um total verificado. As diferenças entre 659 contas de comerciantes, 669 pastas de fornecedores e 1.033 chaves podem refletir conjuntos de dados distintos, chaves duplicadas ou múltiplas chaves por conta e métodos diferentes de contagem. A cifra de 20 mil chaves continua sendo uma alegação não verificada do ator.

Países com mais comerciantes afetados

A distribuição geográfica citada nos relatos foi liderada por:

• Estados Unidos: 212 comerciantes;
• Reino Unido: 81;
• França: 57;
• Canadá: 38;
• Brasil: 30;
• Austrália: 27.

Esses números representam a distribuição de comerciantes identificada nas análises disponíveis e devem ser interpretados junto da ressalva de que o alcance total do conjunto de dados ainda estava sendo avaliado.

O que as empresas que usam a Stripe devem fazer agora

1. Revogar e substituir as chaves secretas ativas

Revogue e substitua toda chave secreta ativa que possa ter aparecido em código-fonte, logs, backups, telemetria de endpoints, imagens de contêiner ou infraestrutura pública. Não espere identificar uma fraude para trocar uma credencial potencialmente exposta.

2. Auditar a atividade da API e as operações de pagamento

Revise os logs de API e de segurança em busca de chamadas desconhecidas, novos links de pagamento, cobranças de teste ou não autorizadas, reembolsos inesperados, alterações de permissões e endereços IP incomuns. Preserve os registros relevantes para que a equipe de resposta a incidentes possa reconstruir a linha do tempo.

3. Conferir as configurações de repasse

Verifique as configurações de repasses, os dados das contas bancárias conectadas e os destinos dos pagamentos. Alterações suspeitas devem ser comunicadas rapidamente à Stripe e às instituições financeiras, seguindo os procedimentos aplicáveis de resposta e notificação de incidentes.

4. Trocar credenciais amplas por chaves restritas

Use chaves restritas ao menor conjunto de operações de API necessário para cada serviço. Separe sistemas de produção, ambientes de desenvolvimento e funções operacionais, em vez de distribuir um único segredo amplo entre várias aplicações.

5. Procurar segredos em todos os lugares onde eles podem permanecer

Pesquise em repositórios atuais e antigos, histórico do Git, saídas de CI/CD, logs do GitHub Actions, arquivos .env, camadas de contêineres, armazenamento em nuvem, documentação e backups por valores sk_live. Qualquer credencial encontrada deve ser revogada e substituída, mesmo que já não apareça na versão atual do código.

6. Tratar a varredura do GitHub como uma camada, não como cobertura completa

O GitHub informa que a varredura de segredos é executada automaticamente em repositórios públicos, enquanto repositórios privados e internos pertencentes a organizações exigem o GitHub Secret Protection em planos elegíveis. A ferramenta também não consegue recuperar segredos que já foram copiados para logs, backups, telemetria de endpoints ou arquivos baixados. Portanto, ela deve complementar — e não substituir — o gerenciamento centralizado de segredos, credenciais com validade curta, controles de acesso e monitoramento contínuo.

A principal lição para os comerciantes

A conclusão mais clara do caso é que a segurança de uma plataforma de pagamentos também depende da higiene das credenciais mantidas pelos próprios comerciantes. Os relatos disponíveis não comprovam uma invasão da infraestrutura da Stripe, mas mostram como chaves de API ativas expostas podem abrir caminho para acesso a dados de clientes e abuso de pagamentos. Segredos de produção devem ser tratados como credenciais de alto impacto: mantidos fora do código e dos logs, limitados por permissões, rotacionados rapidamente e associados à investigação de qualquer evento inesperado de API ou repasse.