El código público de GitHub aún contenía 543.699 credenciales válidas

Truffle Security identificó 543.699 credenciales únicas en repositorios públicos de GitHub que seguían siendo aceptadas por los servicios que las habían emitido cuando se probaron a finales de julio de 2026.

El resultado pone de manifiesto la brecha entre detectar un secreto publicado y conseguir que deje de ser válido. Las claves de API, las credenciales de cuentas de servicio, los tokens y las cadenas de conexión a bases de datos pueden seguir dando acceso hasta que su propietario o el proveedor del servicio las cambie o las revoque.

El análisis se basó en un conjunto de datos recopilado para entrenar modelos de lenguaje de gran tamaño. Según la información de BleepingComputer sobre la investigación, el rastreo original abarcó 224 millones de repositorios y más de 58.000 millones de archivos antes de finalizar el 7 de agosto de 2025.

SecurityWeek informa de que el análisis detectó 1.103.438 credenciales expuestas en total. Truffle determinó después que 543.699 seguían activas. La investigación midió la exposición pública y la vigencia de las credenciales, pero no si los atacantes habían descubierto o explotado cada una de ellas.

Algunas credenciales permanecieron públicas durante años

Las credenciales únicas permanecieron accesibles públicamente durante una mediana de 784 días. Alrededor del 10 % de las credenciales válidas tenían más de 6,3 años, y una cuarta parte de las credenciales detectadas superaba los cuatro años.

Algunas eran mucho más antiguas. Truffle encontró 2.636 credenciales activas en archivos cuya última modificación databa de antes de 2015. Según SecurityWeek, la más antigua era una clave de AWS incorporada en 2009 que no se había vuelto a modificar.

Estas cifras sitúan el código histórico en el centro del problema de exposición. Truffle encontró credenciales en más de 1,1 millones de archivos y repositorios, incluidas copias en bifurcaciones. Por eso, eliminar un secreto de la versión actual de un proyecto no resuelve el problema en todos los lugares donde pudo haber aparecido.

Además, borrar el secreto no revoca la credencial correspondiente. Si el servicio que la emitió sigue aceptando el valor original, una copia obtenida de un archivo o repositorio público anterior puede continuar siendo válida.

La concentración de credenciales activas aumentó durante el periodo analizado. Truffle registró 3,72 credenciales activas por cada millón de archivos en 2015; la cifra subió hasta alcanzar un máximo de 11,62 por millón en 2025.

Los resultados de GitHub también superaron los del análisis anterior de Truffle en Hugging Face. En aquel rastreo se encontraron 221.303 credenciales válidas, menos de la mitad que en el conjunto de datos de GitHub.

La tasa de validez variaba mucho según el tipo de credencial

La probabilidad de que un secreto expuesto siguiera funcionando variaba considerablemente según la categoría y el servicio que lo hubiera emitido.

De las 126.963 credenciales expuestas de cuentas de servicio de Google Cloud, 69.041 seguían siendo válidas. SecurityWeek la describió como la categoría con más credenciales activas de las enumeradas. Entre las demás categorías mencionadas se encontraban:

• 51.067 cadenas de conexión activas de MongoDB
• 33.343 claves de API de Google activas
• Un token de npm válido de los 101.886 publicados

La cifra de npm contrasta claramente con la de las demás categorías. Casi todos los tokens de npm publicados en el conjunto de datos habían dejado de funcionar, mientras que decenas de miles de credenciales de Google Cloud, cadenas de conexión de MongoDB y claves de API de Google seguían respondiendo.

Las prácticas de revocación de los proveedores contribuyen a determinar cuánto tiempo sigue siendo peligrosa una exposición. GitHub puede detectar o notificar ciertos secretos, pero no puede invalidar por su cuenta las credenciales emitidas por otro servicio.

Los informes no detallan los permisos asociados a cada credencial válida. Por tanto, la cifra de 543.699 no puede interpretarse como el número de cuentas, sistemas o entornos en la nube comprometidos. Cada secreto solo permite acceder a los recursos y privilegios que tiene asignados, que pueden variar mucho.

Aun así, que una credencial siga siendo válida abre la puerta a accesos no autorizados. No hace falta sortear ninguna protección técnica si el servicio correspondiente sigue reconociendo una credencial que está disponible públicamente.

Push Protection solo redujo la exposición en los casos que cubre

Push Protection de GitHub analiza el código que se está subiendo para detectar patrones de secretos reconocibles, como claves de API y tokens de acceso. Si identifica un secreto compatible, puede bloquear el envío antes de que la credencial se haga pública.

