La noticia afecta a cualquier desarrollador o empresa que use Claude Code en sus proyectos, y tiene una solución clara. La iré actualizando si hay datos nuevos.

◢Qué ha pasado

A veces la regla es un patrón, como npm test *. Otras veces es el comando exacto que aprobaste. Si le pides que mire por qué falla el login en staging o que lance una migración, el comando que propone lleva la contraseña de la base de datos, porque sin ella no funciona. Al aprobarlo para siempre, esa contraseña queda guardada en texto plano. Según Apiiro¹, es un comportamiento de la herramienta y no del modelo: lo reprodujeron con Opus 5.5 y Fable 5.1, los más recientes de Anthropic.

◢¿Por qué acaba en GitHub si es un archivo local?

El problema es que esa protección vive en la configuración de git de una persona en un ordenador. No se añade al .gitignore del propio proyecto, así que no viaja con él, y no cubre una carpeta que se convierte en repositorio más tarde, un clon en otra máquina ni un archivo que ya estaba subido. Recuerda además que .gitignore no afecta a archivos que git ya sigue: "local" es solo el nombre. Apiiro¹ vio que en 539 de los 1.105 repositorios que rastreó, un commit con Claude como coautor había modificado el archivo. Eso no prueba que el asistente metiera cada credencial, pero sí que a menudo es él quien hace el commit.

◢Qué se sabe

Estas son las cifras del informe de Apiiro¹, con datos recogidos del 1 al 3 de noviembre:

• ▹Apiiro¹ encontró 104.185 copias públicas del archivo en 103.617 repositorios. Un 1,1 %, 1.122 copias, tiene al menos un secreto real, con 1.379 secretos distintos en total.
• ▹Más de un tercio da acceso directo a una base de datos: 379 contraseñas de bases de datos y 122 claves de servicio de Supabase. También hay 43 accesos SSH a servidores públicos, 42 tokens de GitHub, GitLab y npm, y 23 claves de AWS.
• ▹Hay 63 organizaciones afectadas, sobre todo empresas de software. Entre los casos, la clave de administración en la nube de un fabricante de bases de datos, una contraseña de Postgres en Azure de producción y la del dueño de una base de datos de historiales médicos.
• ▹Las versiones antiguas del archivo, que siguen en el historial de git aunque se haya borrado, guardan 734 secretos más en 509 repositorios. Sumando el archivo compartido .claude/settings.json y los registros de conversaciones con agentes que se suben a los repositorios, el total llega a 2.539 secretos en 1.994 repositorios.
• ▹Los escáneres de secretos habituales no ven muchos casos. Gitleaks marcó 564 de los 1.122 archivos y TruffleHog 643, y 215 no los marcó ninguno de los dos. Casi siempre es una contraseña escrita dentro de un comando, detrás de PGPASSWORD= o sshpass -p, que parece una palabra normal.

◢Qué no se sabe

Es un riesgo de exposición, no una brecha demostrada. Apiiro¹ no probó ninguna credencial ni contactó con ningún servidor, así que "secreto real" significa que tiene el formato de una clave conocida o apunta a un servidor público, no que funcione. Avisó a las organizaciones el 2 y el 3 de noviembre y solo una ha confirmado que su clave estaba activa. Tampoco se sabe si alguien ha usado ya alguno de esos secretos.

Anthropic no ha respondido en público por ahora. Según Apiiro, los usuarios avisan de este comportamiento en el repositorio de Claude Code desde agosto de 2025, en varias incidencias que no recibieron respuesta y de las que tres se cerraron solas por inactividad o por duplicadas. Conviene saber también que Apiiro vende productos de seguridad para aplicaciones y agentes de IA.

◢Qué hacer si usas Claude Code

El orden importa. Primero se cambian las claves y después se limpia, porque borrar el archivo no borra el historial de git ni las copias en forks.

1. ▹Busca .claude/settings.local.json y .claude/settings.json en los repositorios de tu cuenta o de tu organización, también en el historial de git aunque el archivo ya no esté.
2. ▹Cambia cada contraseña, token y clave que haya aparecido en esos archivos, aunque creas que nadie lo ha visto.
3. ▹Deja de seguir el archivo local con git rm --cached .claude/settings.local.json y añádelo al .gitignore del proyecto, para que la protección viaje con el repositorio.
4. ▹Abre el archivo en tu propio ordenador, aunque nunca lo hayas subido, y borra las reglas que contengan un secreto. Puede acabar en un paquete npm, una imagen Docker, un zip o una carpeta sincronizada, y el malware que roba credenciales de equipos de desarrollo ya busca este tipo de archivos.
5. ▹No escribas secretos dentro de los comandos. Usa variables, como $DB_URL, que lean de un gestor de secretos, así la regla guarda el nombre de la variable y no el valor. Ojo: escribir DB_PASS=algo comando en la misma línea sigue metiendo la contraseña en el comando.
6. ▹Cuando apruebes de forma permanente, mejor un patrón de comandos que un comando exacto.

Si llevas la seguridad de un equipo, trata las carpetas de los agentes de programación (.claude/, .cursor/, .gemini/) como tratas un archivo .env, añade .claude/settings.local.json a las plantillas de .gitignore de la organización y comprueba que tu escáner de secretos también busca contraseñas dentro de comandos y revisa el historial.

◢Lo que deja esta noticia

Los asistentes de programación trabajan con los mismos permisos y los mismos secretos que tú, y guardan cosas en sitios que no siempre miramos. Un botón de comodidad como "no volver a preguntar" acaba creando un archivo con credenciales que nadie revisa.

Ya escribí sobre claves de API de IA robadas y sobre agentes de IA con demasiados permisos: este caso junta los dos problemas. Si tu equipo empieza a usar estas herramientas y quieres que lo haga con criterio, es parte de lo que trabajo en mis formaciones de ciberseguridad e IA.