CVE-2026-59291

Server-Side Request Forgery
Affects
Spring Cloud Function
in
Spring
No items found.
Versions
>=4.0.4 <=4.1.6, >=4.2.0 <=4.2.7, >=4.3.0 <=4.3.4, >=5.0.0 <5.0.4
Exclamation circle icon
Patch Available

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

Overview

Spring Cloud Function is a Spring project that lets developers write business logic as plain Java functions and then expose those functions over many transports and runtimes, including HTTP endpoints, messaging channels such as RabbitMQ or Kafka, and serverless platforms such as AWS Lambda and Azure Functions, without changing the function code itself. A large part of what the project does at runtime is decide how to turn an inbound message payload into the Java type a function expects, which is handled by its message converters.

A Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-59291) has been identified in the JsonMessageConverter component of Spring Cloud Function, which allows attackers to choose the JSON deserialization target type through the type parameter of the inbound message content type. Because any class present on the application classpath can be named, an attacker who can influence that header can steer binding into types whose construction or property binding opens a URL or reads a local file, producing outbound requests and file reads the application never intended.

Per OWASP: The target application may have functionality for importing data from a URL, publishing data to a URL or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (path traversal etc.). When the manipulated request goes to the server, the server-side code picks up the manipulated URL and tries to read data to the manipulated URL.

This issue affects the message conversion layer of Spring Cloud Function.

Details

Module Info

Vulnerability Info

This Low-severity vulnerability is found in the org.springframework.cloud:spring-cloud-function-context package in the message conversion layer of Spring Cloud Function.

When a function declares no concrete input type, or declares Object, JsonMessageConverter falls back to the type parameter of the message content type to decide what to deserialize into. That parameter travels with the request, so its value is under the control of whoever sends the message, and the converter passed it directly to the context class loader:

@Override
protected Object convertFromInternal(Message<?> message, Class<?> targetClass, @Nullable Object conversionHint) {
    if (conversionHint instanceof ParameterizedTypeReference<?>) {
        conversionHint = ((ParameterizedTypeReference<?>) conversionHint).getType();
    }
    Type convertToType = this.getResolvedType(targetClass, conversionHint);
    if (convertToType == null || convertToType == Object.class) {
        MimeType mimeType = getMimeType(message.getHeaders());
        String type = mimeType.getParameter("type");
        if (StringUtils.hasText(type)) {
            try {
                convertToType = Thread.currentThread().getContextClassLoader().loadClass(type);
            }
            catch (ClassNotFoundException e) {
                throw new IllegalArgumentException("Failed to load class `" + type + "` specified by the provided content-type: " + mimeType, e);
            }
        }
        else {
            return message.getPayload();
        }
    }
    ...
    return this.jsonMapper.fromJson(message.getPayload(), convertToType);
}

There is no restriction on which class may be named. Any type reachable on the application classpath can be selected as the binding target, and the attacker also supplies the JSON body that populates it. Classes whose constructors, setters or JSON creators resolve a URL or a filesystem path are therefore reachable from a remote message, which is how the flaw surfaces as an outbound request to an attacker-chosen host or a read of a local file. The same primitive also widens the reachable class surface for other binding side effects, since the deserializer is being pointed at types the function author never declared.

The companion canConvertFrom check makes the path easy to reach rather than harder: when the target type is unknown, the converter reports that it can convert precisely because a type parameter is present, so a message carrying that parameter selects this converter and then this branch.

Exploitation requires a deployment in which the attacker can supply the message content type and a suitable class is present on the classpath, which is why the issue carries a low CVSS score, but it removes a boundary that application code cannot restore on its own.

This vulnerability was introduced in 2023 with Spring Cloud Function 4.0.4.

Mitigation

Only recent versions of Spring Cloud Function receive community support. Older lines are End-of-Life and will not receive public updates to address this issue.

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

  • Upgrade to a currently supported version of Spring Cloud Function.
  • Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Low
ID
CVE-2026-59291
PROJECT Affected
Spring Cloud Function
Versions Affected
>=4.0.4 <=4.1.6, >=4.2.0 <=4.2.7, >=4.3.0 <=4.3.4, >=5.0.0 <5.0.4
NES Versions Affected
Published date
August 25, 2026
≈ Fix date
September 1, 2026
Category
Server-Side Request Forgery
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 submitting the form 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.