Un prototipo contaminado puede secuestrar su tráfico de axios. Actualice a 1.18.0.

El 1 de agosto, los mantenedores de axios divulgaron CVE-2026-67320, una debilidad de contaminación de prototipos en el adaptador HTTP de Node.js de la librería. axios es uno de los paquetes más instalados en npm, por lo que este problema afecta a muchos backends. En resumen: bajo las condiciones adecuadas, un atacante que pueda contaminar Object.prototype puede hacer que su servidor enrute sus peticiones HTTP salientes a través de un proxy que controla. Para llamadas en texto plano http://, ese proxy puede leer la cabecera Authorization, las credenciales de autenticación básica, el método, la URL completa, la cabecera Host y el cuerpo de la petición, y luego devolver una respuesta a su elección. NVD lo puntuó con 8,3 (Alto) en CVSS 4.0.

Aquí está el mecanismo, porque los detalles importan. axios refuerza su configuración de petición fusionada construyéndola sobre un objeto de prototipo nulo, para que las propiedades heredadas no puedan filtrarse. Pero los interceptores de petición se ejecutan después de esa fusión, y un patrón de interceptor muy común, return { ...config } o Object.assign({}, config), convierte silenciosamente ese objeto reforzado de nuevo en uno ordinario con Object.prototype en su cadena. El adaptador de Node lee entonces config.proxy de ese objeto, recorre la cadena de prototipos y encuentra lo que un atacante haya plantado en Object.prototype.proxy. La corrección en la versión 1.18.0 lee esos valores de configuración anidados a través de un accesor seguro que ignora las propiedades heredadas.

Una advertencia sincera: axios por sí solo no le ofrece esto a un atacante. Necesitan un fallo de contaminación de prototipos separado en algún lugar de su aplicación o en su árbol de dependencias para establecer Object.prototype.proxy en primer lugar. axios es el amplificador, no el punto de entrada. Eso es exactamente por qué vale la pena tomarlo en serio. Los gadgets de contaminación de prototipos son comunes en las bases de código JavaScript, y esto convierte un hallazgo que muchos equipos descartarían como teórico en una exfiltración de credenciales.

Vemos este patrón constantemente durante nuestras pruebas de penetración y revisiones de seguridad. El escáner de un cliente detecta un problema de contaminación de prototipos, alguien lo clasifica como «sin impacto real» y queda en el backlog durante un año. Luego llega un fallo como este y lo teórico se convierte en una línea directa hacia tokens filtrados. La contaminación de prototipos rara vez es el exploit completo. Es el primitivo que hace que el siguiente fallo sea mucho peor.

La acción inmediata es aburrida y debe hacerla hoy: actualice axios a la versión 1.18.0, o a 0.33.0 si todavía está en la rama 0.x. Todo lo que va desde 1.15.2 hasta 1.18.0, o desde 0.31.1 hasta 0.33.0, está afectado. Ejecute npm ls axios y le mostrará cada copia en su árbol, incluidas las transitivas que su propio código nunca importó. Esas copias transitivas son normalmente las que le traen problemas, porque nadie las está vigilando.

Luego vaya un paso más allá del parche. En nuestro trabajo con PHP y Docker para construir backends nativos en la nube, los equipos que gestionan estas divulgaciones con calma son los que ya tratan el tráfico saliente como algo a controlar, no solo el entrante. Algunas cosas que dan resultado aquí:

• Realice las llamadas de servidor a servidor siempre por https://. Este fallo no filtra nada a través de TLS correctamente validado. La llamada interna en texto plano http:// entre dos servicios es la que le traerá problemas.
• Controle el tráfico saliente. Si un servicio solo necesita llegar a tres hosts conocidos, una lista de permitidos de egreso o un proxy que usted mismo gestiona significa que un config.proxy comprometido no tiene a dónde ir.
• Mantenga los secretos fuera de las URLs y reduzca la vida útil de lo que envíe en Authorization en los saltos internos. Los tokens de corta duración limitan el daño cuando algo se filtra.

También hay un ángulo móvil, y es fácil pasarlo por alto. En nuestros proyectos nativos de iOS y Android, la propia aplicación no ejecuta axios, pero el backend-for-frontend o la API gateway que está detrás muy a menudo sí lo hace. Un token filtrado upstream puede comprometer silenciosamente a todos los clientes móviles downstream, y no lo verá en los propios registros de la aplicación. Cuando revisamos un sistema móvil, rastreamos el token hasta el final del backend, no solo hasta el primer salto.

La lección que subyace al CVE es la que vale la pena retener. Su árbol de dependencias es superficie de ataque, y «no usamos esa funcionalidad» no es lo mismo que «ese código no puede ejecutarse». axios tiene soporte de proxy que quizás nunca configure, y la vulnerabilidad vivía allí de todas formas. Saber qué está realmente instalado, y poder parchearlo en una tarde, es una capacidad que se construye antes de necesitarla, no durante un incidente.

Si no está seguro de lo que hay en su árbol de dependencias o de cómo sale el tráfico saliente de sus servicios, hablemos.