El 31 de marzo de 2026, un único archivo mal configurado expuso públicamente 512 000 líneas del código fuente propietario de Anthropic. No hubo ningún hackeo ni ataque sofisticado, solo un error en la configuración de compilación. Eso fue lo que bastó para que el código interno de Claude Code estuviera al alcance de cualquier persona con una cuenta de npm.
Si utilizas desarrollo de software asistido por IA en cualquier área de tu empresa, este incidente te revela algo sumamente importante. No se trata de Anthropic, sino de lo que tu propio proceso de desarrollo podría estar exponiendo silenciosamente en este momento. Hoy hablaremos sobre cómo comprender y minimizar estos nuevos riesgos.
¿Qué sucedió realmente con la filtración del código de Claude?
Aquí un breve resumen: Anthropic distribuye Claude Code como un paquete npm cerrado y ofuscado. El 30 de marzo de 2026, lanzaron la versión 2.1.88, y dentro de ese paquete se encontraba un archivo de mapa de origen, cli.js.map, que apuntaba al código fuente completo y sin ofuscar de TypeScript.
El investigador de seguridad Chaofan Shou fue el primero en alertar públicamente sobre el problema el 31 de marzo, al descubrir que todo el código fuente de Claude Code había quedado expuesto a través de un archivo de mapa de origen publicado en el registro de npm. En cuestión de horas, el código se archivó en GitHub y se distribuyó por internet.
El código fuente filtrado constaba de casi 2000 archivos TypeScript y más de 512 000 líneas de código. El repositorio de GitHub donde se realizó la copia de seguridad superó las 84 000 estrellas y las 82 000 bifurcaciones.
Anthropic confirmó el incidente: un portavoz declaró a The Register que se trató de “un problema con el embalaje del producto causado por un error humano, no de una brecha de seguridad”, y que no se vieron afectados datos ni credenciales de clientes.
Esa es una consecuencia clásica del error humano y una de las muchas razones por las que los desarrolladores utilizan la automatización hoy en día. Sin embargo, ¿habría ayudado a prevenir este problema la automatización completa del proceso de lanzamiento? Analicemos en detalle esta filtración de código de Claude y sus implicaciones para la automatización y el desarrollo de IA a gran escala.
Mecanismos técnicos: Por qué la filtración del código de Claude fue tan fácil de pasar por alto
Si no eres desarrollador, aquí tienes una breve explicación de cómo pueden ocurrir estas cosas. Cuando los ingenieros crean aplicaciones JavaScript o TypeScript, el código se empaqueta y minimiza intencionadamente (se comprime hasta que sea casi ilegible). Los archivos de mapa de origen son herramientas de depuración que revierten este proceso. Es decir, mapean la salida minimizada al código fuente original. Esto resulta muy útil en tu máquina, pero se convierte en un problema en producción.
Según el análisis del código fuente expuesto de Claude Code, la filtración se produjo a partir de una referencia a un código fuente TypeScript sin ofuscar en el archivo de mapa incluido en el paquete npm.
Un único archivo .npmignore o un campo files mal configurado en package.json puede dejarlo todo al descubierto.
Basta con un solo archivo o una exclusión omitida para meterse en un buen lío. En el caso de Anthropic, la cadena de herramientas de compilación (al parecer Bun) generó mapas de origen que no se excluyeron del artefacto publicado, por lo que la configuración de .npmignore no los tuvo en cuenta. Imagínelo así: es como imprimir su hoja de ruta interna en la parte posterior de cada producto que lanza. El producto funciona bien, pero cualquiera que lo revise ahora lo sabrá todo.
Esto es lo que hace que la filtración de código de Claude sea tan instructiva para los equipos de ingeniería. El fallo no se debió a una combinación extrema e inusual de factores, sino más bien a algo que ocurre en cualquier equipo que trabaja a un ritmo acelerado y realiza entregas con frecuencia. La única forma fiable de detectar problemas similares es implementar las comprobaciones adecuadas antes de la publicación, no después.
¿Qué contenía el código filtrado de Claude?
La filtración contenía la propiedad intelectual y la hoja de ruta interna de Anthropic, prácticamente en su totalidad. Esto es lo que la comunidad encontró dentro de esos 1906 archivos TypeScript:
Arquitectura y herramientas:
- Una arquitectura de herramientas basada en complementos con aproximadamente 40 herramientas discretas (lectura de archivos, ejecución de bash, integración de LSP), cada una con control de permisos.
- Un motor de consultas de 46.000 líneas que gestiona todas las llamadas a la API de LLM, la transmisión de datos, el almacenamiento en caché y los bucles de llamadas a herramientas.
- Lógica de orquestación multiagente que anteriormente no estaba documentada.
Características no publicadas:
- Una función llamada KAIROS, un agente persistente en segundo plano que puede corregir errores periódicamente o ejecutar tareas de forma autónoma, enviando notificaciones push sin esperar la intervención del usuario. Complementando esto, existe un modo “sueño” que permite a Claude desarrollar ideas continuamente en segundo plano.
- Una mascota de compañía al estilo Tamagotchi (una especie determinista basada en el hash de tu ID de usuario), cuyo lanzamiento interno está previsto para abril de 2026, con un lanzamiento completo planeado para mayo de 2026.
Además, el “Modo Encubierto” revelado en el código filtrado muestra que Anthropic utiliza Claude Code para realizar contribuciones encubiertas a repositorios públicos de código abierto. El mensaje del sistema para este modo dice: “Estás operando de forma encubierta en un repositorio PÚBLICO/DE CÓDIGO ABIERTO. Tus mensajes de confirmación, títulos de solicitudes de extracción y cuerpos de solicitudes de extracción NO DEBEN contener NINGUNA información interna de Anthropic. No reveles tu identidad.”
Este detalle, en particular, generó la mayor controversia en la comunidad de desarrolladores, ya que representa un agente de IA operando de incógnito en repositorios públicos, según su diseño. Independientemente de si esto resulta preocupante o no, lo importante es que esta información nunca estuvo destinada a ser pública. Sin embargo, ahora ha quedado grabada para siempre en la memoria de internet.
Además, la filtración del código de Claude reveló detalles internos sobre el rendimiento del modelo. El código confirma que Capybara es el nombre en clave interno de una variante de Claude 4.6, y los desarrolladores observaron una tasa de falsas reclamaciones del 29-30% en la versión 8, lo que representa una regresión real en comparación con la tasa del 16,7% observada en la versión 4. Los desarrolladores también señalaron un “contrapeso de asertividad” diseñado para evitar que el modelo se vuelva demasiado agresivo en sus refactorizaciones. Para la competencia, esto supone un nuevo referente, y para los investigadores de seguridad, es un mapa de dónde se encuentran las medidas de seguridad y cómo funcionan.
La mayor amenaza: el ataque a la cadena de suministro de Axios
Aquí es donde la situación se torna más seria para tu equipo. La filtración del código Claude fue embarazosa para Anthropic, pero no representó una brecha de seguridad directa para los usuarios. Sin embargo, el ataque simultáneo de Axios sí constituyó una amenaza de alto nivel.
Entre el 30 y el 31 de marzo de 2026, el paquete npm Axios fue comprometido en uno de los ataques más importantes a la cadena de suministro de npm hasta la fecha. Con más de 100 millones de descargas semanales, Axios es un cliente HTTP fundamental utilizado en todo el ecosistema de JavaScript. Un atacante secuestró la cuenta npm del principal responsable del mantenimiento y publicó dos versiones maliciosas que desplegaban un troyano de acceso remoto (RAT) multiplataforma en cualquier máquina que ejecutara `npm install`.
Los usuarios que instalaron o actualizaron Claude Code a través de npm el 31 de marzo de 2026, entre las 00:21 y las 03:29 UTC, podrían haber instalado inadvertidamente una versión maliciosa de axios (1.14.1 o 0.30.4) que contiene un troyano de acceso remoto. Se recomienda a los usuarios que busquen inmediatamente estas versiones específicas o la dependencia plain-crypto-js en los archivos de bloqueo del proyecto.
El equipo de inteligencia de amenazas de Microsoft atribuyó la vulneración de Axios npm a Sapphire Sleet, un grupo estatal norcoreano. No se trató de un ataque oportunista, sino de un ataque dirigido, programado y diseñado para lograr el máximo impacto.
El ataque funcionó porque explotó una vulnerabilidad de confianza presente en casi todos los proyectos modernos de JavaScript: el atacante utilizó un token de acceso npm robado y de larga duración para publicar directamente en el registro npm, eludiendo por completo los procesos de CI/CD. Las versiones legítimas de Axios incluyen metadatos de procedencia OIDC que vinculan el paquete npm con una ejecución específica de GitHub Actions. Las versiones maliciosas carecían de esto, ya que se publicaron directamente, sin dejar rastro de compilación verificable. La mayoría de los equipos no se habrían percatado de que algo andaba mal.
Lo que ambos incidentes revelan sobre su oleoducto
Dos incidentes distintos el mismo día, con el mismo ecosistema de paquetes. Esto no es una coincidencia, sino un patrón. Y apunta a una serie de riesgos estructurales que existen en la mayoría de los flujos de trabajo de desarrollo modernos.
- Fuga de artefactos de construcción
La mayoría de los equipos nunca ejecutan `npm pack –dry-run` antes de publicar. Confían en que la cadena de herramientas de compilación haga lo correcto. El equipo de Anthropic también lo hizo, de ahí la filtración de código de Claude. Mapas de origen, configuraciones internas, archivos `.env.example` con valores que parecen reales: todo esto puede terminar en un paquete publicado sin que nadie se dé cuenta. - Ceguera ante la dependencia de terceros
El análisis de los ataques ocurridos entre 2025 y 2026 revela un patrón constante: los atacantes obtienen acceso inicial mediante credenciales comprometidas, y la misma cadena de ataque se repite. Los responsables del mantenimiento son víctimas de phishing, se abusa de las credenciales y el código malicioso persiste durante demasiado tiempo antes de que alguien lo detecte. Casualmente, Claude Code utilizaba Axios, y probablemente tu aplicación también. - Dependencia excesiva de las instalaciones automatizadas
Para la mayoría de los equipos, ejecutar `npm install` en una canalización de CI/CD sin verificar la procedencia, fijar la versión ni realizar el seguimiento del SBOM es la práctica habitual. Además, así es como un RAT (troyano de acceso remoto) termina en la máquina de un desarrollador sin que este haga clic en ningún momento. - Puertas de publicación faltantes
La lección que nos deja la filtración de Claude Code es clara: .npmignore soporta una carga. Hay que tratarlo como una barrera de seguridad. La mayoría de los equipos de ingeniería no tienen un paso de revisión formal entre la compilación y la publicación. Es ahí donde se producen estos incidentes.
Esto no es del todo hipotético; por ejemplo, en septiembre de 2025, unos atacantes secuestraron 18 paquetes populares de npm que, en conjunto, se descargaban más de 2 mil millones de veces a la semana. Estos ataques se producen a gran escala y afectan a equipos reales.
Qué debe hacer ahora tu equipo
Esto es lo que debería abarcar una revisión de su cartera de proyectos, teniendo en cuenta lo que quedó al descubierto el 31 de marzo:
Revisa tu configuración de publicación de npm antes de tu próximo lanzamiento. Ejecuta npm pack –dry-run e inspecciona cada archivo que se distribuirá. Busca:
- Cualquier archivo .map en dist/
- Directorios de origen incluidos accidentalmente
- Archivos de configuración con rutas internas o tokens
Marca tu archivo .npmignore como un límite de seguridad e inclúyelo en cada lista de verificación de lanzamiento.
Para proteger tus dependencias críticas, elimina el símbolo de intercalación (^) y la tilde (~) del archivo package.json para bibliotecas como Axios, que se encuentran en niveles profundos de tu árbol de dependencias. Microsoft recomienda deshabilitar las funciones de actualización automática para los paquetes npm en organizaciones donde la postura de seguridad requiere una revisión antes de la implementación.
Compruebe sus archivos de bloqueo ahora mismo si usted o su equipo ejecutaron npm install el 31 de marzo de 2026, entre las 00:21 y las 03:29 UTC, busque en sus archivos de bloqueo inmediatamente:
grep -r "1.14.1\|0.30.4\|plain-crypto-js" package-lock.jsonSe requiere que npm publique comprobaciones de procedencia y SLSA nivel 2 o superior para todos los paquetes internos y de terceros críticos. La ausencia de procedencia OIDC en una nueva versión de un paquete principal debería activar una alerta automática. La mayoría de los equipos no lo han configurado, pero es porque aún no lo han necesitado.
Agregue un paso de revisión de publicación a su canalización de CI/CD para cada lanzamiento. Integre un paso de inspección de artefactos previo a la publicación que verifique los mapas de origen, las URL de depuración y las directivas sourceMappingURL en su salida distribuida final.
Revisa el uso de tu herramienta de codificación de IA en entornos sensibles y adopta una postura de confianza cero al usar Claude Code en entornos desconocidos. Evita ejecutar el agente dentro de repositorios recién clonados o no confiables hasta que hayas inspeccionado manualmente .claude/config.json y cualquier hook personalizado. La misma lógica se aplica a cualquier herramienta de IA con acceso al sistema de archivos y a la línea de comandos. Esto lo explicamos en detalle en nuestro artículo sobre las mejores prácticas de seguridad de OpenClaw.
La pregunta más amplia: ¿Cuánto sabes sobre tu cartera de clientes?
La mayoría de los fundadores y líderes de ingeniería pueden describir la arquitectura de su producto en detalle. Sin embargo, pocos pueden describir con la misma seguridad qué implementa exactamente su canalización de CI/CD, en qué dependencias confía automáticamente y qué podría poner un atacante con un token npm comprometido a disposición de sus desarrolladores mañana.
La clave para prevenir incidentes como la filtración de código de Claude reside en implementar procesos de revisión adecuados que permitan lanzar productos rápidamente sin riesgos ocultos. Una auditoría de software profesional, que abarque la configuración de compilación, la cadena de dependencias, el pipeline de CI/CD y el proceso de publicación, lleva días, no semanas. El incidente de Anthropic se desarrolló en cuestión de horas, mientras que la ventana de ataque de Axios fue de tan solo 39 minutos.
Si utiliza herramientas de desarrollo asistidas por IA y desea garantizar que el flujo de trabajo que las rodea sea seguro y esté debidamente gestionado, ese es precisamente el tipo de trabajo que Redwerk lleva realizando para empresas tecnológicas desde 2005. Nuestro servicio de revisión de código incluye la configuración de compilaciones y dependencias, y nuestra consultoría DevOps abarca el fortalecimiento de CI/CD, lo que reduce considerablemente la probabilidad de que incidentes como estos afecten a su equipo.
La filtración de Claude Code se produjo debido a un único archivo mal configurado. El ataque a Axios tuvo éxito gracias a una cuenta comprometida y un token npm sin restricciones. Ambos son fallos menores, propios de procesos, que los equipos más experimentados suelen pasar por alto hasta que se vuelven incontrolables.
Lo que realmente reveló el 31 de marzo no es que Anthropic cometiera un error, sino que el flujo de trabajo de desarrollo de JavaScript moderno, con sus complejos árboles de dependencias, instalaciones automatizadas y registros de paquetes que confían por defecto, está mucho más expuesto de lo que la mayoría de los equipos se imaginan. Y cuanto más rápido se lance el producto, mayor será la probabilidad de que exista alguna de estas vulnerabilidades entre el código y los usuarios. Si desea prevenir esto en su flujo de trabajo, contáctenos y juntos solucionaremos cualquier problema de seguridad.
Check out how we helped Complete Network's Project Science boost code maintainability by 80%
