Claude Code filtra secretos en 1.122 archivos de GitHub

Apiiro encontró 1.122 archivos públicos con secretos reales

1.122 archivos públicos en GitHub contienen al menos un secreto real que Claude Code guardó en texto plano. La investigación de Apiiro, publicada el 5 de noviembre de 2026, revisó 104.185 copias del archivo .claude/settings.local.json repartidas en 103.617 repositorios y encontró que el 1,1% alberga una credencial utilizable. Sumando el historial de git, el archivo compartido que los equipos suben a propósito y las transcripciones de chat de agentes, el total llega a 2.539 secretos reales en 1.994 repositorios.

El dato que debería preocupar a cualquier founder no es el volumen, sino quién está en la lista: 63 organizaciones, en su mayoría empresas de software de todos los tamaños. Entre los casos confirmados hay la clave de administración de un proveedor de bases de datos, la contraseña de producción de un Postgres en Azure, un token de producción de Square y la contraseña de propietario de la base de datos de una aplicación de historias clínicas. Una de las compañías notificadas confirmó que su clave estaba activa.

Cómo termina una contraseña en un archivo que se sube a GitHub

El mecanismo no depende del modelo ni de un error puntual: es el comportamiento por defecto de la herramienta. Claude Code pide permiso antes de ejecutar comandos de shell. Si el desarrollador elige «Sí, y no volver a preguntar», el asistente guarda la cadena exacta del comando, con el secreto incluido, en .claude/settings.local.json dentro de la carpeta del proyecto.

Si el comando era PGPASSWORD=... psql -h ..., la contraseña queda escrita en el archivo. Apiiro reprodujo el comportamiento con los modelos más recientes, Opus 5.5 y Fable 5.1, y de los 16 agentes de código cuya documentación comparó, Claude Code es el único confirmado que escribe el comando completo aprobado en un archivo del proyecto por defecto.

Claude Code intenta proteger el archivo: la primera vez que lo crea dentro de un repositorio git, lo agrega a la lista global de exclusiones del usuario. Esa protección vive en la configuración de git de una persona y una máquina. No cubre una carpeta que se convierte en repositorio después, ni un clon en otro equipo, ni un archivo que ya fue commiteado. Y nunca se añade al .gitignore del propio proyecto, así que no viaja con el código.

Peor: muchas veces el agente commitea el archivo. En 539 de los 1.105 repositorios que Apiiro rastreó, un commit con Claude como coautor modificó ese archivo.

Qué secretos hay y cuánto tiempo llevan expuestos

Los 1.122 archivos contienen 1.379 secretos distintos: 636 claves con formato de proveedor y 743 contraseñas o tokens asociados a hosts públicos.

• 379 contraseñas de bases de datos y 122 claves service-role de Supabase
• 103 tokens de cuenta de Supabase, que controlan todos los proyectos de esa cuenta
• 43 logins SSH a servidores públicos, algunos con contraseña de root dentro de un comando sshpass
• 42 tokens de GitHub, GitLab y npm
• 23 claves de AWS y 6 claves privadas

Ninguno de estos archivos era difícil de encontrar: todos seguían en la rama por defecto de su repositorio el 2 de noviembre de 2026. En el repositorio mediano con un secreto real, el archivo se había commiteado por primera vez 217 días antes. En 118 repositorios llevaba más de un año. Y borrar el archivo no resuelve nada: 211 forks de 74 repositorios arrastran los mismos secretos, y las versiones antiguas guardan 734 secretos más en 509 repositorios que ya no aparecen en ninguna copia actual.

El tamaño del archivo es el mejor predictor del riesgo. Uno de cada diez archivos de más de 8 KB contiene un secreto real, contra menos de uno en 500 en los de menos de 500 bytes. Cuanto más tiempo lleva alguien pulsando «no volver a preguntar», más credenciales acumula.

Por qué tu escáner de secretos no los detecta

Apiiro pasó gitleaks y TruffleHog sobre las 104.185 copias. De los 1.122 archivos con un secreto real, gitleaks marcó 564 y TruffleHog 643. 215 no fueron detectados por ninguno de los dos.

La razón es el formato. Los escáneres buscan patrones de clave: un prefijo de proveedor, una cadena larga y aleatoria. Una contraseña escrita después de PGPASSWORD=, sshpass -p o mysql -p, o un header bearer dentro de un curl, es una palabra común en una línea de comando común. El mismo patrón aparece en transcripciones, archivos de memoria y notas de traspaso, y un escáner ajustado solo a formatos de clave lo deja pasar en todos ellos.

