BLOG
¿Una sola petición puede tirar tu servidor? Por qué no puedes ignorar las vulnerabilidades de Multer
Si alguna vez has implementado subida de archivos en Node.js/Express, casi seguro que has usado Multer. Resulta que en su rama 1.x se publicaron 7 vulnerabilidades HIGH entre 2025 y 2026, todas corregidas en la 2.x. Aquí te lo explico con analogías cotidianas.
Ese multer que sacas siempre que tocas subida de imágenes. Pues bien: desde 2025 se han publicado 7 vulnerabilidades HIGH severity una detrás de otra contra él. “Vulnerabilidades… eso suena complicado”, quizás pienses, pero si las dejas correr, tu servicio podría dejar de funcionar de repente un día cualquiera.
En este artículo, dirigido a personas que están dando sus primeros pasos como ingenieras de software, explico desde qué hace Multer hasta cuál es la verdadera naturaleza de estos fallos y cómo aplicar una solución que te llevará cinco minutos.

① ¿Qué hace Multer en realidad?
Si has implementado alguna vez subida de archivos en Express, has tocado multer sí o sí. Pero si te preguntan a bocajarro “¿qué problema resuelve exactamente?”, a lo mejor te cuesta responder.
Cuando el navegador envía datos mediante <input type="file">, llegan dentro de la petición HTTP como un bloque enorme de texto. El formato es Content-Type: multipart/form-data, una codificación peculiar donde varios archivos y campos del formulario van concatenados.
En ese estado Node.js no puede tratarlos como ficheros. Multer es la “administrativa de clasificación” que coge ese mazo de papeles, separa imágenes y PDFs, los guarda en disco y te los entrega bien ordenaditos en req.file / req.files.

import multer from "multer";
const upload = multer({ dest: "uploads/" });
app.post("/upload", upload.single("photo"), (req, res) => {
// req.file ya tiene la ruta donde se guardó y los metadatos del archivo
res.json({ saved: req.file.path });
});
Con apenas unas líneas tienes la subida funcionando. Eso es porque la administrativa está clasificando papeles entre bambalinas.
② Las vulnerabilidades, contadas con una analogía
En condiciones normales la cosa va así:
Tú: “Oye, esta petición multipart, sepárame imágenes y texto y guárdalos.”
Administrativa (Multer): “Hecho, en 3 milisegundos.”
Lo que cuentan estas CVEs es que se han descubierto varias formas de mandar peticiones con la mala intención de hacer entrar en pánico a la administrativa.

Concretamente, si un atacante envía peticiones como…
- Documentos con nombres de campo vacíos → la administrativa colapsa → el proceso del servidor se cae entero (CVE-2025-48997)
- Repetir muchísimas veces la acción de cortar la conexión a mitad de subida → la administrativa no consigue recoger los papeles a medio hacer → la memoria y los descriptores de fichero se agotan (CVE-2025-47935, CVE-2026-2359)
- Mandar documentos con anidación anormalmente profunda → la administrativa entra en un “infierno de pasar páginas” hasta que la mesa entera sale volando (desbordamiento de pila por recursión, CVE-2026-3520)
Es decir, hablamos sobre todo de vulnerabilidades del tipo “el servicio se para por completo” (DoS, Denial of Service), no del tipo “te roban los datos”. Algunas tumban el proceso de Node.js con una sola petición maliciosa.
③ El impacto: la caída duele más que la fuga, en la práctica
“Bueno, si no se filtran datos, ¿qué más da?”, podrías pensar. Pero en el día a día esta otra modalidad suele ser la peor.
- El servidor se cae a las 2 de la madrugada → salta la alerta de monitorización → sacan a alguien del equipo de la cama
- Cero ingresos mientras el servicio está caído → en un e-commerce, una hora de caída se traduce en decenas de miles de yenes evaporados
- Limpieza posterior → disculpas a clientes, investigación de la causa, redacción del postmortem
- Ataques pequeños y repetidos que agotan la memoria → todo se va volviendo lento y nadie sabe de quién es la culpa, mientras el equipo se desgasta
Dicho de otra forma: dejar las vulnerabilidades sin parchear eleva las probabilidades de que un día te despierten en plena noche. Y eso da bastante miedo.
④ Las 7 vulnerabilidades publicadas (fuentes primarias)
Para tu referencia, dejo aquí en orden cronológico todas las vulnerabilidades HIGH severity de Multer publicadas entre 2025 y 2026. Todos los enlaces apuntan a GitHub Security Advisory (la fuente primaria).
| Publicada | CVE | Tipo | Versiones afectadas | Corregida en |
|---|---|---|---|---|
| 2025-05-19 | CVE-2025-47944 | Crash por excepción no manejada | <2.0.0 | 2.0.0 |
| 2025-05-19 | CVE-2025-47935 | Fuga de memoria / FD | <2.0.0 | 2.0.0 |
| 2025-06-03 | CVE-2025-48997 | Crash por nombre de campo vacío | <2.0.1 | 2.0.1 |
| 2025-07-17 | CVE-2025-7338 | Crash por petición malformada | <2.0.2 | 2.0.2 |
| 2026-02-27 | CVE-2026-2359 | Recursos no liberados al desconectar | <2.1.0 | 2.1.0 |
| 2026-02-27 | CVE-2026-3304 | Limpieza incompleta | <2.1.0 | 2.1.0 |
| 2026-03-04 | CVE-2026-3520 | Recursión descontrolada por anidación profunda | <2.1.1 | 2.1.1 |
Las puntuaciones CVSS se mueven más o menos entre 7.5 y 8.7 (HIGH). Toda la rama multer 1.x (incluido 1.4.5-lts.2) puede considerarse, sin matices, completamente comprometida.
⑤ La solución: tres pasos para salvar tu código
Esto te lleva cinco minutos.
Paso 1. Comprueba en qué versión estás
npm ls multer
# o
cat package.json | grep multer
Si estás en 1.x (incluido 1.4.x), te toca.
Paso 2. Actualiza al último 2.x
npm install multer@latest
# con pnpm
pnpm add multer@latest
# con yarn
yarn add multer@latest
Con esto te queda instalada la multer@2.1.1 o superior (al momento de escribir esto).
Paso 3. Comprueba que sigue funcionando tras actualizar
La API de Multer 1.x → 2.x es compatible en lo esencial, pero hay algunos cambios:
multer.diskStorage/multer.memoryStoragesiguen funcionando igual- Se han eliminado algunos callbacks que estaban deprecated
- El manejo de errores de los file filters se volvió un pelín más estricto
Lanza un smoke test rápido y tu suite de pruebas existente. Si no salta nada, listo:
npm audit
# lo ideal es ver "found 0 vulnerabilities"
Si tienes Dependabot activado en tu repositorio de GitHub, abrirá automáticamente PRs cuando se publiquen avisos como estos. Si aún no lo has activado, esa es tu siguiente tarea.
Cierre
Una vulnerabilidad no es culpa de nadie. Quienes mantienen software libre también son personas, y las técnicas de ataque evolucionan cada día. Lo importante es incorporar a tu proyecto la operación de “absorber actualizaciones de upstream con regularidad”. Esa costumbre es muchas veces la línea que separa a una persona en sus inicios de una ingeniera profesional.
Un único npm install multer@latest baja claramente las probabilidades de que te llamen a las 3 de la madrugada. Abre package.json ahora mismo.
Refs (fuentes primarias):