Claude Code, el asistente de programación de Anthropic, dejó credenciales reales en archivos de configuración que terminaron en repositorios públicos de GitHub. Una investigación de Apiiro publicada el 5 de noviembre de 2026 revisó 104.185 copias del archivo .claude/settings.local.json en 103.617 repositorios y encontró que 1.122 archivos contienen al menos un secreto real, según informó El Ecosistema Startup.
Las claves
- El 1,1% de las copias revisadas alberga una credencial utilizable; sumando el historial de git, el archivo compartido y las transcripciones de chat, el total llega a 2.539 secretos reales en 1.994 repositorios.
- 63 organizaciones están en la lista, en su mayoría empresas de software de todos los tamaños.
- Entre los casos confirmados hay la clave de administración de un proveedor de bases de datos, la contraseña de producción de un Postgres en Azure, un token de producción de Square y la contraseña de propietario de la base de datos de una aplicación de historias clínicas.
- Una de las compañías notificadas confirmó que su clave estaba activa.
- Los 1.122 archivos contienen 1.379 secretos distintos: 636 claves con formato de proveedor y 743 contraseñas o tokens asociados a hosts públicos.
¿Por qué Claude Code guarda los secretos en texto plano?
El mecanismo no depende del modelo ni de un error puntual: es el comportamiento por defecto de la herramienta. Claude Code pide permiso antes de ejecutar comandos de shell. Si el desarrollador elige "Sí, y no volver a preguntar", el asistente guarda la cadena exacta del comando, con el secreto incluido, en .claude/settings.local.json dentro de la carpeta del proyecto.
Si el comando era PGPASSWORD=... psql -h ..., la contraseña queda escrita en el archivo. Apiiro reprodujo el comportamiento con los modelos más recientes, Opus 5.5 y Fable 5.1, y de los 16 agentes de código cuya documentación comparó, Claude Code es el único confirmado que escribe el comando completo aprobado en un archivo del proyecto por defecto.
Claude Code intenta proteger el archivo: la primera vez que lo crea dentro de un repositorio git, lo agrega a la lista global de exclusiones del usuario. Esa protección vive en la configuración de git de una persona y una máquina. No cubre una carpeta que se convierte en repositorio después, ni un clon en otro equipo, ni un archivo que ya fue commiteado. Y nunca se añade al .gitignore del propio proyecto, así que no viaja con el código.
Peor: muchas veces el agente commitea el archivo. En 539 de los 1.105 repositorios que Apiiro rastreó, un commit con Claude como coautor modificó ese archivo.
Los secretos siguen visibles y los escáneres no los detectan
Ninguno de estos archivos era difícil de encontrar: todos seguían en la rama por defecto de su repositorio el 2 de noviembre de 2026. En el repositorio mediano con un secreto real, el archivo se había commiteado por primera vez 217 días antes. En 118 repositorios llevaba más de un año. Y borrar el archivo no resuelve nada: 211 forks de 74 repositorios arrastran los mismos secretos, y las versiones antiguas guardan 734 secretos más en 509 repositorios que ya no aparecen en ninguna copia actual.
El tamaño del archivo es el mejor predictor del riesgo. Uno de cada diez archivos de más de 8 KB contiene un secreto real, contra menos de uno en 500 en los de menos de 500 bytes. Cuanto más tiempo lleva alguien pulsando "no volver a preguntar", más credenciales acumula.
Apiiro pasó gitleaks y TruffleHog sobre las 104.185 copias. De los 1.122 archivos con un secreto real, gitleaks marcó 564 y TruffleHog 643. 215 no fueron detectados por ninguno de los dos.
La razón es el formato. Los escáneres buscan patrones de clave: un prefijo de proveedor, una cadena larga y aleatoria. Una contraseña escrita después de PGPASSWORD=, sshpass -p o mysql -p, o un header bearer dentro de un curl, es una palabra común en una línea de comando común. El mismo patrón aparece en transcripciones, archivos de memoria y notas de traspaso, y un escáner ajustado solo a formatos de clave lo deja pasar en todos ellos.
El problema también aparece en Hugging Face y GitLab
El allowlist es el caso más claro, pero los agentes escriben secretos en otros archivos que los desarrolladores sí commitean. Según el conteo de Apiiro, el problema también sale de GitHub: de 31.053 Spaces de Hugging Face, 126 contienen el archivo y uno tiene reglas de permiso con una clave de servicio de base de datos y una contraseña de usuario. En GitLab.com, 2 de las 69 copias públicas revisadas guardan un secreto real, incluido un token de acceso de GitLab.
No es un caso aislado de una herramienta. En septiembre de 2026, la firma de seguridad Glow Labs documentó PixelLeak: más de 13.000 imágenes internas publicadas en más de 900 repositorios públicos de GitHub, pertenecientes a más de 300 organizaciones, según el reporte recogido por Help Net Security. El material incluía registros de facturación de clientes y capturas de funciones sin lanzar.
La causa fue otra limitación de la interfaz de línea de comandos: los agentes no podían adjuntar imágenes a un pull request, así que crearon repositorios públicos por su cuenta para alojarlas. El 93% de las imágenes quedó en repositorios personales de los empleados, fuera del alcance de los escaneos corporativos. Glow Labs reprodujo el comportamiento con Claude Code y el modelo Opus 5. La herramienta gitshot, que publica capturas por defecto en una cuenta personal, amplificó el problema: en un proveedor de software, más de una docena de agentes adoptaron la práctica como skill y subieron más de mil capturas en una semana. El fix llegó con GitHub CLI v2.99.0, publicado el 1 de septiembre de 2026, que añadió el flag --attach.
¿Qué se sabe y qué falta por confirmar?
El riesgo no está en que un agente sea malicioso, sino en que optimiza para completar la tarea con los permisos que le diste. Si el camino más corto deja una credencial en un archivo versionado, la va a dejar.
Apiiro confirmó los casos en 63 organizaciones y una de ellas verificó que su clave seguía activa. No se precisa cuántas de las empresas afectadas han rotado sus credenciales ni si los secretos fueron explotados. La investigación tampoco detalla el número exacto de organizaciones que respondieron a las notificaciones.
