Claude Code expone 2.539 secretos en GitHub: cómo evitarlo

2.539 secretos reales quedaron visibles en repositorios públicos de GitHub

Una contraseña de base de datos de producción, una clave de administrador de un proveedor de nube y el usuario root de un servidor SSH estuvieron al alcance de cualquiera que abriera el repositorio correcto. No los filtró un ataque: los guardó Claude Code en un archivo de configuración que terminó publicado, según la investigación de Apiiro que reportó Ars Technica.

Para un founder, la lección es incómoda y directa: el agente de IA que tu equipo usa para programar más rápido puede estar escribiendo credenciales en texto plano dentro de la carpeta del proyecto. Si ese proyecto se hace público, la filtración ocurrió sin que nadie hiciera nada malo a propósito.

¿Qué es el archivo .claude/settings.local.json y por qué guarda secretos?

Claude Code pide permiso antes de ejecutar comandos de terminal. Cuando el desarrollador elige la opción «Yes, and don’t ask again» (sí, y no vuelvas a preguntar), esa aprobación se guarda como una regla en el archivo local .claude/settings.local.json.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El problema es cómo se guarda. A veces la regla se codifica como un patrón genérico, algo como npm test *. Pero muchas veces el comando completo se escribe tal cual, incluyendo la credencial que el desarrollador tecleó dentro de él: PGPASSWORD=..., sshpass -p ..., mysql -p ... o un header de autorización en una llamada con curl.

Y eso no es un caso aislado. Apiiro reprodujo el comportamiento con los modelos más recientes que probó, Opus 5.5 y Fable 5.1, según The Hacker News. De los 16 agentes de programación cuya documentación compararon, Claude Code fue el único confirmado en guardar el comando completo aprobado en un archivo del proyecto por defecto, de acuerdo con ese mismo medio.

¿Por qué el archivo termina en GitHub si está en la lista de exclusión?

Anthropic documenta que ese archivo se agrega a la lista global de .gitignore del desarrollador, lo que en teoría evita que se publique. La protección, sin embargo, vive en la configuración de Git de una sola computadora.

No cubre los tres escenarios que más ocurren en la práctica, según el informe de Apiiro citado por Cybernews: una carpeta que se convierte en repositorio más tarde, un clon del repo en otra máquina, o un archivo que alguien ya había incluido en un commit anterior. La regla nunca llega al .gitignore del propio repositorio, así que no viaja con el proyecto.

A esto se suma un detalle que complica la culpa: en 539 de los 1.105 repositorios con secretos reales, el commit que modificó el archivo tenía a Claude como coautor. Los investigadores lo interpretan como que el agente suele hacer el commit él mismo, sin intervención del usuario.

Los números del hallazgo

Apiiro escaneó GitHub y encontró 104.185 copias públicas de .claude/settings.local.json distribuidas en 103.617 repositorios, de acuerdo con The Hacker News.

1.122 copias contenían al menos un secreto, cerca del 1,1% del total.
Esas copias reunían 1.379 secretos distintos, cifra que sube a 2.539 secretos en 1.994 repositorios al sumar historial de Git, versiones antiguas y otros archivos del agente.
379 contraseñas de bases de datos, 43 logins SSH a servidores públicos, 42 tokens de GitHub, GitLab y npm, y 23 claves de AWS.
63 organizaciones afectadas, entre startups, agencias de software y proveedores establecidos.
211 forks de 74 repositorios arrastraban los mismos secretos que el original.

El caso más delicado que reportan: la clave de nube con permisos de administrador de un proveedor de base 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 una base de datos de historiales médicos, según detalló Cryptobriefing a partir del informe.

Al cierre del análisis, todos los archivos con secretos seguían en la rama principal de su repositorio, y en la mitad de esos repositorios llevaban ahí al menos 217 días, según The Hacker News. Los investigadores no verificaron si alguien ya usó esas credenciales, aunque una empresa notificada confirmó que su clave seguía activa.

¿Por qué gitleaks y TruffleHog no lo detectaron?

Muchos equipos confían en escáneres automáticos de secretos justamente para esto. Los investigadores corrieron gitleaks y TruffleHog sobre las copias afectadas: el primero marcó 564, el segundo 643, y 215 no fueron detectadas por ninguno de los dos, según The Hacker News.