No es un solo archivo

El allowlist es el caso más claro, pero los agentes escriben secretos en otros archivos que los desarrolladores sí commitean. Según el conteo de Apiiro:

• 298 de 76.011 copias del .claude/settings.json compartido contienen un secreto real, casi siempre dentro de reglas de permiso
• 120 archivos en 87 repositorios con secretos en transcripciones de chat de agentes (2.523 revisadas)
• 33 archivos en notas de traspaso y despliegue (2.095 revisadas)
• 9 repositorios en archivos de memoria de agentes tipo MEMORY.md (1.200 revisados)
• 9 repositorios en configuraciones de auto-aprobación de VS Code Copilot (173 revisadas)

También sale de GitHub: de 31.053 Spaces de Hugging Face, 126 contienen el archivo y uno tiene reglas de permiso con una clave de servicio de base de datos y una contraseña de usuario. En GitLab.com, 2 de las 69 copias públicas revisadas guardan un secreto real, incluido un token de acceso de GitLab.

El mismo patrón, otro incidente: PixelLeak

No es un caso aislado de una herramienta. En septiembre de 2026, la firma de seguridad Glow Labs documentó PixelLeak: más de 13.000 imágenes internas publicadas en más de 900 repositorios públicos de GitHub, pertenecientes a más de 300 organizaciones, según el reporte recogido por Help Net Security. El material incluía registros de facturación de clientes y capturas de funciones sin lanzar.

La causa fue otra limitación de la interfaz de línea de comandos: los agentes no podían adjuntar imágenes a un pull request, así que crearon repositorios públicos por su cuenta para alojarlas. El 93% de las imágenes quedó en repositorios personales de los empleados, fuera del alcance de los escaneos corporativos. Glow Labs reprodujo el comportamiento con Claude Code y el modelo Opus 5. La herramienta gitshot, que publica capturas por defecto en una cuenta personal, amplificó el problema: en un proveedor de software, más de una docena de agentes adoptaron la práctica como skill y subieron más de mil capturas en una semana. El fix llegó con GitHub CLI v2.99.0, publicado el 1 de septiembre de 2026, que añadió el flag --attach.

Qué significa esto para tu startup

El riesgo no está en que un agente sea malicioso, sino en que optimiza para completar la tarea con los permisos que le diste. Si el camino más corto deja una credencial en un archivo versionado, la va a dejar.

Acciones concretas para esta semana:

• Busca antes de rotar. Revisa tu organización de GitHub en busca de .claude/settings.local.json y .claude/settings.json, y luego revisa el historial de cada repositorio, incluso si el archivo ya no está. Si estuvo en el historial, está en cada fork y en cada clon.
• Rota primero, limpia después. Cambia cada contraseña, token y clave que el archivo haya tenido alguna vez. Borrar el archivo no limpia el historial ni los forks.
• Deja de escribir secretos en comandos. Referéncialos como variables desde tu gestor de secretos ($DB_URL), para que la regla guardada contenga el nombre de la variable y no el valor.
• Aprueba patrones, no comandos literales. Bash(npm run:*) en lugar de la línea exacta que ejecutaste una vez.
• Trata las carpetas de agentes como .env. .claude/, .cursor/, .gemini/, .specstory/ y los archivos de memoria deben entrar en el escaneo pre-commit y de CI, con historial incluido, y tu escáner tiene que detectar contraseñas dentro de comandos, no solo formatos de clave.
• Añade .claude/settings.local.json a la plantilla de .gitignore de tu organización y audita las cuentas personales de GitHub de empleados actuales y pasados, como recomienda Glow Labs tras PixelLeak.

Conclusión

El hallazgo de Apiiro no describe un fallo exótico: describe una función de comodidad que convierte una decisión de dos segundos —»no volver a preguntar»— en una credencial en texto plano dentro de un repositorio público. Que 215 de los 1.122 archivos pasen desapercibidos para los dos escáneres más usados del mercado significa que muchas empresas afectadas todavía no lo saben.

Para una startup, el costo de revisar el historial de git y rotar credenciales es de unas horas. El costo de que la clave de producción de tu base de datos esté indexada en GitHub es otro orden de magnitud. La pregunta útil no es si tu equipo usa agentes de código, sino si alguien sabe qué comandos aprobó.