BleepingComputer informa de que la función se presentó para los usuarios de Advanced Security en abril de 2022 y se habilitó para los repositorios públicos en mayo de 2023. También señala que GitHub activó Push Protection para todos los usuarios en febrero de 2024. Sin embargo, otra descripción del despliegue incluida en el mismo informe no coincide exactamente con esas fechas.

Truffle dividió las credenciales activas en tres grupos:

• 245.959 eran anteriores a las alertas gratuitas de análisis de secretos.
• 97.897 aparecieron cuando el análisis ya era gratuito, pero Push Protection aún no estaba activado de forma predeterminada.
• 199.843 se expusieron después de que el bloqueo se estableciera como opción predeterminada.

El último grupo representaba aproximadamente el 36,8 % del total de credenciales activas. Por tanto, casi 200.000 credenciales publicadas durante el periodo en que el bloqueo ya era la opción predeterminada seguían siendo aceptadas cuando Truffle las probó.

Esto no significa que el control no fuera eficaz. En las categorías de credenciales cubiertas por Push Protection, la tasa de exposición cayó un 53 % después de que la función se activara de forma predeterminada. La reducción se limita a las categorías protegidas, no al conjunto de credenciales expuestas.

La cobertura es una limitación importante. BleepingComputer informa de que el 51,8 % de las credenciales activas pertenecía a categorías que GitHub no bloquea de forma predeterminada con Push Protection, como las cadenas de conexión a bases de datos y las claves de API de Google.

Push Protection también actúa frente a nuevos intentos de publicar secretos compatibles. No revoca las credenciales expuestas antes de que el control pudiera intervenir.

Las alertas sobre secretos siguen requiriendo la intervención de propietarios y proveedores

GitHub cuenta con un programa de análisis de secretos que envía tokens expuestos a los servicios que los emitieron. Sin embargo, GitHub no obliga a esos proveedores a revocar las credenciales notificadas.

Truffle atribuyó parte de la exposición persistente a proveedores que podrían no tener un proceso para invalidar los tokens filtrados. Como explica la cobertura de SecurityWeek sobre los resultados, las alertas históricas también dependen de que los propietarios de los repositorios las activen, revisen los resultados y cambien las credenciales afectadas.

La corrección puede interrumpirse en varios puntos:

1. GitHub u otro analizador debe reconocer la credencial.
2. La alerta debe llegar al propietario del repositorio o al proveedor que emitió la credencial.
3. Alguien debe evaluar el hallazgo.
4. La credencial expuesta debe revocarse o cambiarse.

La detección por sí sola no hace que la credencial deje de funcionar. Eliminar la cadena del código visible sin invalidarla tiene la misma limitación.

También es importante interpretar los resultados con cautela. Truffle verificó que las credenciales estaban expuestas y seguían funcionando, pero la investigación no determinó qué proporción había sido robada o utilizada por atacantes.

Cambiar las credenciales y analizar el historial son prioridades inmediatas

Las recomendaciones de Truffle empiezan por cambiar de inmediato las credenciales expuestas. Las organizaciones deberían tratar una divulgación pública como un incidente relacionado con el ciclo de vida de las credenciales, no solo como una tarea de limpieza del código.

Los equipos afectados deberían:

1. Cambiar de inmediato las credenciales expuestas. El valor publicado debe dejar de funcionar en el servicio que lo emitió.
2. Eliminar los secretos de los repositorios. Esto reduce su visibilidad, pero no sustituye a la revocación.
3. Analizar el historial de los repositorios. Revisar solo la versión actual puede dejar fuera credenciales incluidas en archivos o confirmaciones anteriores.
4. Configurar la caducidad automática. Las credenciales con una vigencia limitada reducen el tiempo durante el que puede utilizarse una exposición inadvertida.
5. Usar Push Protection y las alertas de análisis de secretos. Estos controles pueden bloquear o detectar tipos de secretos compatibles, pero deben integrarse en un proceso eficaz de cambio de credenciales.

Al revisar los repositorios, los equipos deberían tener en cuenta las bifurcaciones y las copias repetidas detectadas durante la investigación. También deberían consultar los registros del proveedor correspondiente para buscar actividad relacionada con las credenciales expuestas, ya que el análisis general no permite determinar si se hizo un uso indebido de los secretos de una organización concreta.

Los dos informes publicados no enumeran los valores de las credenciales ni las URL de los repositorios afectados. Por eso, las organizaciones deben revisar su propio código público, el historial de sus repositorios y sus inventarios de credenciales, en lugar de esperar a que se publique una lista universal de secretos expuestos.

El problema de fondo no es solo que los desarrolladores incluyeran valores confidenciales en el código. Es que cientos de miles de esos valores siguieron siendo válidos, en algunos casos durante años después de quedar accesibles públicamente.