# 659 comerciantes de Stripe expuestos — cómo una clave filtrada permite fraude en menos de un día
Investigadores validaron claves API activas en un dataset de 35 GB publicado en agosto: acceso completo a clientes, pagos y webhooks sin compromiso del proveedor.
El 18 de agosto de 2026 apareció en un foro de comercio de datos un archivo de 35 GB con claves API vivas de Stripe correspondientes a 659 cuentas de comerciantes, junto con datos de clientes y transacciones extraídos de esas cuentas. Investigadores de Ransomnews analizaron el dataset de forma offline, reportaron la exposición a Stripe antes de publicar y documentaron qué tan rápido un atacante podría monetizar una de esas claves. La respuesta: 17 horas desde el hallazgo de una clave activa hasta completar un cargo de prueba de un dólar usando un enlace de pago fraudulento creado con acceso legítimo a la API. Stripe como plataforma no fue comprometida — las claves pertenecen a los comerciantes, y la fuga es el resultado acumulado de malas prácticas de gestión de secretos en repositorios públicos, logs de compilación y servidores web mal configurados.
Cómo 50,000 claves terminaron indexadas en código público y logs de compilación
Los investigadores identificaron más de 50,000 claves API únicas de Stripe expuestas en distintas fuentes. La mayor parte proviene de repositorios de GitHub — tanto públicos como accidentalmente hechos públicos — donde las claves aparecen hardcodeadas en archivos de configuración, archivos .env subidos sin la entrada correspondiente en .gitignore, o dejadas en comentarios de código. La segunda fuente principal son los logs de GitHub Actions: cuando un workflow imprime variables de entorno para debugging y un secreto no fue enmascarado correctamente, cualquier persona con acceso al repositorio puede leer la clave en el log de compilación.
Los servidores web mal configurados representan otra fuente significativa. Los investigadores encontraron más de 3,000 servidores revelando cadenas relacionadas con Stripe, y aproximadamente el 12 por ciento de esos servidores contenía claves que funcionaban contra la API de Stripe. El origen específico del dataset de 659 comerciantes no está documentado en el reporte, pero los candidatos probables incluyen logs de infostealers extraídos de máquinas de desarrolladores, claves en repositorios públicos, archivos de entorno expuestos y backups mal configurados. Lo que distingue a este dataset no es la recolección de claves — eso es común — sino la validación sistemática de varios cientos de ellas y el recorrido completo de la API para cada cuenta, archivando los resultados en una estructura de carpetas consistente.
Qué permite hacer una clave secreta de Stripe sin restricciones
Una clave secreta de Stripe no es una credencial parcial — es acceso completo a la API. Con una clave activa, un atacante puede listar clientes y sus métodos de pago almacenados, crear cargos e intenciones de pago, emitir reembolsos a cuentas controladas por el atacante, modificar endpoints de webhook para interceptar notificaciones de pagos futuros, y en algunos casos acceder a cuentas conectadas si el comerciante habilitó Stripe Connect. Los investigadores demostraron la viabilidad de este acceso accediendo a la lista de clientes de un comerciante, creando un enlace de pago fraudulento y completando un cargo de prueba en menos de un día.
Stripe proporciona escaneo automático de secretos a través del programa asociado de GitHub, que detecta claves de Stripe en repositorios públicos y puede activar revocación automática cuando un comerciante opta por esa función. El problema es que la tasa de adopción es baja, el escaneo no cubre repositorios privados, y no tiene cobertura sobre logs de compilación, servidores web mal configurados ni otras plataformas donde las claves aparecen. Los investigadores también encontraron que algunos comerciantes habían rotado sus claves después de una exposición en GitHub pero dejaron las claves antiguas activas, posiblemente porque Stripe no revoca claves en la rotación a menos que se elimine explícitamente la clave anterior.
Por qué México y Brasil quedan expuestos por dependencia de integraciones sin claves restringidas
El reporte no desglosa la distribución geográfica de los 659 comerciantes afectados, pero el patrón de exposición tiene implicancias directas para América Latina. México y Brasil concentran el mayor volumen de comercio electrónico de la región y dependen de Stripe para procesamiento de pagos en sectores como SaaS, marketplaces y suscripciones digitales. La práctica documentada de usar claves secretas completas en integraciones que no requieren acceso total — como handlers de webhook que solo necesitan leer eventos, no crear cargos — es común en equipos de desarrollo con presión de tiempo para lanzar productos, especialmente en startups que priorizan velocidad sobre seguridad de credenciales.
La falta de adopción de claves restringidas de Stripe (restricted keys) en la región se agrava por la ausencia de auditorías de secretos en el historial de control de versiones. Un comerciante puede rotar una clave después de detectar una exposición en GitHub, pero si no elimina explícitamente la clave anterior en el panel de Stripe, esa clave sigue funcionando. En un contexto donde muchas empresas latinoamericanas recién están formalizando prácticas de DevSecOps, la brecha entre rotar y revocar es un vector de persistencia que los atacantes pueden explotar meses después de la exposición inicial.
Nuestro análisis
Este caso confirma un patrón que ya vimos en exposiciones previas de credenciales de proveedores cloud: el problema no es que Stripe sea inseguro, sino que la gestión de secretos sigue siendo el eslabón más débil en la cadena de integración de APIs. La diferencia con incidentes anteriores es la escala de validación sistemática — 659 cuentas con claves activas organizadas en un dataset comercializable no es un hallazgo oportunista, es el resultado de un esfuerzo sostenido de recolección y verificación. El hecho de que los investigadores pudieran completar un cargo fraudulento en 17 horas usando una clave encontrada en el dataset demuestra que el tiempo entre exposición y explotación es medible en horas, no en días.
Lo que todavía no sabemos es cuántas de esas 659 claves ya fueron usadas para fraude antes de que el dataset apareciera en el foro de comercio de datos. Stripe no publica métricas de revocación reactiva ni de detección de uso anómalo de claves comprometidas. Tampoco está claro si los comerciantes afectados recibieron notificación directa de Stripe o si la remediación depende de que cada comerciante audite su propio historial de control de versiones. Si la rotación de claves sigue siendo manual y la revocación de claves antiguas no es automática, ¿cuántos comerciantes están operando con claves expuestas que todavía no saben que están expuestas?