Si has pasado algún tiempo en el mundo de JavaScript, has tocado axios. Es la configuración predeterminada para las solicitudes HTTP en Node.js. Es tan común que, por lo general, lo tratamos como parte del lenguaje en sí. Sin embargo, hace unas semanas, la industria entró en una crisis colectiva. Los titulares empezaron a hablar de una vulnerabilidad crítica de 10/10 en Axios, la CVE-2026-40175, que supuestamente permitía a los atacantes eludir la seguridad de AWS y robar las credenciales de la nube.

En Sweent, lo primero que hacemos cuando cae un «10/10» es iniciar una auditoría de toda la cartera. Ya sea que nos dediquemos a gestionar los paneles empresariales o a modernizar las pilas de aplicaciones antiguas, no esperamos a que las alertas automatizadas nos indiquen que se está produciendo un incendio. Empezamos a buscar el humo nosotros mismos. Pero a medida que investigábamos esta vulnerabilidad específica, descubrimos algo que los titulares sensacionalistas pasaban por alto: para la mayoría de las aplicaciones modernas, el exploit estaba listo al llegar.

La anatomía del susto

La vulnerabilidad se describió como una «cadena de artilugios». Si no está familiarizado con el término, considérelo como una máquina de Rube Goldberg para piratas informáticos. Es necesario que varias cosas diferentes salgan mal en un orden específico para que ocurra la explosión final.

En teoría, la cadena tenía este aspecto:

• Un atacante encuentra la manera de provocar la contaminación de un prototipo en su aplicación.

• Axios recoge esos valores contaminados al fusionar su configuración interna.

• Estos valores incluyen los caracteres CRLF (Carriage Return Line Feed) insertados en los encabezados.

• Estos encabezados engañan al servidor para que haga «contrabando de solicitudes» o falsifique solicitudes desde el servidor (SSRF).

• El atacante usa ese SSRF para acceder al servicio de metadatos de instancias de AWS (IMDSv2) y quedarse con sus credenciales en la nube.

• Sobre el papel, es un escenario de pesadilla. Si un atacante puede llegar al 169.254.169.254 desde dentro de su red, es dueño de su infraestructura. Pero he aquí el truco: la teoría y la producción son dos ámbitos muy diferentes.

• Por qué es probable que tu tiempo de ejecución te haya salvado Al realizar nuestra auditoría, nos dimos cuenta de que la primitiva principal en la que se basa este exploit (la inyección de encabezados CRLF) es algo que Node.js ha estado bloqueando durante años a nivel de ejecución. Axios no envía bytes por cable en sí, sino que usa el módulo http integrado en Node.js. Cuando intentamos reproducir el exploit en un entorno estándar, no parábamos de chocar contra una pared. En concreto, un TypeError [ERR_INVALID_CHAR] . Si intentas pasar un valor de encabezado con un carácter de nueva línea a http.request () , Node.js generará un error incluso antes de que la solicitud abandone tu servidor. No importa qué tan «contaminada» esté tu configuración de Axios si el motor subyacente se niega a funcionar. Lo comprobamos y las mismas protecciones existen en Bun y Deno. Es un caso clásico en el que la biblioteca es técnicamente vulnerable pero el entorno es seguro. Incluso analizamos los hallazgos de investigadores como Raúl Vega Del Valle. Su trabajo confirmó lo que veíamos en nuestros laboratorios: en las aplicaciones de producción del mundo real, es casi imposible acceder a esta cadena porque el intérprete la detiene. Entonces, ¿por qué la calificación de 10/10? Porque las puntuaciones de CVE dan por sentado que se trata del peor entorno posible, no de un clúster de Node 20.x bien parcheado.

La auditoría de Sweent

Más allá del escaneo automático, quizás se pregunte por qué nos hemos molestado en aplicar parches si el tiempo de ejecución bloquea el exploit. La respuesta es sencilla: no apostamos por la seguridad por una sola capa de defensa. Confiar en Node.js para detectar el error de una biblioteca es un mal hábito. Nuestro equipo revisó manualmente los archivos package-lock.json y yarn.lock de todos los proyectos activos. No nos limitamos a buscar el número de versión de axios. Analizamos cómo interactuaba realmente el código con la red. Las herramientas automatizadas como el Dependabot son geniales, pero no entienden el contexto. No saben si has creado un adaptador personalizado que pueda eludir esas protecciones de nodo integradas.

• Hemos comprobado si hay adaptadores personalizados. Si una aplicación usa un adaptador Axios personalizado que omite el cliente http de Node.js (quizás para escribir solicitudes sin procesar directamente en los sockets), la protección del tiempo de ejecución desaparece.

• Buscamos los riesgos de contaminación de los prototipos. Si tu aplicación es vulnerable a la contaminación de los prototipos, tienes problemas mucho mayores que un simple error de Axios. Hemos auditado la forma en que gestionamos la fusión de JSON.parse y de objetos en general.

