Tronlar
Gamma
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Una investigación publicada el 5 de noviembre por la empresa de seguridad Apiiro ha destapado un problema bastante preocupante en Claude Code, la herramienta de programación con inteligencia artificial de Anthropic.
Resulta que una opción tan habitual como «Sí, y no vuelvas a preguntar» puede terminar guardando contraseñas, tokens y claves API en un archivo de configuración del proyecto. Y si ese archivo acaba en un repositorio público de GitHub, cualquiera podría consultar su contenido.
Lo más llamativo es que los investigadores han encontrado 2.539 secretos en 1.994 repositorios públicos.
No hablamos únicamente de claves para probar aplicaciones. Entre los casos detectados hay credenciales de bases de datos, accesos SSH, tokens de servicios y claves de infraestructuras en la nube.
🔴 ¿Cómo ocurre exactamente?
Cuando trabajamos con Claude Code, la herramienta suele pedir permiso antes de ejecutar determinados comandos en la terminal.
Por ejemplo, podemos pedirle que compruebe una conexión a una base de datos o que haga una petición a una API.
Si el comando incluye una contraseña o un token y seleccionamos «Sí, y no vuelvas a preguntar», Claude Code puede guardar una regla para recordar esa autorización en futuras sesiones.
El problema aparece cuando esa regla contiene el comando completo, incluyendo la contraseña o clave que se haya utilizado.
La información puede terminar almacenada en este archivo:
Es decir, algo que debería servir para recordar permisos puede acabar funcionando como un pequeño almacén de credenciales en texto plano.
Importante: esto no significa que Claude Code publique automáticamente las contraseñas en GitHub.
La exposición se produce cuando esos archivos terminan subidos a repositorios públicos, por ejemplo, al incluirlos accidentalmente en un commit.
📊 ¿Qué encontraron los investigadores?
Apiiro analizó archivos públicos de configuración de Claude Code alojados en GitHub y encontró los siguientes resultados:
Entre las credenciales encontradas había 379 contraseñas de bases de datos, 43 accesos SSH, 42 tokens relacionados con GitHub, GitLab o npm y 23 claves de AWS.
Los investigadores también identificaron casos especialmente delicados, como credenciales con privilegios elevados sobre servicios en la nube y contraseñas relacionadas con una base de datos de historiales médicos.
Eso sí: encontrar una clave publicada no demuestra que siga funcionando ni que alguien la haya utilizado. Apiiro indica que no comprobó la validez de todas las credenciales, aunque una de las organizaciones notificadas confirmó que su clave había estado activa.
🧐 ¿Pero Claude Code no debería evitar que ese archivo se suba a GitHub?
Aquí está uno de los detalles más interesantes.
Según la documentación de Anthropic, Claude Code intenta mantener el archivo local fuera de Git mediante una configuración de exclusiones del usuario.
El inconveniente es que esa protección depende del entorno local y no equivale a incluir el archivo en el .gitignore del propio proyecto.
Por tanto, pueden producirse situaciones en las que el archivo termine versionado, especialmente si ya estaba incluido anteriormente o se trabaja desde otro entorno.
Y hay otro problema: borrar el archivo del repositorio no elimina necesariamente las contraseñas filtradas.
Si estuvo publicado, sus versiones anteriores pueden continuar en el historial de Git, en clones o en bifurcaciones del proyecto.
Por eso los investigadores recomiendan cambiar primero las credenciales comprometidas y después limpiar el repositorio.
🕒 Lo curioso es que el problema ya se había comunicado en 2025
La investigación también señala que este comportamiento no es completamente nuevo.
El 11 de agosto de 2025, un usuario abrió una incidencia en el repositorio oficial de Claude Code explicando que los comandos autorizados podían almacenarse con contraseñas y tokens sin ocultar.
El informe describía precisamente el archivo settings.local.json y el riesgo de que las credenciales acabaran compartidas accidentalmente.
La incidencia terminó cerrada como «not planned» mediante un proceso automatizado.
Esto no demuestra que Anthropic ignorase deliberadamente el problema, pero sí que existía un aviso público mucho antes de que se publicara esta investigación.
🛠️ ¿Qué deberían revisar quienes utilizan Claude Code?
Si utilizáis Claude Code para desarrollar aplicaciones, administrar servidores o trabajar con APIs, merece la pena comprobar algunas cosas:
Si el archivo ya está siendo seguido por Git, se puede dejar de versionar sin borrarlo del equipo mediante:
Después habría que añadirlo al .gitignore y confirmar el cambio.
Ojo: este comando no borra las versiones antiguas del historial ni revoca las credenciales que hayan podido quedar expuestas.
🔎 ¿Los escáneres de seguridad detectan estas contraseñas?
No siempre.
Los investigadores también comprobaron cómo respondían dos herramientas conocidas para buscar secretos en repositorios: Gitleaks y TruffleHog.
De los 1.122 archivos con información sensible, 215 no fueron identificados por ninguna de las dos herramientas en las pruebas realizadas.
El motivo es bastante sencillo: muchos escáneres reconocen formatos habituales de claves API, pero una contraseña escrita dentro de un comando de terminal puede parecer una cadena de texto cualquiera.
Por eso, tener un escáner de secretos configurado no garantiza que este tipo de filtraciones vaya a detectarse.
📌 En resumen
El problema no está en que Claude Code envíe automáticamente nuestras contraseñas a GitHub, sino en que puede conservar comandos completos con información sensible dentro de archivos que después terminan publicados por accidente.
Es una de esas situaciones en las que una función pensada para ahorrar tiempo puede convertirse en un riesgo de seguridad si no se conoce cómo funciona.
Y viendo que muchos desarrolladores utilizamos asistentes de IA para conectarnos a bases de datos, configurar servidores o probar APIs, no parece mala idea dedicar un par de minutos a revisar esos archivos.
🔗 Fuentes originales:
💬 ¿Utilizáis Claude Code habitualmente?
¿Habéis revisado alguna vez vuestro archivo
Resulta que una opción tan habitual como «Sí, y no vuelvas a preguntar» puede terminar guardando contraseñas, tokens y claves API en un archivo de configuración del proyecto. Y si ese archivo acaba en un repositorio público de GitHub, cualquiera podría consultar su contenido.
Lo más llamativo es que los investigadores han encontrado 2.539 secretos en 1.994 repositorios públicos.
No hablamos únicamente de claves para probar aplicaciones. Entre los casos detectados hay credenciales de bases de datos, accesos SSH, tokens de servicios y claves de infraestructuras en la nube.
🔴 ¿Cómo ocurre exactamente?
Cuando trabajamos con Claude Code, la herramienta suele pedir permiso antes de ejecutar determinados comandos en la terminal.
Por ejemplo, podemos pedirle que compruebe una conexión a una base de datos o que haga una petición a una API.
Si el comando incluye una contraseña o un token y seleccionamos «Sí, y no vuelvas a preguntar», Claude Code puede guardar una regla para recordar esa autorización en futuras sesiones.
El problema aparece cuando esa regla contiene el comando completo, incluyendo la contraseña o clave que se haya utilizado.
La información puede terminar almacenada en este archivo:
Insertar CODE, HTML o PHP:
.claude/settings.local.jsonEs decir, algo que debería servir para recordar permisos puede acabar funcionando como un pequeño almacén de credenciales en texto plano.
Importante: esto no significa que Claude Code publique automáticamente las contraseñas en GitHub.
La exposición se produce cuando esos archivos terminan subidos a repositorios públicos, por ejemplo, al incluirlos accidentalmente en un commit.
📊 ¿Qué encontraron los investigadores?
Apiiro analizó archivos públicos de configuración de Claude Code alojados en GitHub y encontró los siguientes resultados:
- 104.185 copias del archivo settings.local.json en repositorios públicos.
- 1.122 archivos contenían al menos un secreto.
- 1.379 credenciales diferentes aparecían en esos archivos.
- 63 organizaciones tenían información sensible expuesta.
- Al ampliar la búsqueda a historiales de Git, otros archivos de configuración y registros de agentes, el total ascendió a 2.539 secretos en 1.994 repositorios.
Entre las credenciales encontradas había 379 contraseñas de bases de datos, 43 accesos SSH, 42 tokens relacionados con GitHub, GitLab o npm y 23 claves de AWS.
Los investigadores también identificaron casos especialmente delicados, como credenciales con privilegios elevados sobre servicios en la nube y contraseñas relacionadas con una base de datos de historiales médicos.
Eso sí: encontrar una clave publicada no demuestra que siga funcionando ni que alguien la haya utilizado. Apiiro indica que no comprobó la validez de todas las credenciales, aunque una de las organizaciones notificadas confirmó que su clave había estado activa.
🧐 ¿Pero Claude Code no debería evitar que ese archivo se suba a GitHub?
Aquí está uno de los detalles más interesantes.
Según la documentación de Anthropic, Claude Code intenta mantener el archivo local fuera de Git mediante una configuración de exclusiones del usuario.
El inconveniente es que esa protección depende del entorno local y no equivale a incluir el archivo en el .gitignore del propio proyecto.
Por tanto, pueden producirse situaciones en las que el archivo termine versionado, especialmente si ya estaba incluido anteriormente o se trabaja desde otro entorno.
Y hay otro problema: borrar el archivo del repositorio no elimina necesariamente las contraseñas filtradas.
Si estuvo publicado, sus versiones anteriores pueden continuar en el historial de Git, en clones o en bifurcaciones del proyecto.
Por eso los investigadores recomiendan cambiar primero las credenciales comprometidas y después limpiar el repositorio.
🕒 Lo curioso es que el problema ya se había comunicado en 2025
La investigación también señala que este comportamiento no es completamente nuevo.
El 11 de agosto de 2025, un usuario abrió una incidencia en el repositorio oficial de Claude Code explicando que los comandos autorizados podían almacenarse con contraseñas y tokens sin ocultar.
El informe describía precisamente el archivo settings.local.json y el riesgo de que las credenciales acabaran compartidas accidentalmente.
La incidencia terminó cerrada como «not planned» mediante un proceso automatizado.
Esto no demuestra que Anthropic ignorase deliberadamente el problema, pero sí que existía un aviso público mucho antes de que se publicara esta investigación.
🛠️ ¿Qué deberían revisar quienes utilizan Claude Code?
Si utilizáis Claude Code para desarrollar aplicaciones, administrar servidores o trabajar con APIs, merece la pena comprobar algunas cosas:
- Revisar el archivo
.claude/settings.local.jsonde vuestros proyectos y comprobar si alguna regla de permisos contiene contraseñas, tokens o claves API. - Comprobar también
.claude/settings.json, especialmente si se comparte con otros desarrolladores. - Buscar esos archivos en vuestros repositorios de GitHub y revisar el historial de Git, aunque ya los hayáis eliminado.
- Si encontráis una credencial que haya sido publicada, revocarla o cambiarla inmediatamente. Borrar el archivo no es suficiente.
- Añadir
.claude/settings.local.jsonal archivo.gitignoredel proyecto. - Evitar introducir contraseñas directamente en los comandos. Es preferible utilizar variables de entorno o gestores de secretos, teniendo cuidado también con dónde se almacenan esas variables.
Si el archivo ya está siendo seguido por Git, se puede dejar de versionar sin borrarlo del equipo mediante:
Bash:
git rm --cached .claude/settings.local.jsonDespués habría que añadirlo al .gitignore y confirmar el cambio.
Ojo: este comando no borra las versiones antiguas del historial ni revoca las credenciales que hayan podido quedar expuestas.
🔎 ¿Los escáneres de seguridad detectan estas contraseñas?
No siempre.
Los investigadores también comprobaron cómo respondían dos herramientas conocidas para buscar secretos en repositorios: Gitleaks y TruffleHog.
De los 1.122 archivos con información sensible, 215 no fueron identificados por ninguna de las dos herramientas en las pruebas realizadas.
El motivo es bastante sencillo: muchos escáneres reconocen formatos habituales de claves API, pero una contraseña escrita dentro de un comando de terminal puede parecer una cadena de texto cualquiera.
Por eso, tener un escáner de secretos configurado no garantiza que este tipo de filtraciones vaya a detectarse.
📌 En resumen
El problema no está en que Claude Code envíe automáticamente nuestras contraseñas a GitHub, sino en que puede conservar comandos completos con información sensible dentro de archivos que después terminan publicados por accidente.
Es una de esas situaciones en las que una función pensada para ahorrar tiempo puede convertirse en un riesgo de seguridad si no se conoce cómo funciona.
Y viendo que muchos desarrolladores utilizamos asistentes de IA para conectarnos a bases de datos, configurar servidores o probar APIs, no parece mala idea dedicar un par de minutos a revisar esos archivos.
🔗 Fuentes originales:
- Investigación de seguridad de Apiiro (5 de noviembre de 2026)
- Incidencia publicada en GitHub en agosto de 2025
- Documentación oficial de configuración de Claude Code
- Documentación oficial del sistema de permisos de Claude Code
💬 ¿Utilizáis Claude Code habitualmente?
¿Habéis revisado alguna vez vuestro archivo
.claude/settings.local.json para comprobar qué comandos ha guardado?
