alta

CVE

CVE-2026-41840, CVE-2026-41842

CWE

CWE-400

Sistemas afectados

  • Módulos web de Spring Framework en las versiones 5.3.0-5.3.48, 6.1.0-6.1.27, 6.2.0-6.2.18 y 7.0.0-7.0.7
  • Consumidores de org.springframework:spring-webflux que exponen endpoints multipart/form-data
  • Consumidores de org.springframework:spring-webmvc y org.springframework:spring-webflux que sirven recursos estáticos versionados respaldados por el sistema de archivos
  • Aplicaciones Spring Boot que heredan las líneas afectadas de Spring Framework

Spring lanzó las versiones 7.0.8 y 6.2.19 el 8 de junio con un lote denso de correcciones de seguridad web, pero dos de ellas destacan para los equipos de aplicaciones del día a día porque se sitúan directamente en rutas de procesamiento de solicitudes fáciles de olvidar durante el modelado de amenazas:

  • CVE-2026-41840 es un problema de denegación de servicio en el multipart de WebFlux.
  • CVE-2026-41842 es un problema de denegación de servicio en los recursos estáticos de Spring MVC y WebFlux.

Ninguno de los dos fallos requiere una cadena de gadgets, una primitiva de deserialización ni un modelo de despliegue inusual. Si tu servicio acepta multipart/form-data, o si sirve archivos estáticos versionados desde el sistema de archivos, el tráfico HTTP ordinario puede convertirse en el desencadenante de agotamiento de recursos.

Qué está afectado

Los avisos de Spring describen el producto afectado como Spring Framework 5.3.0 hasta 5.3.48, 6.1.0 hasta 6.1.27, 6.2.0 hasta 6.2.18, y 7.0.0 hasta 7.0.7. Para los equipos de aplicaciones, la forma más útil de delimitar esto es por los módulos y funciones de Maven en uso:

CVESuperficie de paquete/proyectoCondición de disparoCorregido en
CVE-2026-41840Aplicaciones que usan Spring WebFlux, típicamente a través de org.springframework:spring-webflux y los codecs compartidos de org.springframework:spring-webLa aplicación expone un endpoint multipart y procesa cuerpos multipart controlados por el atacante7.0.8, 6.2.19, 6.1.28, 5.3.49
CVE-2026-41842Aplicaciones que usan el manejo de recursos estáticos de org.springframework:spring-webmvc o org.springframework:spring-webfluxLa aplicación sirve recursos estáticos desde el sistema de archivos y tiene habilitado el soporte de recursos versionados7.0.8, 6.2.19, 6.1.28, 5.3.49

Si consumes Spring a través de Spring Boot, la corrección práctica es pasar a una versión de Boot que incorpore esas versiones de Spring Framework o posteriores. La lógica vulnerable vive en la pila web del framework, así que revisar solo las dependencias directas no es suficiente.

Por qué importa CVE-2026-41840

El aviso de Spring mantiene la descripción deliberadamente breve: una solicitud multipart hostil puede filtrar memoria en WebFlux y eventualmente denegar el servicio. El diff de código fuente 7.0.7 -> 7.0.8 da más contexto sobre el modo de fallo. En DefaultPartHttpMessageReader, la ruta de error ahora vacía y libera los búferes del cuerpo antes de lanzar una excepción por exceso de límite en la entrada:

if (tooManyParts(partCount)) {
  return partsTokens
      .doOnNext(token -> {
        if (token instanceof MultipartParser.BodyToken bodyToken) {
          DataBufferUtils.release(bodyToken.buffer());
        }
      })
      .then(Mono.error(new DecodingException("Too many parts ...")));
}

Hay cambios de endurecimiento del ciclo de vida correspondientes en la ruta del analizador y generador multipart:

else {
  changeState(this, DisposedState.INSTANCE, buf);
}
class DefaultPartHttpMessageReaderTests extends AbstractLeakCheckingTests {
  // se añadió la comprobación de fugas en el tren de la corrección
}

En conjunto, esos cambios son consistentes con un fallo clásico de gestión de recursos reactivos: el tráfico multipart malformado o adversario podía empujar al analizador hacia estados de error o descarte sin liberar de forma fiable el DataBuffer subyacente y los recursos de las partes. En un servicio WebFlux, eso no tiene que verse dramático al principio. Puede empezar como una presión creciente lenta de memoria directa, retención de búferes o estancamiento de solicitudes bajo tráfico multipart repetido, y solo después colapsar la instancia.

Por eso la superficie vulnerable es más amplia que “servicios de subida de archivos”. Cualquier endpoint reactivo que acepte cuerpos multipart, incluyendo manejadores de subida de imágenes, endpoints de avatar, APIs de ingesta de documentos y gateways de API que proxyen tráfico multipart, pertenece al conjunto de revisión.

Por qué importa CVE-2026-41842

CVE-2026-41842 es el problema de mayor severidad del par en términos de puntuación de NVD. Spring dice que afecta a las aplicaciones que:

  1. usan Spring MVC o Spring WebFlux,
  2. sirven recursos estáticos desde el sistema de archivos, y
  3. habilitan el soporte de recursos versionados.

