Claude Code deja contraseñas a la vista en GitHub
Un clic para que el agente no vuelva a preguntar puede acabar con tus claves en un repositorio público. Delegar no exime de revisar.

Contraseñas y claves API que algunos desarrolladores escribieron en comandos aprobados en Claude Code están ahora en repositorios públicos de GitHub, a la vista de cualquiera. Así lo cuenta The Hacker News a partir de un análisis de la empresa de seguridad de software Apiiro, que ha contado 1.122 copias públicas del archivo implicado en GitHub.
El problema no nace de un ataque sofisticado ni de una brecha en los servidores de Anthropic. Nace de una comodidad: la opción «Sí, y no preguntes más».
Cómo pasa
Claude Code, el asistente de programación con inteligencia artificial de Anthropic, pide permiso antes de ejecutar ciertos comandos. Para no tener que aprobar lo mismo una y otra vez, ofrece la opción «Sí, y no preguntes más». Según The Hacker News, al elegirla, el asistente puede guardar el comando tal cual, palabra por palabra, en un archivo de ajustes del proyecto. Si ese comando llevaba una contraseña o una clave API escrita dentro, el secreto queda guardado con él.
El resto lo hace la rutina de cualquier proyecto: el archivo vive dentro de la carpeta del código, se incluye en un commit, se sube a GitHub y, si el repositorio es público, la clave queda publicada. Nadie la ha filtrado a propósito; simplemente nadie miró qué había dentro de ese archivo antes de subirlo.
El material disponible no detalla cuántas de esas claves siguen siendo válidas, a qué servicios corresponden ni si Anthropic ha anunciado algún cambio en el comportamiento de la herramienta.
Qué hacer si usas Claude Code
Si has aprobado comandos con «no preguntes más», conviene revisar el proyecto:
- Abre el archivo de ajustes del proyecto que genera Claude Code y busca contraseñas, tokens o claves API dentro de los comandos guardados.
- Si aparece alguna y el archivo ha llegado a un repositorio, da la clave por comprometida. Revócala y genera una nueva en el servicio correspondiente. Borrar el archivo en un commit nuevo no basta: lo que se ha subido sigue en el historial de git y puede haber sido copiado ya.
- Saca ese archivo del control de versiones si no necesitas compartirlo, añadiéndolo a las exclusiones del proyecto.
- No escribas secretos directamente en los comandos. Las variables de entorno o un gestor de secretos evitan que acaben copiados en cualquier sitio.
El agente no firma los commits
La tentación de estas herramientas es delegar cada vez más y mirar cada vez menos. «Sí, y no preguntes más» es justo eso: una forma de quitarse de en medio. Pero lo que el agente escribe en el disco y lo que acaba en un repositorio público sigue siendo responsabilidad de quien lo publica.
El caso también dice algo del diseño: una herramienta que guarda permisos en texto plano dentro del propio proyecto, sin filtrar lo que parece un secreto, deja la seguridad en manos de que cada persona revise archivos que probablemente ni sabe que existen. Mientras eso no cambie, la revisión manual es la única barrera, y 1.122 repositorios muestran que no siempre se hace.
Fuente: The Hacker News
Sigue leyendo
Noticia
El creador de systemd quiere un Linux sin shell
Imágenes firmadas, sin SSH ni Python por defecto. Más difícil de atacar, quizá también más difícil de tocar para quien administra la máquina.
Noticia
Roban a un banco francés a través de un proveedor
El banco asegura que sus clientes no han perdido nada, pero el agujero estaba en casa de un proveedor. Y eso puede pasarle a cualquiera.
Noticia
Barcos ligados a Irán merodean sobre cables de internet
Irak, Kuwait, Baréin y Catar solo se conectan al mundo por cables que cruzan Ormuz. Unos pocos cortes podrían dejarlos aislados.
