A estas alturas ya te has enterado. El 31 de marzo de 2026, Anthropic la cagó. Un update rutinario de Claude Code en npm incluyó un archivo de source map que apuntaba a un zip con todo el código fuente del producto. 512.000 líneas de TypeScript, 1.906 archivos. Todo al aire.
No voy a repetirte los detalles porque llevas dos días leyendo hilos sobre esto. Lo que sí quiero contarte es lo que no se está comentando lo suficiente, y que me parece bastante más preocupante que la filtración en sí.
Tres incidentes, un solo día
Lo primero que hay que entender es que el 31 de marzo no pasó una cosa, pasaron tres. Y la mayoría de medios las han mezclado en una sola historia, lo cual ha generado bastante confusión.
La filtración del código de Claude Code. Un error de empaquetado hizo que el source map acabara en el paquete npm público. Un investigador de seguridad llamado Chaofan Shou lo detectó en minutos. En cuestión de horas, el código estaba replicado en cientos de repositorios de GitHub, con más de 41.500 forks. Anthropic empezó a lanzar DMCAs para intentar contener el daño, pero a esas alturas ya era imposible.
El ataque a la cadena de suministro de axios. Esto es completamente independiente de la filtración de Claude Code, aunque ocurrió el mismo día. Un atacante comprometió la cuenta npm del mantenedor principal de axios y publicó versiones maliciosas (la 1.14.1 y la 0.30.4) que incluían un troyano de acceso remoto. La ventana de exposición fue de unas 3 horas, entre las 00:21 y las 03:15 UTC. Google Threat Intelligence atribuyó el ataque a un grupo vinculado a Corea del Norte.
El typosquatting de paquetes internos. Un usuario de npm registró cinco paquetes con nombres idénticos a los paquetes internos de Anthropic que aparecían en el código filtrado. De momento eran stubs vacíos, pero el objetivo era claro: esperar a que alguien intentara compilar el código filtrado y pillarlo con una dependencia maliciosa.
Tres incidentes distintos. Actores distintos. Métodos distintos. Pero al caer el mismo día, muchos artículos los han tratado como si fueran la misma historia.
¿Afectó el ataque de axios a Claude Code?
Esta es la pregunta que más he visto estos días, y la respuesta corta es no. Claude Code empaqueta todas sus dependencias, incluido axios, dentro de un solo archivo JavaScript en tiempo de compilación. Cuando instalas Claude Code con npm, no se descarga axios por separado. No hay dependencia que resolver en tiempo de instalación.
Varios medios publicaron que los usuarios de Claude Code que instalaron o actualizaron durante esa ventana de 3 horas podrían haberse visto afectados. Eso es técnicamente incorrecto para Claude Code en concreto, aunque sí es un riesgo real para cualquier otro proyecto que tuviera axios como dependencia y ejecutara un npm install durante ese período.
Y a mí me consta que fue un riesgo real. El mismo día recibí correos de Datadog avisando de que habían detectado el compromiso y recomendando actuar en caso de haber instalado las versiones afectadas. Axios tiene más de 100 millones de descargas semanales en npm. La empresa de seguridad Huntress detectó los primeros sistemas comprometidos a los 89 segundos de publicarse la versión maliciosa, a través de pipelines automatizados de CI/CD.
Así que aunque Claude Code se libró por su arquitectura, el ataque a axios fue serio y afectó a mucha gente.
Los repos clonados son el verdadero peligro
Aquí es donde la cosa se tuerce.
En las horas siguientes a la filtración, aparecieron docenas de repositorios con el código de Claude Code. Algunos eran copias directas. Otros eran reescrituras en Python o Rust. El más conocido es claw-code, creado por un desarrollador coreano llamado Sigrid Jin, que reescribió el código en Python antes del amanecer para esquivar los DMCAs. El repo consiguió 50.000 stars en dos horas, convirtiéndose en el repositorio con crecimiento más rápido en la historia de GitHub.
Otros repos iban más allá. Algunos decían haber eliminado la telemetría, desbloqueado funcionalidades experimentales ocultas tras feature flags, o directamente haber quitado las restricciones de seguridad. Y la gente los estaba instalando.
La pregunta que me hago es: ¿quién ha auditado ese código?
Estamos hablando de herramientas que tienen acceso a bash, que pueden leer y escribir archivos en tu sistema, que ejecutan comandos de forma autónoma. Si alguien mete código malicioso dentro de uno de esos repos reescritos, tiene acceso directo a tu máquina. Y tú no lo vas a detectar porque no estás revisando 500.000 líneas de código ajeno antes de hacer un npm install.
El patrón que ya conocemos
No es que sea algo nuevo. Este patrón lo hemos visto antes.
El caso más conocido es el backdoor de xz-utils en 2024. Un atacante pasó dos años ganándose la confianza de la comunidad open source como mantenedor de una librería de compresión que usan prácticamente todos los sistemas Linux. Cuando tuvo suficientes permisos, inyectó código malicioso que permitía acceso root a cualquier servidor que usara esa librería. Se descubrió por casualidad, literalmente porque un ingeniero de Microsoft notó que sus logins SSH tardaban medio segundo más de lo normal.
Hace poco, Veritasium publicó un vídeo explicando en detalle cómo funcionó ese ataque y cómo estuvo a punto de comprometer internet entera. Lo explica bastante bien para cualquiera, no hace falta ser técnico para entender la gravedad de lo que pasó:
El paralelismo con lo que está pasando ahora es directo. Tienes repositorios que se han reescrito con IA de la noche a la mañana, mantenidos por gente que no conoces, con código que no has revisado, y que van a tener acceso a ejecutar comandos en tu sistema operativo. Si alguien quiere colar un backdoor, el escenario perfecto ya está montado.
Por qué ejecuto mis agentes en contenedores
Después de años trabajando con agentes de IA para desarrollo, hay algo que tengo claro: nunca ejecuto un agente directamente en mi máquina host.
Todos mis agentes corren dentro de contenedores Docker, en mi caso a través de DDEV. Tienen acceso solo a los volúmenes que yo monto explícitamente. No pueden tocar el resto de mi filesystem, no tienen acceso a mis claves SSH, no pueden leer mis variables de entorno del host, no pueden instalar cosas fuera de su sandbox.
¿Es más trabajo de configurar? Sí. ¿Añade una capa de complejidad? También. Pero la alternativa es darle a una herramienta que ejecuta bash de forma autónoma acceso completo a tu sistema. Y después de lo que hemos visto esta semana, creo que queda bastante claro por qué eso es una mala idea.
Mi recomendación es sencilla: si usas Claude Code, OpenCode, Codex o cualquier otro agente de código, ejecútalo dentro de un contenedor. Docker, DDEV, Podman, lo que prefieras. No tiene que ser complicado. La capa de aislamiento que te da un contenedor puede ser la diferencia entre un susto y un desastre.
Y por supuesto, no te instales repos random de gente que no conoces. Menos aún si esos repos pueden ejecutar comandos en tu sistema de forma autónoma.
Reflexión final
Lo que me genera una mezcla de preocupación e ironía es que Anthropic, la empresa que se vende como el laboratorio de IA que prioriza la seguridad, no ha sabido proteger su propio código fuente. Y esta es la segunda filtración de datos en menos de una semana, porque hace pocos días también se hicieron públicos documentos internos sobre un modelo que aún no han lanzado.
Pero más allá de señalar a Anthropic, lo que me preocupa de verdad es la tendencia. Cada vez vamos a ver más herramientas con acceso profundo a nuestros sistemas, más repos que prometen versiones "mejoradas" o "desbloqueadas" de productos comerciales, y más ataques a la cadena de suministro como el de axios.
Por experiencia te puedo decir que la seguridad no es algo que puedas añadir después. Hay que diseñar tu entorno de trabajo asumiendo que en algún momento algo va a fallar. Los contenedores no son la solución a todos los problemas, pero son una barrera que cuesta poco montar y que te va a ahorrar más de un disgusto.
PS: Si te interesa montar un setup con agentes de IA en contenedores DDEV, estoy preparando un artículo técnico detallado sobre mi configuración. Sígueme para no perdértelo.