Claude Code filtra secretos en GitHub tras el "no preguntar"

Más de mil repositorios públicos de GitHub guardan contraseñas en texto plano, claves de AWS y credenciales de bases de datos. No porque alguien las haya escrito en el código fuente, sino porque los desarrolladores pulsaron "Sí, y no volver a preguntar" en Claude Code, de Anthropic. El asistente de programación con IA guarda los comandos aprobados literalmente en un archivo de configuración del proyecto, con secretos incluidos. La firma de seguridad Apiiro dijo ayer que encontró 1.122 copias públicas de ese archivo con al menos un secreto, según The Hacker News.

El alcance no es teórico. Los archivos expuestos pertenecen a 63 organizaciones, sobre todo empresas de software, y el informe de investigación de Apiiro describe hallazgos como la clave de administrador en la nube de un proveedor de bases de datos y la contraseña de propietario de una base de historiales médicos. Una empresa a la que los investigadores avisaron esta semana confirmó que su clave seguía activa. Y aquí está la parte que determina quién es responsable del incidente: borrar el archivo no soluciona nada, porque las versiones antiguas persisten en el historial de git y en 211 forks. La rotación de credenciales es la única solución, y corresponde a quien sea dueño del repositorio, sin importar qué empleado o qué agente haya confirmado el archivo.

La base: una lista de permisos que guarda la cadena completa del comando

Recorramos la cadena paso a paso, porque el fallo es banal y precisamente por eso se extendió. Por defecto, Claude Code pide permiso antes de ejecutar la mayoría de comandos de shell. Si eliges "Sí, y no volver a preguntar", escribe una regla de permiso en .claude/settings.local.json dentro del proyecto, según la documentación de permisos de Anthropic. Los comandos que coincidan se ejecutan después sin supervisión en las sesiones futuras. Es la función funcionando tal como fue diseñada.

El fallo está en lo que se guarda. La regla cubre lo que ofrecía el aviso: a veces un patrón como npm test *, a veces un comando exacto. Cuando es el comando exacto, cualquier contraseña o token que hayas escrito en él queda persistido en texto plano. Apiiro reprodujo este comportamiento con los modelos más recientes, Opus 5.5 y Fable 5.1. Un ingeniero del hilo de Hacker News describió haber topado con el mismo problema en la práctica: aprobar una vez curl -H "Authorization: Bearer sk-..." y el token queda en el archivo de configuración hasta que alguien lo vuelve a leer.

{
"permissions": {
"allow": [
"Bash(PGPASSWORD=hunter2 psql -h db.example.com -U admin)"
]
}
}

Claude Code sí intenta mantener el archivo fuera de git: la primera vez que escribe el archivo en un repositorio, lo añade a las exclusiones globales de git del usuario, según su documentación de configuración. Pero esa protección es por usuario y por máquina. No hace nada con un archivo que ya está confirmado, y Claude Code nunca añade el archivo al .gitignore propio del proyecto, así que la protección no viaja con el repositorio. Peor aún, en 539 de los 1.105 repositorios que Apiiro rastreó, un commit con Claude como coautor modificó el archivo, algo que los investigadores interpretan como que el agente confirma con frecuencia su propia configuración con secretos. Un comentarista de Hacker News que se identificó como miembro del equipo de Claude Code afirmó que el archivo debe permanecer local y que el equipo está estudiando cómo prevenirlo. Es un comentario de foro no verificado, pero el mecanismo que describe coincide con la documentación.

Un interruptor de comodidad, 2.539 secretos

El escaneo de Apiiro sobre GitHub público encontró 104.185 copias de settings.local.json en 103.617 repositorios. Alrededor del 1,1 % de ellas, es decir 1.122 archivos, contenían al menos un secreto, con un total de 1.379 secretos distintos. Un valor se consideraba secreto cuando coincidía con un formato de clave conocido o aparecía junto a la dirección de un servidor público, y un revisor de IA tenía que confirmarlo. Más de un tercio abre directamente una base de datos: 379 contraseñas de bases de datos, además de 43 accesos SSH a servidores públicos, 42 tokens de GitHub, GitLab y npm, y 23 claves de AWS.

Las cifras de antigüedad son la parte más preocupante. A fecha del lunes, todos los archivos con secretos seguían en la rama por defecto de su repositorio, y en la mitad de esos repositorios llevaban allí al menos 217 días. El historial de git guarda otros 734 secretos en 509 repositorios que ya no aparecen en ninguna copia actual, normalmente porque alguien borró el archivo y dio el asunto por cerrado. Los forks propagan la filtración: 211 forks de 74 repositorios contienen los mismos secretos que sus originales. Si sumas el archivo compartido .claude/settings.json, que los equipos confirman a propósito (298 de 76.011 copias tenían secretos, sobre todo dentro de reglas de permiso), además de versiones antiguas y registros guardados de chats con agentes, el total de Apiiro llega a 2.539 secretos en 1.994 repositorios. De los 16 agentes de programación cuya documentación compararon los investigadores, Claude Code es el único que, según se ha confirmado, guarda por defecto el comando aprobado completo en un archivo del proyecto.

