Un análisis de código público en GitHub ha revelado 543,699 credenciales únicas que seguían siendo válidas durante las pruebas realizadas el 27 y 28 de julio de 2026. Según una investigación de Truffle Security, este hallazgo evidencia un fallo en la gestión de secretos, ya que las credenciales pueden permanecer activas durante años después de ser publicadas, a pesar de los controles de protección y escaneo de GitHub.

Un análisis de código público de GitHub ha descubierto 543.699 credenciales únicas que seguían siendo válidas cuando los investigadores las probaron los días 27 y 28 de julio de 2026.

Los hallazgos exponen un fallo en la gestión de secretos: las credenciales pueden seguir siendo utilizables durante años después de que los desarrolladores las publiquen, a pesar del escaneo de secretos y los controles de protección de envío (push-protection) de GitHub.

Según una investigación publicada por Truffle Security, la empresa examinó The Stack v3, una instantánea de código público ensamblada para entrenar modelos de lenguaje extensos. El corpus contiene 224.553.295 repositorios y 58.467.468.698 archivos a través de 4.096 fragmentos de metadatos, y su rastreo finalizó el 7 de agosto de 2025.

Los investigadores verificaron los secretos contrastándolos con sus servicios emisores, los eliminaron por duplicado según el valor de la credencial y rastrearon 543.699 credenciales fechadas en 1.103.438 exposiciones, incluyendo archivos y bifurcaciones (forks).

543.699 Credenciales Únicas Expuestas

La mediana de tiempo que una credencial permaneció en una rama pública predeterminada fue de 784 días. El diez por ciento tenía al menos 6,3 años, mientras que la más antigua era una credencial de base de datos en una configuración de servidor Erlang modificada por última vez en junio de 2009 que todavía autenticaba 16,1 años después.

Debido a que The Stack v3 conserva solo instantáneas de la rama predeterminada y los tiempos de modificación de los archivos, los investigadores trataron la marca de tiempo más temprana asociada a cada credencial como su fecha de filtración. Las ramas eliminadas, el historial reescrito y los secretos eliminados antes del rastreo fueron invisibles, lo que significa que es probable que la exposición sea mayor.

GitHub hizo que las alertas de escaneo de secretos fueran gratuitas para los repositorios públicos en febrero de 2023, permitiendo que los mantenedores detecten secretos compatibles en todo el historial del repositorio. En febrero de 2024, la plataforma comenzó a habilitar la protección de envío por defecto para los usuarios gratuitos. Esta función escanea los envíos en busca de credenciales reconocibles, bloquea los secretos detectados antes de la publicación y permite a los desarrolladores eliminar o ignorar la advertencia.

No obstante, 199.843 credenciales activas, el 36,8 por ciento del total, tenían fecha posterior al inicio de la protección de envío predeterminada. Otras 245.959 eran anteriores a las alertas gratuitas, mientras que 97.897 aparecieron durante el año intermedio.

Esto no significa que el control sea ineficaz. La investigación encontró que la densidad de exposición para los tipos de credenciales cubiertos por la protección de envío cayó un 53 por ciento después del despliegue, en comparación con el 7 por ciento de los tipos no protegidos.

La cobertura sigue siendo la limitación. Aproximadamente el 51,8 por ciento de las credenciales activas utilizaban formatos que la protección de envío predeterminada no bloquea, incluyendo cadenas de conexión de bases de datos, claves privadas y claves de API de Google.

Las categorías más grandes incluyeron 69.041 credenciales de cuentas de servicio de Google Cloud, 51.067 cadenas de conexión de MongoDB y 33.343 claves de API de Google. Los investigadores identificaron 31.374 claves de Gemini activas, cuyo formato comparte el prefijo AIzaSy utilizado por otros servicios de Google, lo que complica el bloqueo fiable.

Los resultados también muestran que la detección por sí sola no neutraliza la exposición. Solo uno de los 101.886 tokens de npm comprometidos permanecía activo, junto con 260 de 73.048 tokens de GitHub y 15 de 30.437 tokens de Hugging Face.

Por el contrario, 11.465 de 12.985 cadenas de conexión de PostgreSQL, 1.806 de 2.421 cadenas de MySQL y 69.041 de 126.963 credenciales de cuentas de servicio de Google Cloud todavía funcionaban. La diferencia señala a la revocación automatizada del proveedor como un control decisivo.

Debes tratar cada credencial comprometida como vulnerada, revocarla o rotarla inmediatamente e investigar los sistemas asociados en busca de un uso indebido.

La limpieza del repositorio debe seguir a la rotación, no precederla, porque borrar un secreto no invalida las copias que ya han sido recolectadas. Los equipos de seguridad también deberían escanear el historial completo de Git, habilitar patrones genéricos y personalizados, prohibir los saltos de advertencia casuales, adoptar credenciales de corta duración e integrar las alertas de secretos con la revocación automatizada. La protección de envío puede reducir las nuevas filtraciones, pero solo el vencimiento y la revocación cierran el acceso que ya ha sido expuesto.

Fuentes:
https://cybersecuritynews.com/543699-unique-credentials-exposed/