Saltar al contenido
sobolewski.proLa IA de hoy, cada tardeSuscribirme

Una vez al día. Date de baja con un clic. Política de privacidad

Filtración de credenciales en Claude Code por «Yes, and don’t ask again»

Filtración de credenciales en Claude Code: «Yes, and don’t ask again» dejó secretos en 1122 archivos públicos de GitHub. Veamos si nos afecta.

4 min de lectura

Este artículo en otros idiomas:العربيةDeutschEnglishFrançaisItaliano日本語Polski简体中文

En este artículo
  1. ¿En qué consiste la filtración de credenciales de Claude Code?
  2. Si el archivo es local, ¿cómo llegó a GitHub?
  3. ¿Qué alcance tiene?
  4. ¿Por qué se habla tanto de esto?
  5. ¿Qué conviene vigilar a partir de ahora?
  6. FAQ

El 5 de noviembre, los investigadores de Apiiro Shmulik Cohen y Matan Giladi publicaron un informe sobre una filtración de credenciales de Claude Code a GitHub. En 104.185 copias públicas del archivo .claude/settings.local.json encontraron 1122 archivos con al menos un secreto, en total 1379 contraseñas, claves de API y tokens distintos.

¿En qué consiste la filtración de credenciales de Claude Code?

Cuando Claude Code pide permiso para ejecutar un comando en la terminal, podemos elegir «Yes, and don’t ask again». Según la documentación de Claude Code, ese permiso se guarda como una regla allow en el archivo .claude/settings.local.json del proyecto.

El problema es que la regla guarda el comando aprobado completo, con todo lo que escribimos en él. Si el comando llevaba una contraseña, por ejemplo PGPASSWORD=… psql … o un curl con una clave de API en la cabecera, esa contraseña acaba en el archivo en texto plano.

Lo curioso es que no es un descubrimiento nuevo. En agosto de 2025 alguien reportó exactamente este problema en el issue #5544 (con ejemplos de claves de API y tokens de Jira). Un bot lo cerró el 3 de enero de 2026, tras 60 días sin actividad, como «not planned» y sin solución.

Si el archivo es local, ¿cómo llegó a GitHub?

En principio, el archivo es privado. La primera vez que Claude Code lo escribe, añade **/.claude/settings.local.json al archivo global de exclusiones de git para que no entre en los commits (así lo describe la documentación).

Pero esa protección tiene varios agujeros:

  1. La exclusión global funciona solo en un ordenador y no viaja con el repositorio.
  2. Si creamos el archivo a mano, Claude Code no lo excluye y tenemos que añadirlo nosotros al .gitignore.
  3. Las reglas de ignorar no se aplican a archivos que git ya sigue, así que un archivo commiteado una vez sigue entrando en los commits siguientes.
  4. Borrar el archivo del repositorio no lo elimina del historial ni de los forks.

Según iTWire, en 539 de los 1105 repositorios rastreados el archivo lo modificaron commits en los que Claude figuraba como coautor.

¿Qué alcance tiene?

Las cifras del informe (datos recogidos del GitHub público entre el 1 y el 3 de noviembre):

  1. 104.185 copias públicas de settings.local.json, de las cuales 1122 (alrededor del 1,1 %) contenían al menos un secreto.
  2. En esos archivos había 1379 valores distintos.
  3. Sumando el historial de git, el archivo compartido .claude/settings.json y las conversaciones guardadas con el agente, salen 2539 secretos en 1994 repositorios.
  4. Apiiro avisó a las empresas el 2 y el 3 de noviembre, y una de ellas confirmó que la clave expuesta estaba activa.

Un matiz: Apiiro no comprobó si las credenciales encontradas funcionaban. Cribó los candidatos con filtros de falsos positivos y la valoración de un modelo de lenguaje, así que algunas podían estar ya caducadas.

¿Por qué se habla tanto de esto?

El sábado por la noche el informe llegó a la portada de Hacker News. La opción «don’t ask again» sirve para que el agente no pregunte una y otra vez lo mismo, así que es fácil olvidar qué se ha guardado realmente.

Es también un ejemplo más de que hoy los secretos no se filtran solo desde el código de las aplicaciones, sino también desde los archivos de configuración de los agentes (como ocurrió con la filtración de OpenCode). Por ahora, en lo publicado por los medios no hay respuesta de Anthropic.

¿Qué conviene vigilar a partir de ahora?

  1. Primero revoquemos y cambiemos cualquier contraseña o clave que haya estado alguna vez en este archivo en un repositorio público. Solo después limpiemos el historial.
  2. Comprobemos si el archivo está bajo seguimiento: git ls-files .claude. Si lo está, dejemos de seguirlo (git rm --cached .claude/settings.local.json) y añadámoslo al .gitignore del propio repositorio, no solo al global.
  3. Revisemos también el historial (git log --all -- .claude/settings.local.json), el .claude/settings.json compartido y las conversaciones guardadas con el agente.
  4. No escribamos contraseñas directamente en los comandos. Es mejor pasarlas mediante variables de entorno o un gestor de secretos y, en las reglas allow, usar patrones como Bash(npm run test *) de la documentación.

Cuento más sobre cómo mantener las claves de API lejos de los agentes en la guía de seguridad de agentes de IA, y lo básico de la herramienta está en el tutorial de Claude Code.

FAQ

¿Claude Code envía mis contraseñas a GitHub por su cuenta?

No. El archivo settings.local.json se queda en nuestro disco. La filtración ocurre solo cuando el archivo entra en un commit y en un repositorio público.

¿Cómo compruebo si mi settings.local.json está en el repositorio?

Basta con ejecutar git ls-files .claude en la carpeta del proyecto. Si en la lista aparece settings.local.json, git lo está siguiendo. También vale la pena abrir el archivo y buscar contraseñas, tokens y claves en las reglas allow.

¿Basta con borrar el archivo del repositorio?

No. El archivo sigue en el historial de git y en los forks, por eso lo más importante es revocar y cambiar las credenciales expuestas.

  • IA
  • Claude Code
  • Anthropic
  • seguridad

La IA de hoy, cada tarde

Cada tarde, las noticias de IA más importantes del día y los nuevos artículos del blog. Breve y con fuentes.

Una vez al día. Date de baja con un clic. Política de privacidad