IA en un minutoNoticiasSeguridad
Apiiro halla contraseñas y claves expuestas en GitHub por una opción de aprobación de Claude Code
Redacción de IA en un minuto · Editor: Jon Elgezabal
En 30 segundos
Apiiro rastreó GitHub y dio con contraseñas y claves de acceso en 1.122 de las 104.185 copias públicas del archivo donde Claude Code anota los permisos concedidos. Claude Code las deja ahí cuando alguien aprueba una orden para siempre, y quedan a la vista si después se sube la carpeta del proyecto con ese archivo. Gitleaks y TruffleHog, dos detectores muy extendidos, pasaron por alto 215 de esos archivos.
La firma de ciberseguridad Apiiro publicó el 5 de noviembre un estudio sobre los permisos que guarda Claude Code, el asistente de programación de Anthropic. Revisó 104.185 copias públicas en GitHub del archivo .claude/settings.local.json y en 1.122 encontró lo que llama secretos reales: contraseñas, claves de API y otros datos de acceso.
El problema nace en el trabajo diario. Antes de ejecutar una orden en la terminal, Claude Code pide permiso, y una de las respuestas posibles es "Yes, and don't ask again". Si se elige, la herramienta guarda esa orden exacta como regla permitida en el archivo local del proyecto, y si la orden llevaba una contraseña, por ejemplo para entrar en una base de datos, la contraseña queda escrita tal cual. Claude Code intenta que el archivo no se suba: cuando lo crea dentro de un repositorio, lo añade a la lista global de exclusiones de Git de quien programa. Según Apiiro, esa protección se queda en su ordenador y no viaja con el proyecto, de modo que no cubre una carpeta que se convierte en repositorio más tarde, una copia en otro equipo ni un archivo que ya se había subido. En 539 de los 1.105 repositorios con secretos que rastreó, el archivo cambió en un commit en el que Claude figura como coautor.
Esos 1.122 archivos reúnen 1.379 secretos distintos. Más de un tercio dan acceso directo a una base de datos: 122 claves de servicio de Supabase y 379 contraseñas de bases de datos. Hay además 43 accesos por SSH a servidores públicos. Si se suman las versiones anteriores del archivo, el archivo de configuración que los equipos comparten a propósito y las conversaciones con agentes guardadas en los repositorios, Apiiro llega a 2.539 secretos en 1.994 repositorios públicos, de 63 organizaciones, la mayoría empresas de software.
Las herramientas habituales no los detectan todos. Apiiro pasó Gitleaks y TruffleHog por los 1.122 archivos: el primero señaló 564 y el segundo 643, y en 215 no saltó ninguno de los dos. Son sobre todo contraseñas escritas dentro de una orden, que no tienen el formato reconocible de una clave de proveedor.
Apiiro no probó ninguna credencial ni se conectó a los servidores. Llama secreto real a una clave con el formato de un proveedor conocido o a una contraseña que aparece junto a la dirección de un servidor público, no a una que haya comprobado que funciona. Avisó a las organizaciones afectadas el 2 y el 3 de noviembre, y una confirmó que su clave estaba activa. La firma recuerda que usuarios de Claude Code han descrito este comportamiento en GitHub desde agosto de 2025 y que, según su recuento, Anthropic no respondió a ninguno de esos avisos. Su recomendación para quien tenga el archivo publicado es cambiar primero las credenciales y limpiar después, porque el historial, las bifurcaciones y las copias del repositorio conservan el contenido.
Por qué importa · análisis y opinión
Lo llamativo del hallazgo es que no hace falta ningún atacante: basta un clic pensado para trabajar más rápido y un archivo que nadie revisa antes de subir el código. Los asistentes de programación acumulan permisos durante semanas, y esas listas acaban guardando datos tan delicados como el propio código. Quien use Claude Code puede abrir hoy el archivo de permisos de cada proyecto, borrar las reglas que lleven contraseñas y comprobar que no figura en el historial del repositorio. Si aparece, lo primero es cambiar esas credenciales. A medio plazo, lo sensato es que las contraseñas lleguen a las órdenes desde un gestor de secretos y no escritas a mano, y que los equipos de seguridad incluyan las carpetas de los agentes en sus revisiones.
Fuente oficial: Apiiro · Redactada con ayuda de IA: cómo hacemos las noticias
¿Qué significa para tu negocio? · análisis y opinión
Afecta a cualquier pyme, startup o programador autónomo de España o Latinoamérica que use Claude Code en proyectos guardados con Git, sobre todo si los repositorios son públicos o se clonan en varios equipos. Quien no usa este asistente, o nunca ha pulsado "Yes, and don't ask again" ante un comando que llevara una contraseña, no tiene este problema concreto, aunque conviene comprobarlo igualmente.
Lo prudente es buscar el archivo .claude/settings.local.json en los proyectos y en su historial de Git, y revisar si las reglas aprobadas contienen contraseñas, tokens o cadenas de conexión. Si aparece alguna, el orden importa: primero se cambia o revoca la credencial y después se borra el archivo, porque las copias antiguas siguen en commits, forks y clones. Luego basta con dejar de seguir el archivo con git rm --cached y añadirlo al .gitignore del propio repositorio, que sí viaja con el proyecto. Nuestro consejo es no confiar solo en un escáner automático: Gitleaks y TruffleHog pasaron por alto 215 de los archivos afectados.
Prevenir cuesta muy poco, unos minutos de revisión y cambiar algunas contraseñas. No hacerlo puede dejar al alcance de cualquiera el acceso a bases de datos, servidores por SSH o servicios en la nube. A partir de ahora conviene aprobar solo patrones de comandos acotados y usar referencias a un gestor de secretos en lugar de escribir la contraseña dentro del comando.
