DataStax Pulsar JMS EUVD-2026-103379

Exploitation requires (1) the attacker to have low-privilege ability to publish JMS messages to a Pulsar destination consumed by a pulsar-jms client (PR:L - not unauthenticated), (2) a consuming application that receives and calls decode on a PulsarObjectMessage (i.e. uses JMS ObjectMessage rather than text/bytes messages), and (3) for meaningful code-execution impact, a suitable deserialization gadget chain present on the consumer's classpath. Limiting factors: the authentication/publish requirement, the need for the consumer to actually process ObjectMessage objects, and the gadget-dependency of impact. Applies to pulsar-jms versions up to and including 9.0.3; no fixed version is available.

This is a Java deserialization flaw (CWE-502) in the decode function of PulsarObjectMessage.java in DataStax pulsar-jms through 9.0.3. The only provided CVSS is a CVSS 4.0 vector (base 5.3, Medium) with AV:N/AC:L/PR:L/UI:N and uniformly Low impact (VC:L/VI:L/VA:L), plus E:P indicating a proof-of-concept exploit exists. POC is confirmed publicly available (GitHub issue #210), but the vulnerability is NOT in CISA KEV and no EPSS score was supplied, so there is no evidence of active or widespread exploitation - exploitation status is 'publicly available exploit code exists,' which is a distinct and weaker signal than in-the-wild use. The PR:L metric means the attacker must be an authenticated/low-privileged participant able to publish an ObjectMessage onto the broker, which materially limits the attacker population compared to an unauthenticated flaw. The most significant tension in the data: CWE-502 Java deserialization of untrusted objects frequently enables remote code execution (which would warrant High impact), yet the VulDB-sourced vector rates all impacts only Low - this likely reflects that real impact is contingent on exploitable gadget chains being present on the consumer's classpath, so the rating is conservative rather than definitive. Net assessment: a legitimate, patch-worthy issue for teams running pulsar-jms, but given authentication requirement, niche library footprint, no KEV listing, and gadget-dependent impact, it is a moderate-priority item rather than a drop-everything emergency.

An attacker with low-privilege access to publish to a Pulsar topic sends a JMS ObjectMessage containing a maliciously crafted serialized Java object. When a consuming application invokes decode in PulsarObjectMessage, the untrusted object is deserialized, and if an exploitable gadget chain exists on the consumer classpath this can escalate to code execution or application compromise. A public proof-of-concept has been disclosed via the project's GitHub issue tracker.