Spring Framework CVE-2026-41855: Brief Summary of JMS Deserialization Vulnerability Affecting All Supported Release Lines

Introduction

A deserialization flaw in Spring Framework's JMS message converters allows attackers to instantiate arbitrary Java classes by sending crafted messages to an untrusted JMS broker, opening the door to remote code execution via gadget chain exploitation. With Spring Framework commanding over 22% of the web framework market and serving as the backbone for enterprise Java applications across regulated industries, CVE-2026-41855 affects an exceptionally broad install base spanning all four supported release lines from version 5.3.0 through 7.0.7.

The vulnerability, reported by external security researcher wo1enca1ca1 and disclosed on June 8, 2026, carries a CVSS score of 8.1 (HIGH) with full confidentiality, integrity, and availability impact. What makes this particularly noteworthy is the combination of a well understood vulnerability class (CWE-502: Deserialization of Untrusted Data) with a widely deployed framework and a patching model that restricts fixes for older release lines to commercial support customers only.

Technical Information

Root Cause

CVE-2026-41855 resides in two Spring JMS message converter classes:

• org.springframework.jms.support.converter.MappingJackson2MessageConverter
• org.springframework.jms.support.converter.JacksonJsonMessageConverter

These converters use Jackson's polymorphic deserialization capabilities to convert JMS message payloads into Java objects. The core problem is that the converter blindly resolved the Java type specified in an incoming JMS message header, the typeId property, via ClassUtils.forName() without any restriction on which classes could be instantiated. There was no allowlist, no blocklist, and no validation of any kind on the type identifier before class loading occurred.

This is a textbook instance of CWE-502 (Deserialization of Untrusted Data), which MITRE defines as a weakness where "the product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid." The CWE documentation further describes how attackers leverage "gadget chains," defined as "a sequence of method invocations that self-execute during the deserialization of a crafted payload." These chains repurpose existing legitimate classes already present on the application's classpath, meaning no custom malicious code needs to be injected.

CVSS Vector Breakdown

The CVSS v3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H tells us:

The "High" attack complexity is the key factor keeping this at 8.1 rather than a critical 9.x score. Exploitation requires that the JMS environment be untrusted, meaning the attacker must be able to publish messages to the JMS broker, and that suitable gadget classes exist on the target application's classpath. In a fully trusted environment where only authorized applications can publish messages, the attack vector is not viable. However, enterprise JMS deployments frequently involve shared brokers, cross-organizational messaging, or environments where the definition of "trusted" is ambiguous.

Attack Flow

A typical exploitation sequence proceeds as follows:

1. Reconnaissance: The attacker identifies a Spring application using MappingJackson2MessageConverter or JacksonJsonMessageConverter connected to a JMS broker they can publish to, or that accepts messages from untrusted sources.

2. Payload Construction: The attacker crafts a JMS message with a _type header (or equivalent type identifier property) pointing to a known gadget class available on the target application's classpath. Enterprise Spring deployments typically have rich classpaths with many libraries, expanding the set of available gadget classes significantly.

3. Message Delivery: The crafted message is published to the JMS broker on a queue or topic consumed by the vulnerable application.

4. Deserialization Trigger: Upon message consumption, the converter reads the typeId from the message header, calls ClassUtils.forName() with the attacker-specified class name, and instantiates the class during Jackson deserialization.

5. Gadget Chain Execution: The gadget chain executes a sequence of method calls during deserialization that achieve the attacker's objective. As the CWE-502 documentation notes, attackers can leverage gadget chains to achieve goals "such as generating a shell."

This follows the same pattern as prior Jackson deserialization vulnerabilities such as CVE-2020-24616, an RCE vulnerability in Jackson-databind that exploited a gadget chain found in the commons-dbcp2 library.

Patch Information

The Spring team published the fix on June 8, 2026, via commit 9bec52b1 (closing issue gh-36791), authored by Sébastien Deleuze and committed by Brian Clozel. The fix was shipped across multiple release branches:

The patch introduces a package-level allowlist mechanism (119 lines added, 0 deleted across source and test files). Here is what changed:

New trustedPackages Field and Setter

A new nullable String[] field and public setter were added to the converter:

private String @Nullable [] trustedPackages;

public void setTrustedPackages(String... trustedPackages) {
    this.trustedPackages = trustedPackages.clone();
}

The defensive .clone() call prevents callers from modifying the internal array after setting it.

Private Validation Method

