Claude Code puede exponer contraseñas y claves de API en GitHub por una confirmación de permiso

Claude Code puede dejar secretos en GitHub tras aprobar comandos de shell

Nos ayudas mucho si nos sigues en Google Seguir en

Una opción de permiso de Claude Code puede acabar dejando contraseñas, claves de API y otros secretos en repositorios públicos de GitHub. El problema descrito por investigadores de seguridad de Apiiro está en cómo se guarda la aprobación de ciertos comandos de shell: la regla puede conservar el comando tal cual, incluidas las credenciales que contenga.

Apiiro encontró más de 100.000 casos en los que el archivo local de configuración de Claude Code se había subido a repositorios públicos. En alrededor de 1.100 casos, repartidos entre 63 organizaciones, los investigadores identificaron secretos como tokens de API, contraseñas de bases de datos o claves privadas. Las cifras corresponden a los hallazgos atribuidos a Apiiro y no implican que todos los archivos publicados contuvieran credenciales.

Qué guarda Claude Code al autorizar un comando

El archivo implicado es .claude/settings.local.json. Cuando una persona acepta la opción “Yes, and don’t ask again” para ejecutar un comando automatizado, la aprobación queda registrada en una regla local. A veces se representa como un patrón; en otros casos, el comando se escribe directamente en el archivo.

La diferencia importa si el comando incluye información sensible. Por ejemplo, un desarrollador podría ejecutar una orden que incorpora una contraseña o un token como argumento. Si esa cadena se guarda literalmente en la configuración, el archivo deja de contener solo una preferencia de permisos: también conserva el secreto. Es un ejemplo hipotético del mecanismo descrito, no un caso concreto comunicado por Apiiro.

Guardar el archivo en el propio ordenador no equivale por sí solo a publicarlo. El riesgo aparece cuando la configuración se incorpora a un repositorio y este se comparte. Claude Code puede confirmar cambios en ese archivo sin intervención del usuario, según la investigación citada por Ars Technica.

Por qué una exclusión global de Git no basta

La documentación de Claude Code indica que el archivo se añade a la lista global de exclusión de Git del desarrollador. Esa lista ayuda a evitar que Git incluya el archivo en los repositorios de ese usuario, pero Apiiro señala que la exclusión no queda reflejada en la configuración del propio repositorio.

Por eso la protección puede no acompañar al proyecto. Entre las situaciones descritas están clonar un repositorio en otro equipo o convertir una carpeta en repositorio después de haber trabajado en ella. Si la configuración local queda dentro del árbol del proyecto y la exclusión no se aplica en ese entorno, el archivo puede terminar en un commit y, después, en GitHub.

La distinción es relevante para equipos: una regla global depende de la configuración de cada máquina, mientras que una exclusión definida en el repositorio puede viajar con el proyecto. Ninguna configuración sustituye a revisar qué archivos entran en un commit, pero la ausencia de una protección compartida deja más margen para que un cambio local se publique por error.

Qué implica para desarrolladores y responsables de IT

El hallazgo no significa que cualquier uso de Claude Code exponga credenciales. El riesgo descrito requiere que un comando con datos sensibles quede almacenado en la configuración y que el archivo llegue a un repositorio público. Apiiro encontró numerosos archivos publicados, pero una parte mucho menor contenía secretos identificados.

Para los equipos que usan agentes de desarrollo, la lección concreta es evitar introducir credenciales directamente en comandos que puedan quedar registrados. Es preferible que los procesos de trabajo lean los secretos desde mecanismos de configuración separados, en lugar de incorporarlos como texto en una orden. También resulta útil comprobar que los archivos locales de herramientas están excluidos en el propio repositorio, no solo en la configuración global de cada desarrollador.

Si se detecta una credencial publicada, borrar el archivo no garantiza que el secreto deje de estar expuesto. La investigación advierte que pueden persistir copias en bifurcaciones (forks) del repositorio original. Por tanto, la respuesta debe incluir la revocación o sustitución de las credenciales afectadas, además de retirar el archivo y revisar las copias conocidas. El contenido de un repositorio puede haber sido replicado antes de su eliminación.

El caso muestra una dependencia importante en las herramientas de programación con agentes: una confirmación pensada para agilizar ejecuciones repetidas también puede guardar el comando autorizado. Para las organizaciones, revisar permisos, exclusiones de Git y gestión de secretos forma parte del control del flujo de desarrollo, no solo de la configuración de la inteligencia artificial.

Fuente: artículo de Ars Technica sobre los hallazgos de Apiiro.

Blogs de tecnología Similares

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *