Repos de GitHub exponen más de 543.000 credenciales válidas
Los repositorios públicos de GitHub siguen albergando cientos de miles de secretos operativos, pese a que la plataforma ha incorporado herramientas pensadas para evitar filtraciones accidentales. Un nuevo análisis de Truffle Security ha encontrado 543.699 credenciales únicas que seguían siendo válidas en julio.
Los investigadores analizaron 224 millones de repositorios y más de 58.000 millones de archivos. Comprobaron que una credencial filtrada típica permanecía accesible públicamente una mediana de 784 días antes de que alguien se diera cuenta o tomara medidas.
Llama la atención la antigüedad de algunos de estos secretos. Alrededor del 10 % de las credenciales operativas tenía más de 6,3 años, y la más antigua que seguía siendo válida se remonta a 2009. Los 543.699 secretos únicos aparecían una y otra vez en más de 1,1 millones de archivos y repositorios, incluidas copias en forks.
De dónde salen los datos
Truffle Security no rastreó GitHub directamente para este estudio. Trabajó con un conjunto de datos creado para entrenar grandes modelos de lenguaje, basado en un rastreo que terminó el 7 de agosto de 2025.
La cifra de GitHub duplica con creces la que el mismo equipo obtuvo en agosto tras analizar Hugging Face, donde identificó 221.303 credenciales operativas.
La investigación también apunta a un aumento constante de la frecuencia con la que aparecen secretos en el código. El número de credenciales operativas pasó de 3,72 por millón de archivos en 2015 a un máximo de 11,62 por millón de archivos en 2025.
Push Protection ayuda, pero hasta cierto punto
La principal barrera de GitHub contra este problema es Push Protection. Estuvo disponible por primera vez en abril de 2022 para los clientes de Advanced Security, se amplió a los repositorios públicos en mayo de 2023 y más tarde se activó por defecto.
La función revisa el código entrante en busca de patrones de secretos, como claves de API y tokens de acceso, y bloquea el push si encuentra una coincidencia. Sin embargo, no revoca las credenciales que ya estaban expuestas antes de que entrara en juego.
Según Truffle Security, 199.843 de las credenciales activas, alrededor del 36,8 % del total, quedaron expuestas después de que GitHub activara Push Protection para todos los usuarios en febrero de 2024.
Algo más de la mitad (51,8 %) de los secretos operativos pertenecía a categorías que la configuración por defecto de Push Protection no bloquea. Entre ellas figuran las cadenas de conexión a bases de datos y las claves de API de Google.
En las categorías que sí cubre, la función parece funcionar. La tasa de credenciales expuestas en las categorías protegidas cayó un 53 % después de que GitHub la activara por defecto.
Unos servicios limpian más rápido que otros
La probabilidad de que un secreto filtrado siga funcionando depende en gran medida del servicio al que pertenece. De 101.886 tokens de npm subidos a repositorios públicos, los investigadores solo encontraron uno que siguiera activo.
Las credenciales de cuentas de servicio de Google Cloud cuentan una historia muy distinta. De 126.963 claves expuestas, 69.041 seguían siendo válidas cuando Truffle Security hizo sus comprobaciones.
A quienes se vean afectados se les recomienda rotar de inmediato las credenciales expuestas, limpiar los repositorios, analizar todo el historial de commits y establecer una caducidad automática para todos los secretos activos.
El estudio muestra cuántos secretos operativos hay en el código público. No muestra cuántos de ellos han sido realmente encontrados y aprovechados por atacantes.
Por qué importa
Para desarrolladores y equipos de seguridad, la conclusión más útil es que bloquear nuevas filtraciones no es lo mismo que arreglar las antiguas. Push Protection parece reducir las exposiciones en las categorías que cubre, pero cientos de miles de secretos más antiguos o no cubiertos siguen activos. Esto sugiere que analizar el historial y revocar claves sigue quedando, en gran medida, en manos de los propietarios de los repositorios.
La diferencia entre los tokens de npm y las credenciales de Google Cloud también es reveladora. Indica que la detección y la revocación automática por parte del proveedor pueden marcar una gran diferencia, y que los servicios sin estos mecanismos dejan la carga en los usuarios.
Los hallazgos encajan en una tendencia más amplia de datos sensibles que acaban en código público, desde agentes de IA que filtran capturas de pantalla a GitHub hasta direcciones de correo de GitLab expuestas que se utilizan para subir código. Habrá que estar atentos a si GitHub amplía Push Protection para cubrir las cadenas de conexión a bases de datos y las claves de API de Google, y a si más proveedores de nube adoptan la revocación automática de credenciales filtradas.