Contraseñas guardadas por Claude Code quedan expuestas en GitHub

Un estudio de la firma de seguridad Apiiro ha encontrado 1.379 contraseñas, claves de API y tokens privados al alcance de cualquiera en repositorios públicos de GitHub, guardados uno a uno por el propio Claude Code cada vez que un desarrollador aprobaba un comando marcando la opción «Yes, and don’t ask again» (sí, y no vuelvas a preguntar). La cifra se dispara hasta 2.539 secretos en 1.994 repositorios si se suman las versiones antiguas conservadas en el historial de git, los archivos de configuración compartidos que los equipos versionan a propósito y las transcripciones guardadas de conversaciones con el agente. No proceden de una brecha ni de un ataque a Anthropic. Entre lo expuesto hay 379 contraseñas de bases de datos, 43 accesos SSH a servidores públicos, 42 tokens de GitHub, GitLab y npm, y 23 claves de AWS.

El mecanismo es de una simplicidad incómoda. Cuando Claude Code pide permiso para ejecutar un comando y el usuario elige que no vuelva a preguntar, la herramienta guarda ese comando exacto, con la contraseña o el token que llevara tecleado dentro, como una regla en el archivo .claude/settings.local.json del proyecto. Es su comportamiento por defecto: los investigadores lo han reproducido con los modelos más recientes, Opus 5.5 y Fable 5.1. Ese archivo debería quedarse en el ordenador del desarrollador, y de hecho Claude Code lo apunta en la lista global de exclusiones de git de la máquina. Pero esa protección no viaja con el proyecto: nunca se añade al .gitignore del repositorio, de modo que basta clonar el repo en otro equipo, convertir en repo una carpeta que no lo era o haber versionado el archivo una sola vez para que empiece a subirse a GitHub.

Ni siquiera hace falta que el desarrollador lo suba. En 539 de los 1.105 repositorios con secretos que los investigadores pudieron rastrear, el commit que modificó ese archivo lleva a Claude como coautor: la propia herramienta lo estaba versionando. Las instrucciones internas de Claude Code para hacer commits le prohíben subir archivos .env o credentials.json, pero no mencionan su propio archivo de configuración.

El censo de Apiiro localiza 104.185 copias públicas de ese archivo, de las que 1.122 contienen al menos un secreto real. Entre los afectados hay 63 organizaciones, desde grupos de estudiantes hasta empresas de software consolidadas: el caso más llamativo es la clave de administrador en la nube del propio fabricante de una base de datos, seguido de la contraseña de propietario de una base de datos de historiales médicos. Al menos una organización confirmó que su clave seguía activa cuando fue avisada.

Borrar el archivo no resuelve nada. Los secretos llevaban una mediana de 217 días publicados a fecha del 2 de noviembre, 211 forks de 74 repositorios los siguen copiando y 734 contraseñas más sobreviven solo en el historial de repos donde el archivo ya fue eliminado. Los escáneres habituales tampoco sirven de red: gitleaks y TruffleHog, dos de las herramientas más usadas para detectar secretos, pasaron por alto 215 de los 1.122 archivos, porque una contraseña tecleada dentro de un comando no tiene el formato de clave que esas herramientas buscan. No es la primera filtración de credenciales a gran escala, pero sí de las más evitables.

Reportes sin respuesta desde agosto de 2025

Lo más delicado del caso es que no es nuevo. El primer informe de error sobre este comportamiento se registró el 11 de agosto de 2025, y los cuatro reportes relacionados fueron cerrados automáticamente por un bot por inactividad, sin respuesta de Anthropic. Tras la publicación de la investigación, Boris Cherny, responsable de Claude Code, ha respondido en Hacker News que el equipo estudia cómo evitarlo, con prototipos que incluyen detección en el modo automático y un escáner de secretos integrado. Cherny matiza que esos archivos «no deberían versionarse casi nunca» y que los casos que ha revisado parecían creados a mano, un argumento en tensión con los 539 commits cofirmados por la propia herramienta que documenta Apiiro.

Mientras llega la corrección, la recomendación de los investigadores tiene un orden claro: primero rotar y después limpiar, es decir, cambiar cada contraseña, token y clave que haya pasado por esos archivos antes de borrar nada, porque el historial de git y los forks no perdonan. Cualquier equipo que use Claude Code debería buscar hoy mismo ese archivo en sus repositorios. El episodio se suma a una lista que crece: ya vimos cómo el uso de IA generativa sin control puede exponer datos de clientes y cómo los falsos agentes y skills sortean los controles de seguridad. La conclusión es incómoda para toda la industria: cuanta más confianza genera una herramienta de IA, más permisos acumula, y un «no vuelvas a preguntar» dicho a la ligera puede acabar publicando la llave de la base de datos de producción.

Más información | la investigación completa de Apiiro