• Verificamos nuestras configuraciones de AWS. Incluso si se produjera una SSRF, nos aseguramos de que nuestros proyectos utilicen IMDSv2 con límites de saltos estrictos. Esto hace que el robo de credenciales sea mucho más difícil, incluso con una inyección exitosa.

• Hemos visto cómo se construyen los encabezados. Buscamos cualquier lugar en el que la entrada del usuario pudiera tocar un encabezado, una tecla o un valor sin necesidad de desinfectarlos.

Durante este período de 24 horas, trasladamos todos los proyectos a Axios 1.15.0 o superior. Hemos visto cómo la «fatiga de alerta» ha destruido a los equipos de desarrollo. Reciben cien notificaciones a la semana, la mayoría de ellas relacionadas con dependencias de desarrollo de bajo riesgo, y comienzan a ignorarlas. Tratamos la seguridad como una tarea de ingeniería manual de alta prioridad para que el ruido no ahogue la señal.

La confusa realidad de la cadena de suministro

Este CVE se produjo inmediatamente después de otro incidente de Axios, mucho más aterrador: el secuestro de una cuenta de mantenedor que, de hecho, desplegó un troyano de acceso remoto (RAT). Fue un verdadero ataque a la cadena de suministro. No se trataba de una «cadena de dispositivos» que necesitara cuatro coincidencias para funcionar, sino de código malicioso que se ejecutaba durante el proceso de creación.

La comparación de ambos pone de manifiesto un problema importante en la ingeniería moderna. La industria tiende a reaccionar de forma exagerada ante los errores teóricos de nivel bibliotecario, mientras que no reacciona de forma exagerada ante los problemas de contabilidad. Pasamos más tiempo hablando de una SSRF teórica que del hecho de que un responsable principal de mantenimiento no tuviera habilitada la autenticación de dos factores en su cuenta de npm.

Mantener la diferencia entre la versión instalada y la última versión parcheada tan pequeña como sea posible es la única forma de mantener la cordura. Pero no puedes ejecutar npm update a ciegas. Hemos visto actualizaciones «menores» que rompen los encabezados de producción o cambian la forma en que se gestionan los tiempos de espera. Por eso, nuestras canalizaciones de CI/CD incluyen pruebas de regresión y puertas de seguridad. Si una actualización no supera una prueba de una sola unidad, no avanza.

¿Cuándo un error «crítico» no es crítico?

La calificación de «10/10» de este CVE se basó en el peor escenario posible. Si asumes que un atacante ya ha puesto en peligro el prototipo de tu aplicación, que estás utilizando una pila de red personalizada poco común y que los metadatos de tu nube están abiertos de par en par, entonces sí, es un 10. ¿Pero para el desarrollador promedio? Es un recordatorio para mantener limpias tus dependencias.

Nos hemos hecho cargo de proyectos antiguos en los que el package.json no se ha utilizado desde 2022. Esa es una enorme carga. Cada paquete anticuado es una puerta que se deja abierta. Nos esforzamos por educar a nuestros socios sobre por qué son importantes estas auditorías. No se trata de seguir todos los titulares; se trata de saber exactamente qué código se está ejecutando en su entorno de producción y por qué.

Y seamos honestos: Axios se está exagerando. Es una gran herramienta, pero tiene mucho peso heredado para ser compatible con navegadores y versiones de Node antiguas. A veces, la mejor solución de seguridad no es un parche, sino cambiar a la API nativa fetch si estás usando un entorno de ejecución de Node moderno. Tiene menos funciones, pero también tiene una superficie de ataque mucho más pequeña.

Nuestra comida para llevar

La seguridad no es una función de «configúrala y olvídate». Es un proceso constante de verificación. Nos complace informar de que todos nuestros sistemas internos y plataformas gestionadas fueron parcheados y verificados pocas horas después de la divulgación, a pesar de la baja probabilidad de que se exploten realmente.

No aplicamos los parches simplemente porque las noticias nos decían que lo hiciéramos. Hicimos un parche porque la biblioteca en sí misma no debería permitir valores inseguros, incluso si el tiempo de ejecución los detecta. Se trata de una defensa en profundidad. Si la primera línea de defensa (Axios) falla, la segunda línea (Node.js) la atrapa. Si la segunda falla, la tercera (AWS IMDSv2) bloquea el premio. Así es como se crean sistemas que no se estropean cuando una biblioteca tiene una mala semana.

Si te preocupa tu propio árbol de dependencias o si no estás seguro de si tu equipo actual está captando estos matices, probablemente deberías revisar tu package-lock.json ahora mismo. ¿Confías en un bot para que te avise cuando corres un riesgo o tienes un equipo que realmente entiende el tiempo de ejecución?