Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain publish access to consumed Pulsar topic
-
DeliveryCraft message header with malicious type metadata
-
ExploitHeader bypasses prefix-based trusted-packages check
-
ExecutionConsumer JsonPulsarHeaderMapper deserializes attacker-chosen class
-
PersistGadget chain executes in consumer JVM
-
ImpactFull compromise of consumer process
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V1 - Encoding and Sanitization Safe deserialization, type allowlists
MITRE ATT&CK
2 techniques across 2 tactics: Execution, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires (1) a Spring for Apache Pulsar consumer on a vulnerable version (1.1.0-1.1.17, 1.2.0-1.2.17, or 2.0.0-2.0.5) that uses JsonPulsarHeaderMapper to deserialize message headers; (2) the attacker can publish messages to a topic that consumer reads - either directly through Pulsar producer access, via a compromised upstream producer, or because the topic accepts untrusted input; and (3) either trustedPackages is configured with a parent package whose subpackages contain an exploitable class, or trustedPackages is left empty (triggering the unsafe trust-everything fallback). Practical code execution further requires a usable deserialization gadget on the consumer's classpath, which is the primary reason CVSS scores AC:H. Deployments that authenticate Pulsar producers and tightly scope topic publish permissions materially reduce reachability even before patching. |
| Impact | The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H signals a network-reachable, unauthenticated path with high attack complexity and full CIA impact on the consumer JVM - typical of a Java deserialization issue that requires the right gadget chain on the consumer's classpath. No EPSS, KEV, SSVC, or POC data was provided, so exploitation likelihood signals are absent and cannot be cited; absence of POC is not evidence one will not appear, given how well-trodden Jackson polymorphic deserialization gadgets are. The realistic risk depends heavily on deployment context: exposed Pulsar consumers that ingest headers from untrusted producers and run on classpaths containing common gadget-laden libraries (Spring, Commons Collections, etc.) should treat this as a priority, while internal consumers with strictly controlled producers face a lower (but non-zero) blast radius. AC:H reflects that an attacker still needs both reachable header ingestion and a viable gadget chain, which moderates raw severity but does not negate it. |
| Exploit ScenarioDerived | An attacker with the ability to publish to a Pulsar topic consumed by a vulnerable Spring for Apache Pulsar application crafts a message whose header type metadata references a class living under (or prefix-matching) a trusted package, or any class at all if the consumer left trustedPackages empty. When the JsonPulsarHeaderMapper deserializes the header on the consumer JVM, Jackson instantiates the attacker-chosen type, and if a suitable gadget chain exists on the consumer's classpath this can chain into arbitrary code execution in the consumer process. No public exploit identified at time of analysis, but Java JSON-deserialization gadget research is mature and the AC:H rating largely reflects gadget-availability dependence rather than novel difficulty. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 10, 2026
Insecure deserialization in Spring for Apache Pulsar's JsonPulsarHeaderMapper allows remote attackers to bypass trusted-package controls and potentially trigger arbitrary Java object instantiation through Pulsar message headers. The flaw stems from a prefix-based package match plus an unsafe empty-allow-list default, affecting versions 1.1.0-1.1.17, 1.2.0-1.2.17, and 2.0.0-2.0.5. No public exploit identified at time of analysis, but the CVSS 8.1 rating and CWE-502 classification place this firmly in the high-impact Java deserialization category that has historically yielded remote code execution.
RemediationAI
Upgrade Spring for Apache Pulsar to a fixed release on your branch - consult https://spring.io/security/cve-2026-41732 for the exact patched versions, as the input does not enumerate them and they should not be guessed. If immediate upgrade is not feasible, explicitly configure the trustedPackages property on JsonPulsarHeaderMapper to a minimal, exhaustive allow-list of the fully qualified packages your application actually deserializes, avoiding broad parents such as 'com' or 'org' since prefix matching will pull in everything beneath them, and never leave the trusted-packages list empty since that triggers the unsafe trust-everything fallback. Where header-typed deserialization is not required, switch to a header mapper that treats all headers as raw bytes or strings, accepting that downstream code must then perform its own typed conversion. Additionally restrict which producers can publish to consumed topics via Pulsar authentication and authorization so that untrusted parties cannot inject crafted headers in the first place.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Spring for Apache Pulsar is the Spring portfolio's integration library for Apache Pulsar, a distributed messaging and streaming platform. The JsonPulsarHeaderMapper component converts Pulsar message headers into typed Java objects on the consumer side, using a 'trusted packages' allow-list to constrain which classes Jackson may instantiate during deserialization - a standard defense against the CWE-502 Deserialization of Untrusted Data class of bugs. Two distinct logic defects undermine that defense: trust is enforced via string prefix matching (so trusting 'com.example' also trusts 'com.example.attacker' and any other subpackage a consumer never intended), and an empty trusted-packages configuration silently degrades to trusting every package instead of the documented safe-default behavior. The combination effectively turns header deserialization into a broad gadget-loading surface whenever Spring Pulsar consumers process headers from a producer an attacker controls.
Know when Spring For Apache Pulsar gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from Vendor (vmware) · only source for this CVE.
CVSS VectorVendor: vmware
Lifecycle Timeline
2DescriptionCVE.org
JsonPulsarHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Additionally, an empty trusted-packages configuration fell back to trusting all packages rather than applying a safe default allow-list.
Affected versions: Spring for Apache Pulsar 2.0.0 through 2.0.5; 1.2.0 through 1.2.17; 1.1.0 through 1.1.17.
Blast Radius
ecosystem impact- 8 maven packages depend on org.springframework.pulsar:spring-pulsar (2 direct, 6 indirect)
Ecosystem-wide dependent count for version 2.0.0.
Articles & Coverage 1
Executive ViewAI
Spring for Apache Pulsar versions 1.1.0-2.0.5 contain a remote code execution vulnerability in message header processing, exposing organizations' entire message queue infrastructure to potential compromise. No public exploit has been identified, but the CVSS 8.1 rating and lack of available patches create a critical exposure window for any organization using affected versions. Immediate compensating controls are required to prevent potential exploitation of mission-critical messaging systems.
No vendor-released patch identified at time of analysis. Interim mitigations: (1) Network controls-restrict producer access to Pulsar brokers via firewall/VPC rules; (2) JVM hardening-remove or restrict Java serialization gadget libraries (commons-collections, commons-beanutils) from classpath; (3) Application protections-implement strict message header validation, enable message encryption and digital signatures; (4) Detection-enhanced logging of deserialization operations with real-time alerting on errors; (5) Isolation-segregate affected systems from sensitive data and critical business systems.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.
EUVD-2026-35909
GHSA-gg69-9wwp-6jx2
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB