CVE-2026-41732

Content Spoofing
Affects
Spring for Apache Pulsar
in
Spring
No items found.
Versions
>=1.0.0 <=1.0.12, >=1.1.0 <=1.1.17, >=1.2.0 <=1.2.17, >=2.0.0 <=2.0.5
Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

Overview

Spring for Apache Pulsar is the Spring portfolio project that brings core Spring concepts to the development of Apache Pulsar based messaging applications, providing templates, listener containers, and the @PulsarListener annotation for producing and consuming Pulsar messages.

A high-severity vulnerability (CVE-2026-41732) has been identified in Spring for Apache Pulsar. The JsonPulsarHeaderMapper, the default mapper that converts Pulsar message headers to and from Spring MessageHeaders as JSON, evaluated its trusted-packages allow-list with a prefix check, so trusting any package implicitly trusted all of its subpackages. In addition, an empty trusted-packages configuration, which is the out-of-the-box state, fell back to trusting all packages rather than applying a safe default allow-list. Combined with Jackson's default bean deserialization, a producer who can publish messages to a topic consumed by an affected application can supply crafted header values that cause the consumer to deserialize arbitrary JDK types, including classes whose constructors carry side effects such as allocating file descriptors or spawning thread pools.

Per OWASP, with deserialization of untrusted data, data which is untrusted cannot be trusted to be well formed; malformed or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code when deserialized.

This issue affects versions >=1.0.0 <=1.0.12, >=1.1.0 <=1.1.17, >=1.2.0 <=1.2.17, and >=2.0.0 <=2.0.5.

Details

Module Info

Vulnerability Info

When Spring for Apache Pulsar maps inbound message headers, the JsonPulsarHeaderMapper reads a special spring_json_header_types header that records the fully qualified Java type of each header value, then asks Jackson to deserialize each value back to that type. To constrain which types may be reconstructed this way, the mapper checks the requested type against a set of trusted packages in its trusted() method. In affected versions, that check had two weaknesses.

First, the constructor treated the "*" wildcard by simply clearing the trusted-packages set, which made the trust-everything state indistinguishable from the default nothing-configured state:

for (var trusted : trustedPackages) {
    if ("*".equals(trusted)) {
        this.trustedPackages.clear();
        break;
    }
    this.trustedPackages.add(trusted);
}


Second, trusted() returned true for every type whenever the set was empty, and matched configured packages by prefix rather than exact name

protected boolean trusted(String requestedType) {
    if (requestedType.equals(NonTrustedHeaderType.class.getName())) {
        return true;
    }
    if (TRUSTED_ARRAY_TYPES.contains(requestedType)) {
        return true;
    }
    if (this.trustedPackages.isEmpty()) {
        return true;
    }
    var type = requestedType.startsWith("[") ? requestedType.substring(2) : requestedType;
    int lastDot = type.lastIndexOf('.');
    if (lastDot < 0) {
        return false;
    }
    var packageName = type.substring(0, lastDot);
    for (var trustedPackage : this.trustedPackages) {
        if (packageName.equals(trustedPackage) || packageName.startsWith(trustedPackage + ".")) {
            return true;
        }
    }
    return false;
}


Because no trusted packages are configured by default, every consumer using the default header mapper accepted any type name a producer placed in spring_json_header_types. Even applications that did configure trusted packages remained exposed through the prefix match, since trusting a package such as java.util silently extended trust to every subpackage like java.util.concurrent or java.util.logging. Jackson's default bean deserialization will instantiate the requested class and invoke its setters and constructors, so an attacker able to produce messages to a consumed topic could force the application to construct arbitrary JDK classes whose instantiation has side effects, such as objects that allocate file descriptors or spawn thread pools, leading to resource exhaustion and potential further compromise on the consumer.

The remediation evaluates package trust by exact match only, so subpackages must be listed explicitly, and replaces the trust-all fallback with a safe default allow-list of java.lang, java.net, java.util, and org.springframework.util. User-supplied packages are added on top of these defaults, untrusted header types are delivered to the application as NonTrustedHeaderType wrappers instead of being deserialized, and trusting all packages now requires explicitly passing "*". A new pulsarHeaderTrustedPackages bean lets annotation-driven listeners and readers extend the trusted set declaratively.

This vulnerability has existed since Spring for Apache Pulsar 1.0.0.

Mitigation

Spring for Apache Pulsar 1.2.x and 2.0.x receive the fix in the open-source releases 1.2.18 and 2.0.6; the 1.1.x line, along with older lines such as 1.0.x, is past its open-source support window and has no publicly available fix. Users still running an affected line that no longer receives free updates should not attempt to hand-patch the header mapper's trust handling.

To remediate this issue, affected users have two recommended options:

  1. Upgrade to a supported, fixed release of Spring for Apache Pulsar (1.2.18 or 2.0.6).
  2. Adopt HeroDevs Never-Ending Support (NES) for Spring Pulsar, which provides a drop-in compatible build with this vulnerability fixed for release lines that are otherwise end-of-life, with no code changes required. Learn more about HeroDevs Never-Ending Support for Spring and request coverage at https://www.herodevs.com/support/spring-nes.

Credits

  • This issue was discovered internally, per the vendor advisory.
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Medium
ID
CVE-2026-41732
PROJECT Affected
Spring for Apache Pulsar
Versions Affected
>=1.0.0 <=1.0.12, >=1.1.0 <=1.1.17, >=1.2.0 <=1.2.17, >=2.0.0 <=2.0.5
NES Versions Affected
Published date
June 11, 2026
≈ Fix date
June 11, 2026
Category
Content Spoofing
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Spring
Rss feed icon
Subscribe via RSS
or

By clicking “submit” I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.