Claude Code filtra secretos de desarrolladores en repositorios públicos de GitHub

Un estudio de investigadores de Apiiro reveló que Claude Code, asistente de programación de Anthropic, puede guardar contraseñas, claves de API y tokens SSH en texto plano cuando un usuario selecciona la opción "Sí, y no preguntar nuevamente" durante la aprobación de comandos. Más de 1.000 copias de estos archivos de configuración fueron encontradas en repositorios públicos de GitHub, conteniendo 1.379 credenciales distintas.

El mecanismo del filtrado

El problema ocurre en un flujo de trabajo aparentemente inocente. Cuando un desarrollador usa Claude Code para ejecutar comandos de shell que incluyen credenciales — contraseñas de base de datos, claves de API, tokens de autenticación — el asistente pide permiso antes de ejecutar. El desarrollador puede hacer clic en "Sí, y no preguntar nuevamente" para evitar tener que aprobar el mismo comando repetidamente.

Donde reside el problema: en lugar de registrar solo un patrón genérico (como `Bash(npm run:*)`), Claude Code guarda el comando exacto, incluyendo la credencial en texto claro, en un archivo llamado `.claude/settings.local.json`. Si este archivo termina siendo commiteado y enviado a un repositorio público de GitHub — ya sea por accidente, por clonación en otra máquina, o porque el propio Claude Code lo commiteó — todas las credenciales quedan expuestas.

Los investigadores de Apiiro examinaron 104.185 copias públicas de este archivo en 103.617 repositorios. Cerca del 1,1% de ellos, o 1.122 copias, contenían al menos una credencial real, totalizando 1.379 secretos distintos. Cuando los investigadores ampliaron la búsqueda para incluir versiones más viejas del archivo, archivos de configuración compartidos y transcripts de chat de agentes, el total subió a 2.539 secretos en 1.994 repositorios.

La naturaleza de las credenciales expuestas es particularmente preocupante. Más de un tercio abría acceso directo a bases de datos, incluyendo 379 contraseñas de base de datos y 122 claves Supabase service-role. Otros incluyen 43 logins SSH para servidores públicos, algunos con contraseña de root, 42 tokens de GitHub, GitLab y npm, y 23 claves AWS.

Impacto organizacional

Aunque la mayoría de los archivos expuestos pertenecían a desarrolladores individuales, 63 organizaciones fueron afectadas, desde grupos estudiantiles hasta proveedores establecidos. Entre ellas: una empresa de bases de datos con clave de API cloud con acceso de administración, una agencia de software con token de producción de Square, y la contraseña de propietario de la base de datos en la nube de una aplicación de registros médicos.

Apiiro notificó a las organizaciones afectadas, aunque reconoció que no verificó si las credenciales aún funcionaban. Una organización confirmó que su clave aún estaba activa.

Por qué las herramientas de seguridad convencionales fallaron

Un dato que debería alarmar a los equipos de seguridad: de los 1.122 archivos con secretos, gitleaks (un scanner de secretos ampliamente utilizado) solo señalizó 564, y TruffleHog, otro scanner popular, señalizó solo 643. Esto significa que 215 archivos con credenciales en texto claro escaparon tanto a gitleaks como a TruffleHog.

El problema tampoco se limita a GitHub. El archivo reside en formato JSON puro en las máquinas de los desarrolladores, donde puede ser encontrado por malware. En septiembre de 2025, el worm Shai-Hulud del npm ejecutó el scanner TruffleHog sobre los archivos de las máquinas infectadas, señalizando más de la mitad de los archivos como conteniendo secretos.

La respuesta de Anthropic

Boris Cherny, jefe del Claude Code en Anthropic, reconoció el problema en un foro de Hacker News, diciendo que la empresa está buscando soluciones. "Históricamente, Claude Code no hizo limpieza de secretos (existen muchas buenas herramientas para eso), pero estamos evaluando qué podemos hacer para evitarlo", dijo Cherny.

El equipo planea prototipar enfoques incluyendo hacer que el modo automático capture estos comandos e integre un scanner básico de secretos. Sin embargo, un lector señaló que la misma exposición podría ocurrir en modo auto, y Cherny estuvo de acuerdo: "Buen punto".

Cherny también argumentó que ya que Claude Code agrega el archivo a la lista global de .gitignore del desarrollador en la creación, las copias expuestas fueron creadas manualmente y enviadas. Sin embargo, los investigadores observaron que en 539 de los 1.105 repositorios que rastrearon, un commit listando a Claude como coautor modificó el archivo — sugiriendo que el propio Claude frecuentemente commitea el archivo de configuraciones.

Un problema reportado por más de un año

Los usuarios de Claude Code reportaron este comportamiento en issues de GitHub desde agosto de 2025. En diciembre de 2025, un reporte describió claves de API llegando al settings.local.json y terminando en un repositorio público. Un bot automático cerró el reporte como "no planificado" en enero de 2026, después de 60 días sin respuesta del equipo de Anthropic.

El problema es fundamental: Claude Code no agrega el archivo al propio .gitignore del proyecto — lo agrega solo a la lista global del usuario. Esto significa que la protección no viaja con el proyecto. Cuando alguien clona el repositorio o cuando una carpeta se convierte en un repositorio, la protección desaparece.

Qué hacer

Los investigadores recomiendan:

1. Buscar su repositorio de GitHub por `.claude/settings.local.json` y `.claude/settings.json` en cada repositorio 2. Verificar el historial de git para copias más antiguas 3. Rotar todas las credenciales antes de limpiar los archivos — eliminar el archivo no remueve commits anteriores ni forks 4. Dejar de poner secretos en comandos. Usar variables de manejador de secretos (como `$DB_URL`) en lugar de contraseñas en texto claro 5. Adoptar aprobación por patrón (como `Bash(npm run:*)`) en lugar de comandos individuales 6. Agregar `.claude/settings.local.json` a las plantillas de .gitignore de la organización

El caso del Claude Code ilustra una tensión creciente en el ecosistema de desarrollo: cuanto más poder damos a asistentes de código basados en IA, más vulnerables nos volvemos a tipos de filtrado que no son exploits sofisticados, sino consecuencias de funcionalidades diseñadas para conveniencia. El problema no es que un modelo de IA fue "engañado" — es que una funcionalidad de conveniencia guardó datos sensibles en texto claro, y el ecosistema de seguridad en el que los desarrolladores confiaron para protegerlos simplemente no pudo detectar el patrón.

La pregunta a observar: si scanners consolidados como gitleaks y TruffleHog perdieron cerca del 20% de estas credenciales, ¿cuántos otros secretos están circulando en repositorios públicos sin que nadie lo sepa?

Fuentes: The Hacker News, iTWire, iTnews Australia

✓ Fuentes independientes cruzadas y verificadas antes de la publicación