El diff del lanzamiento muestra a Spring reforzando exactamente la ruta de eliminación de versión y validación de ruta que se sitúa delante de la resolución de recursos estáticos. Antes de la corrección, la eliminación de versión borraba cada subcadena -<hash> coincidente. En la 7.0.8, eso se convirtió en una eliminación de la última ocurrencia:

public String removeVersion(String requestPath, String version) {
  String versionString = "-" + version;
  int index = requestPath.lastIndexOf(versionString);
  if (index != -1) {
    return requestPath.substring(0, index) + requestPath.substring(index + versionString.length());
  }
  return requestPath;
}

Spring también añadió una barrera de rechazo de rutas inválidas justo después de eliminar la versión:

String simplePath = versionStrategy.removeVersion(requestPath, candidate);
if (ResourceHandlerUtils.shouldIgnoreInputPath(simplePath)) {
  return Mono.empty();
}

La prueba de regresión añadida en el mismo tren concreta la forma del fallo:

String path = "font-awesome/css-sha/font-awesome.min-sha.css";
assertThat(removeVersion(path, "sha"))
    .isEqualTo("font-awesome/css-sha/font-awesome.min.css");

Eso importa porque la búsqueda de recursos versionados a menudo se trata como “solo plomería de frontend”, pero de todos modos se ejecuta en hilos de solicitud o en capacidad del bucle de eventos. Cuando el resolvedor elimina demasiado de una ruta, recorre el objetivo equivocado del sistema de archivos, o sigue intentando resolver rutas versionadas malformadas, los atacantes obtienen una primitiva barata de retención de conexiones contra una ruta de activos estáticos que de otro modo sería ordinaria.

Para los equipos de seguridad de aplicaciones, la conclusión clave es que una función de frontend como el versionado por hash de contenido cambia la superficie de ataque del backend. Un manejador de activos respaldado por el sistema de archivos ya no es un servidor de archivos pasivo una vez que empieza a analizar cadenas de versión controladas por el atacante y a resolverlas contra el almacenamiento local.

Delimitación de tu exposición

Primero, identifica si están presentes los módulos web de Spring afectados:

mvn dependency:tree -Dincludes=org.springframework:spring-web,org.springframework:spring-webflux,org.springframework:spring-webmvc
./gradlew dependencies --configuration runtimeClasspath | rg "spring-web(|flux|mvc)"

Luego identifica si las rutas de funciones vulnerables realmente están habilitadas en tu aplicación:

rg -n "FilePart|Part|MultipartBodyBuilder|multipart/form-data" src
rg -n "VersionResourceResolver|addVersionStrategy|resourceChain|VersionStrategy" src

Para CVE-2026-41840, prioriza cualquier controlador, router o método manejador que acepte Part, FilePart o subidas multipart. Para CVE-2026-41842, busca manejadores de recursos personalizados que sirvan desde ubicaciones locales del sistema de archivos en lugar de activos empaquetados en el classpath, especialmente cuando el versionado por hash de contenido está habilitado.

Detección y remediación

Actualiza a una de las líneas corregidas de inmediato:

  • Spring Framework 7.0.x -> 7.0.8
  • Spring Framework 6.2.x -> 6.2.19
  • Spring Framework 6.1.x -> 6.1.28 (comercial)
  • Spring Framework 5.3.x -> 5.3.49 (comercial)

Si necesitas priorizar, CVE-2026-41842 es la ruta de agotamiento remoto más sencilla porque VMware la puntuó como AV:N/AC:L/PR:N/UI:N/A:H, mientras que CVE-2026-41840 sigue siendo alcanzable de forma remota pero requiere una ruta de disparo multipart más estrecha (AV:N/AC:H/PR:N/UI:N/A:H).

Después de actualizar, vuelve a probar exactamente las rutas que corresponden a las funciones vulnerables:

  1. manejadores de subida multipart que analizan cuerpos multipart grandes o malformados;
  2. endpoints de activos estáticos que usan versionado por hash de contenido; y
  3. cualquier comportamiento de proxy inverso o CDN que pueda almacenar en caché o reproducir rutas versionadas extrañas.

Para los equipos que no pueden parchear de inmediato, la reducción temporal más segura está guiada por configuración: reduce la exposición pública de los endpoints multipart, coloca controles estrictos de tamaño de solicitud y de tasa delante de las rutas de subida, y revisa si los recursos estáticos versionados respaldados por el sistema de archivos son realmente necesarios. Esos son controles compensatorios, no correcciones.

La lección importante es más amplia que estos dos CVE. Las pilas web modernas de Java incluyen analizadores, resolvedores, cachés y cadenas de recursos que los desarrolladores rara vez tocan directamente, pero a los atacantes no les importa si una ruta es lógica de negocio o plomería del framework. Si una entrada no confiable la alcanza, forma parte de tu límite de seguridad de aplicaciones.

De la investigación a la remediación

Comprueba si este patrón existe en tu código

Convierte esta investigación en un flujo de remediación. Analiza dependencias y manifiestos para detectar riesgos similares en la cadena de suministro y prioriza las correcciones con contexto de alcanzabilidad.

Explorar el análisis de dependencias Solicitar demo

Referencias