A new isTrustedPackage() method extracts the package name from the requested type string and checks it against the allowlist. It also correctly handles array type descriptors (e.g., [Lcom.example.MyClass; for 1D arrays, [[Lcom.example.MyClass; for 2D arrays) by stripping the array prefix:

private boolean isTrustedPackage(String requestedType) {
    if (this.trustedPackages != null) {
        String packageName = ClassUtils.getPackageName(requestedType);
        int lastBracketIndex = packageName.lastIndexOf('[');
        if (lastBracketIndex != -1 && packageName.length() > lastBracketIndex + 1
                && packageName.charAt(lastBracketIndex + 1) == 'L') {
            packageName = packageName.substring(lastBracketIndex + 2);
        }
        for (String trustedPackage : this.trustedPackages) {
            if (packageName.equals(trustedPackage)) {
                return true;
            }
        }
        return false;
    }
    return true;
}

When trustedPackages is null (the default, meaning setTrustedPackages was never called), the method returns true, preserving full backward compatibility for trusted JMS environments. Enforcement only activates when the developer explicitly configures the allowlist.

Enforcement Gate

The actual security gate is inserted in the getJavaTypeForMessage() method, right before the existing ClassUtils.forName() call that resolves the attacker-controlled typeId:

if (!isTrustedPackage(typeId)) {
    throw new MessageConversionException("The class '" + typeId +
            "' is not in the trusted packages: " + Arrays.toString(this.trustedPackages));
}

If the class's package does not appear in the allowlist, a MessageConversionException is thrown before any class loading or instantiation occurs, completely neutralizing the deserialization gadget chain.

Test Coverage

The commit adds 82 lines of test code in MappingJackson2MessageConverterTests.java covering five scenarios: untrusted package rejection, trusted package acceptance, empty allowlist (rejects all), 1D array type handling, and 2D array type handling.

Required Configuration After Upgrading

Upgrading alone is not sufficient for applications in untrusted JMS environments. The Spring advisory makes explicit that developers must also call setTrustedPackages(...) with the specific packages they expect. A representative configuration:

@Bean
public MappingJackson2MessageConverter jacksonJmsMessageConverter() {
    MappingJackson2MessageConverter converter = new MappingJackson2MessageConverter();
    converter.setTargetType(MessageType.TEXT);
    converter.setTypeIdPropertyName("_type");
    converter.setTrustedPackages("com.yourcompany.yourapp.domain");
    return converter;
}

This is an opt-in security hardening pattern, similar to Spring's existing DefaultJmsListenerContainerFactory and ActiveMQ's own trusted packages approach. The advisory describes this as "a single, secure configuration step" versus the previously error-prone approach of configuring the underlying ObjectMapper directly.

Commercial Support Considerations

Organizations on Spring Framework 6.1.x or 5.3.x without commercial Tanzu Spring support cannot obtain patched versions through open source channels. For those unable to purchase commercial support, alternative mitigations include implementing strict JMS broker access controls, network segmentation to isolate JMS infrastructure, deploying WAF or application-layer filtering, or manually configuring the underlying ObjectMapper to restrict polymorphic deserialization types (described as "error-prone and complex" in community discussions).

Affected Systems and Versions

All four supported Spring Framework release lines are affected:

The advisory explicitly warns that unsupported versions are also vulnerable. The specific vulnerable configuration requires:

• An application using MappingJackson2MessageConverter or JacksonJsonMessageConverter for JMS message processing
• The converter configured with a typeIdPropertyName enabling polymorphic type resolution
• An untrusted JMS environment where unauthorized message producers can publish to the broker
• Gadget classes present on the application's classpath (common in enterprise deployments with rich dependency trees)

Applications operating in fully trusted JMS environments where all message producers are authorized and the broker itself is secured are not exploitable through this vector, though the advisory recommends patching regardless.

Vendor Security History

The Spring portfolio has experienced several significant security incidents that provide context for CVE-2026-41855.

The most notable was Spring4Shell (CVE-2022-22965), a remote code execution vulnerability in Spring Core that was actively exploited in the wild. Trend Micro observed exploitation deploying the Mirai botnet, and Unit 42 documented widespread scanning and exploitation attempts. Spring4Shell demonstrated that Spring Framework vulnerabilities attract significant attention from both opportunistic and sophisticated threat actors.

Recent 2025 and 2026 Spring security advisories reveal an expanding attack surface across the portfolio:

The emergence of four Spring AI advisories in May 2026 alone signals a new and expanding attack surface as the portfolio diversifies into AI, cloud configuration, and observability tooling.

On June 8, 2026, the same day as the CVE-2026-41855 advisory, Broadcom announced expanded investment in Spring and Java ecosystem security to "prepare customers for AI-enabled threats." While this signals vendor awareness of the evolving threat landscape, the timing alongside a high severity framework vulnerability and the commercial-only patching model for older release lines creates a complex picture for organizations evaluating their Spring security posture.

Java deserialization vulnerabilities more broadly remain a persistent threat category. CVE-2026-40860, a separate JMS deserialization vulnerability where "the application deserializes the message payload without proper validation," and CVE-2026-27830, a c3p0 JNDI deserialization RCE, both demonstrate that JMS deserialization is a recurring weak point across the Java ecosystem. The MITRE EMB3D model classifies insecure deserialization as TID-326, confirming it as a top-tier threat for critical infrastructure.

Historical precedent for rapid exploitation is particularly relevant here. CVE-2025-24813, another Java deserialization vulnerability, was exploited approximately 30 hours after public disclosure according to Endor Labs. Proofpoint telemetry indicates that 12 distinct 2026 CVEs are being actively exploited in network-facing attacks. While no active exploitation of CVE-2026-41855 has been confirmed as of June 9, 2026, the window for proactive patching before weaponization may be narrow.

References

• CVE-2026-41855: Spring Framework Unsafe Deserialization via JMS Converters (Spring Advisory)
• NVD Entry for CVE-2026-41855
• Spring Framework Patch Commit 9bec52b1
• Feedly CVE-2026-41855 Tracking
• CWE-502: Deserialization of Untrusted Data
• Spring Security Advisories
• CVE-2022-22965 (Spring4Shell) Analysis by Unit 42
• Spring4Shell Exploitation Analysis by Trend Micro
• Struggling to Patch Spring-Web? Try This Instead (Endor Labs)
• 2026 Vulnerability Exploitation in the Wild (Proofpoint)
• Java Deserialization Cheat Sheet
• TID-326: Insecure Deserialization (MITRE EMB3D)
• CVE-2020-24616: Jackson-databind Deserialization Vulnerability
• CVE-2026-40860: JMS Deserialization (Red Hat)
• Broadcom Expands Investment in Spring and Java Ecosystem Security
• Spring Framework Market Share (6sense)