Exposición de claves de Stripe puso en riesgo 688.363 registros de clientes

La exposición relacionada con Stripe del 18 de agosto de 2026 parece haber sido un compromiso masivo de credenciales de comercios, no una intrusión confirmada en la infraestructura propia de Stripe. Un actor que utilizaba el alias «Satanic» habría publicado el material en el foro ilícito pwnforums, incluyendo claves secretas activas y datos obtenidos de cuentas individuales de comerciantes.

El alcance reportado

El análisis más detallado describe un conjunto de datos asociado a 659 cuentas de comercios, 650 claves secretas activas sk_live y aproximadamente 688.363 registros de clientes de 42 países. El archivo tendría unos 35 GB, distribuidos en 17.654 archivos.

El material habría incluido información de clientes y registros relacionados con:

• Cargos
• Payment Intents, es decir, intenciones de pago
• Facturas
• Transferencias a comercios
• Reembolsos
• Transacciones de saldo

Los registros estarían fechados entre enero de 2022 y junio de 2026.

El incidente también implicaba un riesgo directo para las operaciones de pago: según los informes, 519 de las 659 cuentas podían tanto aceptar pagos como emitir transferencias. Si las credenciales seguían activas, esa combinación podría facilitar operaciones fraudulentas o intentos de desviar fondos.

La mayor concentración de comercios afectados se encontraba en Estados Unidos, con 212 cuentas, seguido del Reino Unido, con 81, y Francia, con 57.

Quién publicó los datos

El material se atribuyó al actor «Satanic», quien supuestamente lo publicó el 18 de agosto en pwnforums. La información se habría ofrecido para su descarga, en lugar de venderse.

Sin embargo, las cifras de la publicación inicial no coinciden exactamente con las del conjunto de datos validado posteriormente. Un análisis relacionado de Hudson Rock describió 669 carpetas de proveedores, 1.033 claves API comprometidas y un archivo anunciado de 33 GB.

Las diferencias podrían deberse a distintas fases de publicación, métodos de conteo o criterios de validación. Por eso, no deben sumarse ni interpretarse como un único total confirmado. La afirmación de que el actor poseía unas 20.000 claves API adicionales de Stripe para futuras publicaciones tampoco ha sido verificada de forma independiente.

Hudson Rock también señaló que una publicación del foro anunciaba 33 GB, mientras que el archivo descargable ocupaba aproximadamente 2,37 GB. La discrepancia es compatible con —aunque no demuestra— la posibilidad de que hubiera más material fuera de la descarga inicial.

Por qué no parece una brecha de la infraestructura de Stripe

Los informes disponibles indican que los atacantes podrían haber utilizado claves secretas robadas de comercios para realizar solicitudes API normales de Stripe. En ese escenario, los datos se habrían recopilado mediante credenciales con acceso a cuentas individuales, no mediante una vulnerabilidad en los sistemas centrales de Stripe. Los investigadores no encontraron pruebas de que la infraestructura principal de Stripe hubiera sido comprometida.

Entre las posibles vías de exposición de las claves se encuentran:

• Registros procedentes de infostealers, programas que roban credenciales
• Commits de código públicos
• Archivos .env expuestos
• Copias de seguridad inseguras
• Registros de sistemas CI/CD
• Servidores web mal configurados
• Escaneos automatizados en busca de variables de entorno y otros secretos mal protegidos

En el momento de los informes, los investigadores no habían relacionado una infección concreta por infostealer con los dominios de los comercios incluidos en el conjunto de datos. Por tanto, el origen exacto de las credenciales seguía sin resolverse.

La distinción es importante para la respuesta al incidente. Una intrusión en la infraestructura de Stripe implicaría un evento de seguridad de alcance general; la exposición de claves de comercios apunta, en cambio, a numerosas credenciales filtradas por separado y utilizadas contra las cuentas que controlaban.

Qué podía hacer un atacante con una sola clave activa

Los investigadores informaron de que una única clave activa bastó para acceder a la lista de clientes de un comercio, crear un Payment Link fraudulento y realizar un cargo de prueba en un plazo de 17 horas.

La demostración explica por qué una clave secreta activa y con permisos amplios debe tratarse como un incidente inmediato de seguridad de la cuenta. Si la clave ya autoriza el acceso a datos de clientes y funciones de pago, el atacante no necesita vulnerar directamente Stripe.

El posible impacto va más allá de la divulgación de información. Dependiendo de los permisos de la clave y de la configuración de la cuenta, un acceso no autorizado podría exponer registros de pagos o permitir acciones relacionadas con enlaces de pago, cargos, reembolsos y transferencias. El conjunto analizado incluía varias de esas categorías, pero los informes disponibles no demuestran que todas las cuentas mencionadas hubieran sufrido actividad fraudulenta.

El problema de escanear solo los repositorios

El incidente también muestra por qué revisar únicamente los repositorios públicos no basta para proteger las credenciales de pago. Los investigadores identificaron posibles puntos de exposición en registros de GitHub Actions, artefactos históricos, archivos .env públicos, copias de seguridad y servidores mal configurados, lugares que pueden quedar fuera de un escaneo convencional de repositorios.

Otro informe indicó que los investigadores habían identificado más de 50.000 secretos de Stripe en código público, registros de GitHub Actions y servidores mal configurados. Esa cifra describe un problema de descubrimiento más amplio y no significa necesariamente que todas esas claves formaran parte del conjunto publicado el 18 de agosto.

Para las empresas, la lección práctica es clara: borrar un secreto del repositorio actual no lo vuelve seguro. Pueden existir copias en el historial de commits, registros de compilación, artefactos, copias de seguridad o sistemas desplegados. Una clave potencialmente expuesta debe revocarse o rotarse, y también hay que investigar los sistemas relacionados.

Qué deberían hacer ahora los comercios de Stripe

Los comercios que puedan haber expuesto credenciales deberían priorizar la contención:

1. Revocar o rotar de inmediato las claves secretas activas potencialmente expuestas. Eliminar un archivo o una entrada del repositorio no invalida la clave.
2. Revisar la actividad de la API y de la cuenta de Stripe en busca de direcciones IP desconocidas, accesos a listas de clientes, exportaciones de datos, creación de Payment Links, intentos de pago, reembolsos y transferencias inusuales.
3. Verificar los datos de las cuentas bancarias receptoras y los cambios recientes en las transferencias. Cuando corresponda, aumentar temporalmente la supervisión o establecer controles adicionales para los movimientos de fondos.
4. Sustituir las claves amplias por claves restringidas, con permisos limitados a las operaciones que realmente necesita cada aplicación.
5. Guardar los secretos en un gestor especializado y retirarlos del código fuente, los archivos de entorno, los registros y las copias de seguridad sin protección.
6. Buscar en repositorios históricos, registros de CI/CD, artefactos, servidores y copias de seguridad, no solo en el código público más reciente.

La evidencia disponible respalda una exposición grave de credenciales de comercios, con un riesgo considerable para los datos de clientes y las operaciones de pago. No permite afirmar que la infraestructura central de Stripe haya sido vulnerada. Además, las cifras contradictorias indican que los totales deben leerse como estimaciones específicas de cada conjunto de datos, no como un inventario definitivo.