Quedan dos cosas sin resolver, y ambas importan. Apiiro no comprobó si los secretos siguen funcionando: la única clave activa se conoce por la confirmación de una empresa notificada. Y los investigadores no dicen si alguien ha abusado de las credenciales expuestas. Considéralo preguntas abiertas, no motivos para tranquilizarse.

Por qué gitleaks y TruffleHog pasaron de largo

Si piensas que tu escaneo de secretos en CI ya cubre esto, probablemente no. Apiiro ejecutó gitleaks y TruffleHog, sin sus pasos de verificación, sobre todos los archivos. De los 1.122 con secretos, gitleaks detectó 564 y TruffleHog 643; ninguno de los dos encontró 215. Los fallos son estructurales: los escáneres buscan formatos de clave conocidos, y una contraseña que sigue a PGPASSWORD=, sshpass -p o mysql -p parece una palabra corriente dentro de una línea de comandos corriente. Es la misma brecha de detección que hemos visto en historias de herramientas afines, desde agentes manipulados por un archivo suelto hasta la extensión troyanizada de Claude Code en el mercado de Cursor: el directorio de trabajo del agente es un límite de confianza que nadie vigila.

Las copias que nunca tocan GitHub también cuentan. El archivo es JSON plano en la carpeta del proyecto, lo que significa que viaja dentro de paquetes npm, imágenes Docker, archivos zip y carpetas sincronizadas. Y el malware ya frecuenta este pasillo: en septiembre de 2025, el gusano Shai-Hulud ejecutó el escáner TruffleHog en las máquinas infectadas, y marcó como secretos más de la mitad de los archivos que encontró. Un settings.local.json sin confirmar en un portátil es un botín esperando al próximo infostealer con una regla de scraping.

Presentado en agosto, cerrado por un bot

Esto no sorprendió a nadie que siguiera el gestor de incidencias. Un informe de error presentado el 11 de agosto de 2025 describía que los comandos aprobados con claves API y tokens se guardaban palabra por palabra en settings.local.json. Un bot automático lo cerró como "no planificado" el 3 de enero, tras 60 días de inactividad. Según los investigadores, a día de hoy las cuatro incidencias relacionadas que citan se han cerrado con el mismo bot, la más reciente ayer, y ninguna recibió respuesta de Anthropic. Anthropic no ha respondido públicamente a los hallazgos de Apiiro hasta el momento de escribir esto.

Quién rota y qué auditar esta semana

En cuanto a responsabilidades, no le des demasiadas vueltas: la organización dueña del repositorio es la dueña de la rotación. No importa que un agente escribiera el archivo, que un bot cerrara la incidencia o que el desarrollador pulsara un botón que la herramienta le ofrecía. La credencial es tuya, es pública, y el orden de remediación está fijado: primero rota, después limpia, porque con el historial y los forks limpiar por sí solo es cosmético. Piénsalo como una muerte permanente para los secretos: no hay partida guardada, solo un personaje nuevo.

Lista de verificación para desarrolladores de Apiiro, resumida:

• Busca en la organización de GitHub .claude/settings.local.json y .claude/settings.json, y revisa el historial de git de cada repositorio en busca de ambos, incluso cuando los archivos hace tiempo que no existen.
• Rota cada contraseña, token y clave que los archivos hayan contenido, antes de cualquier limpieza.
• Deja de rastrear el archivo local: git rm --cached .claude/settings.local.json y después añádelo al .gitignore del propio repositorio.
• Abre el archivo en tu propia máquina aunque nunca se haya confirmado, y borra cada regla que contenga un secreto.
• Mantén los secretos fuera de los comandos por completo: referencia variables de un gestor de secretos, como $DB_URL, para que la regla guardada almacene solo el nombre de la variable. Aprueba patrones como Bash(npm run:*) en lugar de comandos sueltos.

Para los equipos de seguridad, los investigadores recomiendan tratar las carpetas de agentes (.claude/, .cursor/, .gemini/, .specstory/) y los archivos de memoria de los agentes como portadores de secretos, igual que .env, tanto en portátiles como en repositorios. Inclúyelos en el escaneo de pre-commit y de CI, incluido el historial de git, con reglas que detecten contraseñas dentro de las líneas de comandos y no solo formatos de clave conocidos. Añade .claude/settings.local.json a las plantillas de .gitignore de la organización. Y prioriza según la accesibilidad: las credenciales emparejadas con una dirección de servidor público van primero, porque son las que realmente abren una puerta.

El enfoque editorial es correcto, y los datos lo respaldan: esto es un fallo de diseño disfrazado de error del usuario. Una herramienta que guarda los comandos aprobados literalmente, escribe el resultado en un archivo del proyecto, protege ese archivo solo en la máquina que lo creó y a veces confirma el propio archivo, ha construido un canal de exfiltración de credenciales a partir de pura comodidad. Sesenta y tres organizaciones están gestionando ahora un incidente por culpa de un botón. Hasta que cambie el valor por defecto, la lista de permisos es tu superficie de ataque: audítala como tal.