Ilustración editorial generada con IA por Defensops. No es una fotografía del incidente ni de los equipos afectados. Representa Ilustración editorial de credenciales persistentes en copias de repositorios.

Síntesis y análisis propios a partir de la cobertura de BleepingComputer; las afirmaciones del medio se atribuyen a su fuente.

Qué se ha confirmado

Según BleepingComputer, Truffle Security identificó 543.699 credenciales únicas todavía operativas en un análisis de repositorios públicos de GitHub; aparecían repetidas en más de 1,1 millones de archivos y repositorios, incluidos forks.

La publicación describe un rastreo de 224 millones de repositorios y más de 58 mil millones de archivos, con una mediana de 784 días de accesibilidad pública por credencial única.

El mecanismo Push Protection de GitHub busca patrones de secretos y puede bloquear su subida, pero no revoca credenciales que ya quedaron expuestas.

Truffle Security calcula que el 51,8 % de las credenciales válidas pertenecía a categorías que la protección predeterminada no bloquea, entre ellas cadenas de conexión a bases de datos y claves de API de Google.

Dentro de las categorías cubiertas, la investigación observó una reducción del 53 % en la tasa de credenciales expuestas tras activar la protección por defecto.

El estudio encontró una credencial npm aún funcional entre 101.886 tokens publicados y 69.041 credenciales de cuentas de servicio de Google Cloud válidas entre 126.963 expuestas.

Análisis de Defensops

El dato importante para quien administra código es la duración de la exposición, no solo el momento de la subida. Borrar una línea del estado actual del repositorio puede dejar el secreto en el historial, en forks o en copias obtenidas por terceros. La medida que elimina el riesgo de uso de una credencial publicada es revocarla o rotarla y verificar que el sustituto no vuelve a quedar accesible.

La protección preventiva de GitHub muestra utilidad en las categorías que reconoce, según el estudio, pero su cobertura por defecto no incluye todos los tipos de secreto. Por eso una tasa menor de nuevas fugas no equivale a un inventario limpio de credenciales activas. El contraste entre tipos de tokens en la muestra también sugiere que los procesos de revocación dependen del proveedor y de la clase de credencial.

Las cifras proceden del análisis de Truffle Security recogido por BleepingComputer. La fuente no establece qué proporción de las claves encontradas fue robada o usada de forma maliciosa. Tampoco permite trasladar la frecuencia observada a todos los repositorios privados o a cualquier organización concreta.

Prioridades de revisión

Buscar credenciales propias en repositorios públicos y su historial, incluidos forks conocidos; priorizar las que siguen activas y tienen permisos sobre producción o datos sensibles.

Revocar o rotar de inmediato cada credencial confirmada como expuesta y comprobar en el servicio emisor que la anterior dejó de funcionar; después revisar el uso registrado durante la ventana de exposición.

Eliminar el secreto del código visible y del flujo de desarrollo que lo introdujo, sin tratar esa limpieza como sustituto de la revocación; comprobar que los despliegues ya emplean la nueva credencial.

Verificar qué patrones cubre Push Protection en los repositorios utilizados y añadir controles para categorías no bloqueadas por defecto, como las cadenas de conexión relevantes para la organización.

Establecer caducidad y permisos mínimos para las credenciales nuevas, y comprobar periódicamente que los secretos retirados no siguen operativos.

Qué no se ha confirmado

El estudio no determina cuántas de las credenciales expuestas fueron obtenidas o usadas por atacantes.

La cobertura resume un conjunto de datos específico y no ofrece una prevalencia comparable para repositorios privados.

La cronología del conjunto de datos y del momento de comprobación de validez no queda completamente aclarada en la cobertura.

Fuente

BleepingComputer. Fecha indicada: 2026-09-30.