CVE-2026-41007

Denial of Service
Affects
Spring HATEOAS
in
Spring
No items found.
Versions
>=1.3.0 <=1.3.7, >=1.5.0 <=1.5.6, >=2.2.0 <=2.2.5, >=2.3.0 <=2.3.4, >=2.4.0 <=2.4.1, >=2.5.0 <=2.5.2, >=3.0.0 <=3.0.3
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring HATEOAS is a library for building hypermedia-driven REST APIs on top of the Spring Framework. It helps applications create and consume representations that follow the HATEOAS principle by modeling links and link relations as first-class objects. Link relations (the rel values that describe how a linked resource relates to the current one) are represented internally by the StringLinkRelation value type, which every string-based relation flows through, including relations that originate from incoming hypermedia payloads and parsed Link headers.

A high-severity vulnerability (CVE-2026-41007) has been identified in Spring HATEOAS. The StringLinkRelation type maintains a process-wide static cache of StringLinkRelation instances keyed on the raw relation string. The cache is a plain ConcurrentHashMap populated with computeIfAbsent, so it has no eviction and no upper bound: every distinct relation string ever observed adds a permanent entry. Because the public LinkRelation.of(String) factory and the JSON deserialization path both funnel through StringLinkRelation.of(String), an application that deserializes untrusted hypermedia through a controller @RequestBody, or that parses Link headers or relation values supplied by a remote peer, lets an attacker insert an unlimited number of distinct cache keys. A stream of requests carrying unique relation strings drives the cache to grow without bound until the JVM heap is exhausted and the application fails with an OutOfMemoryError, denying service to all users.

Per OWASP: a Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed; there are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resource-handling vulnerabilities, among others. This issue is the resource-handling variant of that category: an unbounded in-memory cache lets remote input consume heap until the process can no longer serve requests.

The CVSS v3.1 base score for this vulnerability is 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The attack vector is Network and requires no privileges or user interaction because the malicious relation strings arrive in ordinary hypermedia requests. The impact is Availability-only and High: the cache growth exhausts the heap and takes the application down, with no effect on confidentiality or integrity.

This issue affects >=1.3.0 <=1.3.7, >=1.5.0 <=1.5.6, >=2.2.0 <=2.2.5, >=2.3.0 <=2.3.4, >=2.4.0 <=2.4.1, >=2.5.0 <=2.5.2, and >=3.0.0 <=3.0.3 of Spring HATEOAS.

Details

Module Info

Vulnerability Info

The vulnerability is in StringLinkRelation, the value type that backs every string-based LinkRelation in Spring HATEOAS. The class holds a single static cache and resolves all relations through it:

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

final class StringLinkRelation implements LinkRelation, Serializable {

    private static final Map<String, StringLinkRelation> CACHE = new ConcurrentHashMap<>(256);

    @JsonCreator
    public static StringLinkRelation of(String relation) {

        Assert.hasText(relation, "Relation must not be null or empty!");

        return CACHE.computeIfAbsent(relation, StringLinkRelation::new);
    }
    // ...
}


The 256 passed to ConcurrentHashMap is only an initial-capacity hint, not a cap. computeIfAbsent inserts a new, permanent entry for every relation string that is not already present, and nothing ever removes entries. The cache therefore grows monotonically with the number of distinct relation strings the application has ever seen.

That cache is reachable from attacker-controlled input. The public LinkRelation.of(String) factory delegates straight to it:

static LinkRelation of(String relation) {
    return StringLinkRelation.of(relation);
}

and the @JsonCreator annotation on StringLinkRelation.of means Jackson invokes the same method while deserializing hypermedia documents (HAL and other media types) that carry link relations. Any endpoint that accepts hypermedia through a controller @RequestBody, or any client that parses Link headers or relation values returned by a remote peer, will feed remote-supplied relation strings into the cache. An attacker who sends a large number of requests, each carrying a fresh unique relation string, forces a corresponding number of permanent cache entries. With enough distinct strings the JVM heap is exhausted, the process throws OutOfMemoryError, and the application stops serving requests.

Mitigation

Only recent versions of Spring HATEOAS receive community support and updates. Older versions have no publicly available fixes for this vulnerability.

Users of the affected components should apply one of the following mitigations:

  • Upgrade to a currently supported version of Spring HATEOAS that has a public OSS fix. The fix ships in Spring HATEOAS 2.5.3 (2.5.x line) and 3.0.4 (3.0.x line).
  • Leverage a commercial support partner like HeroDevs for post-EOL security support through Never-Ending Support (NES) for Spring HATEOAS.
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
High
ID
CVE-2026-41007
PROJECT Affected
Spring HATEOAS
Versions Affected
>=1.3.0 <=1.3.7, >=1.5.0 <=1.5.6, >=2.2.0 <=2.2.5, >=2.3.0 <=2.3.4, >=2.4.0 <=2.4.1, >=2.5.0 <=2.5.2, >=3.0.0 <=3.0.3
NES Versions Affected
Published date
June 11, 2026
≈ Fix date
June 11, 2026
Category
Denial of Service
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By clicking “submit” I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.