CVE-2026-41006

Incorrectly Configured Access Control
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, providing model types such as RepresentationModel, EntityModel, and CollectionModel along with serializers and deserializers for several hypermedia media types, including HAL, Collection+JSON (application/vnd.collection+json), and UBER (application/vnd.amundsen-uber+json). When an application accepts one of these media types as a request body, the corresponding Spring HATEOAS Jackson module deserializes the incoming document back into the application's model objects.

A high-severity vulnerability (CVE-2026-41006) has been identified in the Collection+JSON and UBER deserializers. Both deserializers reconstruct domain objects through PropertyUtils.createObjectFromProperties, which binds incoming values onto JavaBean setters using plain reflection without consulting the active Jackson configuration. As a result, the Jackson access controls and customizations an application relies on to protect security-sensitive properties (for example @JsonProperty(access = READ_ONLY), setter-side @JsonIgnore, @JsonIgnoreProperties, mix-ins, and the mapper's deserialization features) are ignored on these two media-type code paths. A remote client can therefore set properties that the application configured Jackson to reject, driving a deserialized model into a state the application assumed was unreachable.

Per OWASP: secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. When a deserialization path enforces its own ad hoc reflection-based binding instead of honoring the centrally configured Jackson access controls, the protection the application believes it has declared is silently not applied, which is exactly the kind of design-level access-control gap this category warns about.

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 because the malicious document arrives over an ordinary HTTP request, attack complexity is Low and no privileges or user interaction are required because any client that can reach an affected endpoint can submit the payload, and the impact is Availability-only and High because the unguarded property binding can force the model into an invalid state. There is no confidentiality or integrity disclosure impact, and the advisory does not describe a polymorphic-deserialization or gadget-chain path, so this is an access-control bypass on the deserialization path rather than remote code execution.

This issue affects Spring HATEOAS >=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.

Details

Module Info

Vulnerability Info

The vulnerability is in PropertyUtils.createObjectFromProperties in the org.springframework.hateoas.mediatype package, which is invoked by the Collection+JSON deserializers in org.springframework.hateoas.mediatype.collectionjson (Jackson2CollectionJsonModule and CollectionJsonItem.toRawData) and the UBER deserializers in org.springframework.hateoas.mediatype.uber (Jackson2UberModule). These deserializers run whenever an application has enabled the Collection+JSON or UBER hypermedia types and a controller accepts a RepresentationModel subclass or an EntityModel as a request body.

Pre-fix, createObjectFromProperties accepts a raw Class and binds every entry of the parsed property map directly onto the matching JavaBean setter via reflection. It never touches the active Jackson DeserializationContext or ObjectMapper, so any access control the application configured through Jackson is bypassed

public static <T> T createObjectFromProperties(Class<T> clazz, Map<String, Object> properties) {

    T obj = BeanUtils.instantiateClass(clazz);

    properties.forEach((key, value) -> {
        Optional.ofNullable(BeanUtils.getPropertyDescriptor(clazz, key)) //
                .ifPresent(property -> {

                    try {

                        Method writeMethod = property.getWriteMethod();
                        ReflectionUtils.makeAccessible(writeMethod);
                        writeMethod.invoke(obj, value);

                    } catch (IllegalAccessException | InvocationTargetException e) {
                        throw new RuntimeException(e);
                    }
                });
    });

    return obj;
}

The deserializers call this method with the raw class of the target type, for example in Jackson2CollectionJsonModule:

RepresentationModel<?> resourceSupport = (RepresentationModel<?>) PropertyUtils
        .createObjectFromProperties(this.contentType.getRawClass(), properties);

and in CollectionJsonItem.toRawData:

return PropertyUtils.createObjectFromProperties(javaType.getRawClass(), //
        this.data.stream() //
                .collect(Collectors.toMap(CollectionJsonData::getName, CollectionJsonData::getValue)));

with equivalent call sites in Jackson2UberModule.convertToResourceSupport and convertToResource. Because binding goes through BeanUtils.getPropertyDescriptor plus writeMethod.invoke, a setter is invoked for any property name the document supplies whose setter exists, regardless of whether Jackson would have treated that property as read-only, ignored, or otherwise not bindable. An application that protects a security-sensitive property solely through Jackson annotations (the documented and supported way to do so) therefore loses that protection for requests that arrive as Collection+JSON or UBER, while the same payload submitted as plain JSON or HAL would be correctly rejected by the standard Jackson pipeline.

Mitigation

Only recent versions of Spring HATEOAS receive community support and updates. The OSS fixes are limited to the 2.5.x and 3.0.x lines. Older versions have no publicly available OSS 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. The OSS fix ships in Spring HATEOAS 2.5.3 (2.5.x line) and 3.0.4 (3.0.x line).
  • If an upgrade is not immediately possible on an affected deployment, and the application does not require the Collection+JSON or UBER hypermedia types, disable those media types so the affected deserializers are not registered, and continue to use HAL or plain JSON, which deserialize through the standard Jackson pipeline.
  • 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-41006
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
Incorrectly Configured Access Control
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.