External risk intelligence

Spring Framework Arbitrary Class Instantiation via Untrusted JMS

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-41855

This vulnerability affects a Java Message Service (JMS) component within the Spring Framework. JMS brokers and message listeners are typically deployed within internal, backend network segments to facilitate application-to-application communication, rather than being directly exposed to the public internet.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical vulnerability in the Spring Framework's message conversion components that could allow unauthorized actions. In specific, untrusted Java Message Service environments, this flaw enables attackers to execute arbitrary code through deserialization, potentially leading to significant system compromise. While the primary concern is confirming relevance and exposure, this issue highlights the importance of secure configurations in messaging systems.

  • Allows unauthorized code execution via message conversion.
  • Critical flaw in widely used Spring Framework.
  • Confirm relevance and exposure of messaging systems.

Attack Path

How an attacker could exploit the issue

An attacker can exploit this vulnerability by sending specially crafted messages to an untrusted Java Message Service (JMS) environment. The vulnerable `MappingJackson2MessageConverter` or `JacksonJsonMessageConverter` components within the Spring Framework can be tricked into deserializing malicious data. This process can lead to the instantiation of arbitrary classes, allowing the attacker to execute unauthorized actions.

  • Requires untrusted JMS environment.
  • Triggered by deserializing crafted messages.
  • Leads to arbitrary code execution.

Live Threat

Current exploitation, exposure, and threat context

In an untrusted Java Message Service (JMS) environment, this vulnerability could allow unauthorized actions through gadget class deserialization when using specific Spring Framework message converters.

  • Spring Framework message converters.
  • Arbitrary class instantiation via deserialization.
  • Unauthorized actions, impacting service behavior.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in Spring Framework's JMS converters enables arbitrary class instantiation via gadget class deserialization in untrusted JMS environments. Infrastructure, platform, and security teams are likely responsible for addressing this. The first practical move is to identify all instances of the affected Spring Framework versions, determine their reachability and business criticality, and then assign ownership for remediation planning based on assessed risk.

  • Application and platform teams own the issue.
  • Verify JMS and application reachability.
  • Plan remediation based on risk.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is the Spring Framework and how does it relate to CVE-2026-41855?

Spring Framework is a foundational Java platform used by developers to build enterprise-level applications, frequently handling data exchange between different services. CVE-2026-41855 specifically targets components within this framework designed to convert messages, which are essential for applications to communicate asynchronously through Java Message Service (JMS) brokers.

How does this vulnerability allow for arbitrary class instantiation?

This flaw belongs to the CWE-502 weakness class, known as Deserialization of Untrusted Data. The affected Spring converters attempt to turn incoming message data into Java objects. If an attacker sends a malicious message, the converter may mistakenly instantiate unintended, unauthorized classes—known as gadgets—that the application did not expect to process, which can then be used to execute arbitrary code.

Does any message sent to a Spring application trigger this vulnerability?

No. The vulnerability requires a specific context: the application must be configured to process messages from an untrusted Java Message Service environment. If your system does not utilize these specific message converters to handle data from external or untrusted sources, or if your messaging infrastructure is strictly isolated from untrusted actors, the trigger conditions for this deserialization flaw are not met.

Is my Spring-based application relevant to this CVE?

Relevance depends on where your JMS components sit in your network. According to Halo Surface Signal, this vulnerability is classified as unlikely for many because JMS brokers and listeners are typically buried deep within internal, backend network segments rather than exposed to the public internet. If your messaging service is not reachable from an untrusted network, your immediate risk is significantly reduced.

What is the first step to take if I am running Spring Framework?

Begin by auditing your software inventory to identify which applications utilize the affected versions of the Spring Framework. Once identified, evaluate whether these applications interact with untrusted JMS environments. Your goal is to map these components to their business function and network location so you can prioritize patching those that are most accessible or critical to your operations.

References