La razón es de formato. Los escáneres buscan patrones de clave conocidos: un prefijo de proveedor, una cadena larga y aleatoria. Una contraseña escrita después de PGPASSWORD= o mysql -p es una palabra común en una línea de comando común, y los dos escáneres la dejaban pasar.

Qué dice Anthropic

Boris Cherny, responsable de Claude Code en Anthropic, respondió a los hallazgos y dijo que el equipo está «viendo qué podemos hacer para prevenirlo», según Cybernews. Su lectura es que el archivo no debería estar en control de versiones y que Anthropic lo excluye automáticamente cuando Claude lo crea, de modo que los casos encontrados corresponderían a archivos creados manualmente y subidos al repo.

Cherny también recomendó usar el modo automático en lugar de mantener listas de permitir y denegar, y tener el escaneo de secretos activado en GitHub «sin importar qué agente uses».

Hay un antecedente que conviene conocer: un reporte de bug sobre este mismo comportamiento, con claves y tokens guardados palabra por palabra, se había archivado el 11 de agosto de 2025. Un bot automatizado lo cerró como «no planificado» el 3 de enero, tras 60 días sin actividad, según The Hacker News. Los cuatro reportes relacionados que citan los investigadores corrieron la misma suerte, sin respuesta de Anthropic.

Qué significa esto para tu startup

El riesgo no es hipotético ni exclusivo de equipos grandes: la mayoría de los repositorios afectados pertenecen a desarrolladores individuales. Y el vector no es solo GitHub. El archivo es JSON plano dentro de la carpeta del proyecto, así que también puede salir publicado dentro de un paquete de npm, metido en una imagen de Docker, dentro de un zip o en una carpeta sincronizada en la nube. El informe de Apiiro lo dice sin vueltas, citado por Cybernews: la lista de permisos es JSON plano en la carpeta del proyecto, y el malware ya recolecta credenciales de las máquinas de desarrolladores de forma masiva.

Hay además un detalle que suele pasarse por alto: borrar el archivo no deshace la filtración. Las versiones anteriores quedan en el historial de Git y en los forks que ya lo copiaron.

Cómo revisar tu organización esta semana

Estas son las acciones concretas que recomienda Apiiro y que puedes empezar hoy:

Busca el archivo en toda tu organización. Revisa .claude/settings.local.json y .claude/settings.json en cada repositorio y, sobre todo, en el historial de Git, incluso donde el archivo ya no existe.
Rota primero, limpia después. Cambia cada contraseña, token y clave que esos archivos hayan contenido alguna vez. La limpieza sin rotación no sirve, porque el historial conserva el valor.
Saca el archivo del control de versiones con git rm --cached .claude/settings.local.json y agrégalo al .gitignore del repositorio, no solo al global de tu máquina. Añádelo también a las plantillas de .gitignore de la organización.
Abre el archivo en tu computadora aunque nunca se haya subido y elimina toda regla que contenga un secreto en texto plano. El riesgo existe también en local.
Deja de escribir credenciales dentro de comandos. Usa variables que apunten a un gestor de secretos, como $DB_URL, para que la regla guardada contenga el nombre de la variable y no el valor.
Aprueba patrones en lugar de comandos sueltos. Aprobar Bash(npm run:*) es más seguro que autorizar un comando único que lleva una contraseña embebida.
Trata las carpetas del agente como un .env. .claude/, .cursor/, .gemini/ y .specstory/, además de los archivos de memoria del agente, deben entrar en el escaneo de secretos de pre-commit y de CI, incluyendo el historial. Y verifica que el escáner detecte contraseñas dentro de comandos, no solo formatos de clave conocidos.

Conclusión: la comodidad del agente tiene un costo de seguridad

Claude Code no introdujo una vulnerabilidad exótica. Automatizó una decisión humana que casi nadie revisa: aceptar un comando para no volver a ver el mismo diálogo. El resultado es que credenciales sensibles quedaron escritas en un archivo que la mayoría de los equipos ni sabía que existía, y que los escáneres que ya tenían instalados no supieron leer.

Para un founder, la prioridad es simple y no admite espera: revisa el historial de tus repositorios, rota lo que aparezca y pon el .gitignore a nivel de proyecto, no de laptop. La próxima vez que alguien apruebe un comando con «no volver a preguntar», esa decisión debería estar protegida por un proceso, no por la memoria de una máquina.