Apiiro detectó decenas de miles de copias públicas de un archivo de configuración de Claude Code en GitHub, y más de un millar de ellas contienen secretos explotables. La causa es una función pensada para acelerar el trabajo diario con el agente, que memoriza el comando aprobado sin distinguir una credencial de acceso de un argumento inofensivo.
Un archivo de confianza que también memoriza secretos
Cuando un desarrollador responde «Yes, and don’t ask again» a una petición de ejecución, Claude Code guarda la regla en .claude/settings.local.json, en la raíz del proyecto. Si la regla corresponde a un comando exacto en lugar de un patrón genérico, cualquier argumento introducido en ese comando, una contraseña o un token de API incluidos, queda escrito en texto plano. La herramienta añade el archivo a las exclusiones globales de Git de la máquina que lo creó, pero no al .gitignore del repositorio, así que la protección no viaja con el código. El paralelismo con la gestión correcta de variables de entorno y secretos resulta inevitable: una credencial que pasa por un comando de shell en lugar de un gestor dedicado queda expuesta al primer descuido.
La magnitud del problema según Apiiro
La firma de seguridad detectó más de 104.000 copias de este archivo en más de 103.000 repositorios públicos. De ellas, 1.122 contienen al menos un secreto explotable, con un total de 1.379 secretos distintos. Sumando el historial de Git, los forks duplicados y un segundo archivo de configuración, .claude/settings.json, el total sube a 2.539 secretos repartidos en 1.994 repositorios y 63 organizaciones.
| Categoría de secreto | Volumen detectado | Riesgo principal |
|---|---|---|
| Contraseñas de bases de datos | 379 | Acceso directo a datos de producción |
| Tokens (GitHub, GitLab, npm) | 42 | Publicar o modificar código en nombre de una cuenta |
| Accesos SSH a servidores públicos | 43 | Toma de control de una máquina expuesta |
| Claves de AWS | 23 | Acceso a la infraestructura en la nube de la cuenta afectada |
Entre los casos citados figuran una clave de nube con permisos de administrador de un proveedor de bases de datos y la contraseña propietaria de una base de datos de historiales médicos. Los investigadores no comprobaron de forma sistemática si cada secreto seguía activo, pero una empresa notificada confirmó que una de sus claves todavía funcionaba.
Por qué los escáneres habituales no lo detectan
De los 1.122 archivos con algún secreto, gitleaks detectó 564 y TruffleHog 643; 215 se escaparon de ambos, porque un secreto escondido en medio de una línea de comandos no siempre tiene el aspecto de una clave de API estándar. Apiiro recomienda tratar las carpetas de agentes, .claude/ igual que .cursor/, como zonas de riesgo al mismo nivel que un archivo .env, y reforzar en consecuencia los escáneres de pre-commit y CI integrados en el conjunto de herramientas de línea de comandos ya presente en el puesto de desarrollo.
En 1.105 repositorios analizados donde un commit acredita a Claude como coautor, 539 muestran una modificación automática de este archivo de configuración por parte del propio agente.
Cómo corregir la configuración ahora mismo
El orden de las operaciones importa: hay que revocar las credenciales expuestas antes de limpiar el repositorio, no después, porque un historial de Git purgado no elimina nada de lo que los rastreadores ya hayan podido indexar.
# 1. Dejar de rastrear el archivo sin borrarlo del disco
git rm --cached .claude/settings.local.json
# 2. Añadirlo al .gitignore del proyecto, no solo a la exclusión global
echo ".claude/settings.local.json" >> .gitignore
# 3. Comprobar que ninguna regla aprobada contiene un comando completo con un secreto
grep -n "Bearer\|password\|API_KEY" .claude/settings.local.json
git rm --cached no limpia el historial: cualquier secreto ya confirmado sigue siendo legible en commits antiguos y en los forks existentes. La rotación inmediata del secreto sigue siendo la única protección fiable.Lo que hay que recordar
- La opción «don’t ask again» de Claude Code puede escribir un secreto en texto plano en un archivo de proyecto que no está protegido por defecto a nivel de repositorio.
- Se detectaron más de 1.300 secretos explotables en repositorios públicos, incluidos accesos a bases de datos, SSH y nube.
- Los escáneres de secretos habituales fallan en casi uno de cada cinco casos cuando la credencial está oculta dentro de un comando.
- La corrección empieza por rotar las credenciales antes de limpiar el repositorio, y después añadir el archivo al
.gitignoredel proyecto.
En los proyectos que se siguen día a día, este archivo de configuración del agente recibe el mismo trato que un archivo de entorno: nunca entra en un commit, y punto. La costumbre de responder «don’t ask again» para ganar unos segundos tiene un coste que solo se nota cuando un repositorio pasa a ser público. Un gestor de secretos combinado con reglas de aprobación basadas en patrones, en lugar de comandos exactos, resuelve el problema de raíz, sin renunciar a la comodidad que estos agentes aportan por lo demás, sobre este punto, véase la experiencia de campo con agentes editoriales en producción. — Simon Janvier
Para profundizar: el informe completo de Apiiro, vía The Hacker News.
