CVE-2026-41855: Spring Framework JMS Jackson Deserialization Flaw

On June 8, 2026, the Spring team disclosed CVE-2026-41855, a High-severity (CVSS 3.1 base score 8.1, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) deserialization vulnerability (CWE-502) in Spring Framework's JMS support. In an untrusted JMS environment, the MappingJackson2MessageConverter and JacksonJsonMessageConverter classes allow arbitrary class instantiation from incoming message payloads, which can drive gadget-chain deserialization and unauthorized actions on the consuming application. It affects Spring Framework 5.3.0–5.3.48, 6.1.0–6.1.27, 6.2.0–6.2.18, and 7.0.0–7.0.7. An OSS fix is available for the supported 6.2.x and 7.0.x branches (6.2.19 and 7.0.8); the EOL 6.1.x, 5.3.x, and earlier branches have no OSS fix available.

Running an unsupported version of Spring Framework? See NES for Spring for a secure drop-in replacement with this CVE resolved.

‍

What is CVE-2026-41855?

CVE-2026-41855 is a deserialization of untrusted data vulnerability (CWE-502) in the Jackson-based message converters that Spring Framework provides for JMS (Java Message Service) integration.

When an application configures MappingJackson2MessageConverter or JacksonJsonMessageConverter to deserialize inbound JMS messages, the converter resolves the target Java type from information carried in the message itself. If the broker, or any party that can publish to the destination, is not fully trusted, an attacker can craft a message that instructs the converter to instantiate an arbitrary class on the classpath. Combined with a suitable gadget class, that arbitrary instantiation becomes the entry point for a deserialization gadget chain, the same exploitation pattern that has driven a long line of Java deserialization CVEs. (For a related look at how a Jackson-family flaw plays out in practice, see our breakdown of CVE-2025-52999 in jackson-core.)

The critical qualifier, stated plainly in the advisory, is the untrusted JMS environment. In the common case where the JMS broker and all publishers are trusted infrastructure, the converter's behavior is not exploitable. The vulnerability surfaces when message payloads can originate from a source outside the application's trust boundary: a shared or multi-tenant broker, a broker reachable by lower-trust services, or a destination that external systems can publish to.

‍

Severity and exploit conditions

The scoring below is the CNA-assigned vector from the Spring security advisory. At the time of writing, NVD lists the record as Undergoing Analysis and has not yet published an independent primary score, so the CNA vector is the authoritative figure today.

Exploit preconditions. All of the following must hold for the vulnerability to be exploitable:

• The application consumes JMS messages using MappingJackson2MessageConverter or JacksonJsonMessageConverter.
• The JMS environment is untrusted: a publisher outside the application's trust boundary can place messages on a consumed destination.
• A gadget class usable for the intended impact is present on the consumer's classpath.

Two metrics deserve emphasis. PR:N means no application credentials are needed: an attacker who can publish to a consumed destination does not have to authenticate to the Spring application. But AC:H reflects a real precondition. The vulnerability is only exploitable in an untrusted JMS environment, and the worst-case impact additionally depends on a usable gadget class being present on the consumer's classpath. This is not a drive-by against every Spring application that uses JMS. Where the environment is trusted, the converters behave safely; where it is not, and a gadget chain is reachable, the impact reaches the full C:H/I:H/A:H severity.

‍

What an attacker can do

An attacker who can publish to a consumed JMS destination in an untrusted environment can:

• Instantiate arbitrary classes named in the inbound message, using the Jackson converter's type resolution as the instantiation primitive.
• Trigger a deserialization gadget chain by selecting a class (or chain of classes) on the consumer's classpath whose construction or property-setting side effects perform attacker-useful work. Depending on the available gadgets, this is the classic path to remote code execution.
• Exfiltrate in-process secrets reachable from the gadget chain (credentials, tokens, configuration held in memory), consistent with the C:H rating.
• Corrupt application state or data through gadget side effects, consistent with the I:H rating.
• Degrade or crash the consumer by instantiating classes that exhaust resources or throw on construction, consistent with the A:H rating.

The shape of the worst case depends on which gadget classes are present. The vulnerability itself provides the arbitrary-instantiation foothold; the deployed dependency set determines how far that foothold reaches.

‍

Root cause

The converters resolve the Java type to deserialize into from message-supplied metadata and then hand that type to Jackson for instantiation, without restricting which classes are permitted. There is no allowlist of trusted packages by default, so any resolvable class on the classpath is a candidate for instantiation.

The fix adds a setTrustedPackages(String... trustedPackages) method to the affected converters. Operators of a supported branch can constrain deserialization to an explicit set of packages, so that a crafted message naming a class outside the allowlist is rejected before instantiation. After upgrading to a fixed version, configuring the allowlist takes one call on the converter bean:

@Bean
public MessageConverter jmsMessageConverter() {
    MappingJackson2MessageConverter converter = new MappingJackson2MessageConverter();
    converter.setTargetType(MessageType.TEXT);
    converter.setTypeIdPropertyName("_type");
    // New in 6.2.19 / 7.0.8: restrict deserialization to the packages
    // your application actually expects on this destination.
    converter.setTrustedPackages("com.example.orders.messages", "com.example.shared.events");
    return converter;
}

A crafted message naming a type outside those packages is now rejected before Jackson ever instantiates it. The default-deny posture this enables is the standard remediation for Jackson polymorphic-deserialization exposure: limit instantiation to types the application actually expects.

This is a familiar lesson in Java security: any pipeline that turns externally influenced data into instantiated objects is a deserialization trust boundary, and that boundary must be enforced with an allowlist, not with the assumption that the data source is benign.

Who is affected?

The fix availability below reflects what is obtainable as a free open-source release. Branches whose only resolution path is outside open-source distribution are marked "No (OSS EOL)".

Spring Framework 6.1 reached end of open-source life on June 30, 2025, and Spring Framework 5.3 reached end of open-source life on August 31, 2024. The Spring open-source project does not ship security releases for these branches. Applications still running 6.1.x, 5.3.x, or earlier are exposed to CVE-2026-41855 with no free upstream patch to apply: the only options are migrating to a supported branch or obtaining a commercially maintained, patched build.

Mitigation guidance

‍

Related CVEs

CVE-2026-41855 is one of several recent Spring ecosystem disclosures where EOL branches are left without an open-source fix. If you are assessing Spring exposure across an estate, review these alongside it:

• CVE-2026-40982: Spring Cloud Config Server directory traversal
• CVE-2026-22752: Spring Authorization Server XSS, SSRF, and privilege escalation
• CVE-2025-41254: Spring WebSocket CSRF bypass

For background on how the Spring project handles security fixes across supported and EOL branches, see our guide to how Spring Framework CVEs are patched and what happens after end of life.

‍

Taking action

CVE-2026-41855 is a textbook EOL-risk scenario. The supported 6.2.x and 7.0.x branches receive an open-source fix and a new setTrustedPackages(...) control. The 6.1.x and 5.3.x branches, both past their open-source end of life, get no free patch. For the many enterprises still standardized on those branches, the choice is an unplanned migration under disclosure pressure, or a maintained build that closes the gap without one.

If your organization runs Spring Framework on an EOL branch, this is exactly the risk HeroDevs exists to address. NES for Spring delivers secure drop-in replacements with vulnerabilities like CVE-2026-41855 resolved on the versions the Spring project no longer maintains, so you can stay protected and compliant without an emergency upgrade.