CVE-2026-105927 in Pulsar
Summary
by MITRE • 10/22/2026
The Apache Pulsar WebSocket service allows a WebSocket consumer to configure a dead letter policy through query parameters of the consumer endpoint, including the deadLetterTopic parameter that names the topic to which messages are written after the maximum number of redeliveries is exceeded. When authorization is enabled, the WebSocket service checks only that the connecting user holds the CONSUME permission on the subscribed topic. It does not check whether the user holds the PRODUCE permission on the topic named in deadLetterTopic. The dead letter messages are then written by the WebSocket service using its own broker client identity rather than the identity of the connecting user.
As a result, an authenticated user who holds the CONSUME permission on at least one topic can cause messages to be written to a topic of their choosing in any existing namespace, including namespaces belonging to other tenants, provided the role used by the WebSocket service to connect to the brokers is authorized to produce to that topic and the topic accepts a producer that registers no schema. The dead letter producer created by the WebSocket service registers no schema, so it is rejected when the target topic has a schema and schema validation is enforced for that topic or its namespace; this setting is not enabled by default. The same user is refused when attempting to produce to that topic directly. Where automatic topic creation is enabled, which is the default, the named topic is created if it does not already exist. The issue can only be triggered when the WebSocket service is enabled, either in the broker (webSocketServiceEnabled, which is disabled by default) or as a standalone WebSocket proxy.
The impact is unauthorized injection of messages into topics the user is not permitted to produce to. The user can determine the content of the injected messages when they also control the messages on the subscribed topic. The issue does not allow reading, modifying or deleting existing messages in the target topic. Injected messages carry the dead letter message properties and a dead letter producer name, so they can be distinguished from messages produced normally; however, the values of these properties are not authenticated and should not be relied upon to establish the origin of a message. Whether an injected message has further consequences depends on how the applications consuming the target topic process it. Repeated injection also consumes storage and backlog capacity in the target namespace.
This issue affects Apache Pulsar versions from 2.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
Users who cannot upgrade immediately and do not require the WebSocket service should disable it. Where the WebSocket service is required, restricting network access to it and limiting the permissions granted to the role the WebSocket service uses to connect to the brokers to the namespaces WebSocket clients are intended to access reduces the exposure.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Apache Pulsar involves a critical authorization bypass within the WebSocket service component, specifically affecting versions from 2.3.0 up to but not including 4.0.14 and from 4.1.0 up to but not including 4.2.5. This flaw allows authenticated users with only CONSUME permissions on a subscribed topic to manipulate the dead letter policy configuration via query parameters, thereby forcing the system to write messages to arbitrary topics that the user is otherwise prohibited from producing to. The core technical failure lies in the asymmetric permission checking logic employed by the WebSocket service when handling dead letter routing. When a consumer configures a deadLetterTopic through the endpoint's query string, the service verifies that the connecting user possesses CONSUME rights for the source topic but completely neglects to validate whether the same user holds PRODUCE permissions for the destination topic specified in the policy. This oversight creates an indirect privilege escalation path where users can inject messages into namespaces and topics belonging to other tenants or restricted areas, provided the underlying broker client identity used by the WebSocket service has sufficient privileges on those target locations.
From a technical perspective, this issue is classified under CWE-269 Improper Privilege Management because it stems from an incorrect enforcement of access control policies during message routing operations. The attack vector leverages the fact that dead letter messages are written using the broker's own client identity rather than the identity of the connecting WebSocket user. Consequently, if the role assigned to the WebSocket service is authorized to produce to a specific topic or namespace, any authenticated consumer can redirect their failed messages there by simply specifying the target in the deadLetterTopic parameter. This mechanism effectively bypasses standard tenant isolation boundaries and authorization checks that would normally prevent direct production attempts by unauthorized users. The vulnerability is particularly insidious because it exploits legitimate functionality designed for error handling, turning a reliability feature into an avenue for data injection across security domains.
The operational impact of this vulnerability centers on the unauthorized injection of messages into topics where the attacker lacks explicit write permissions. An authenticated user can determine the content of these injected messages if they also control the source topic from which the dead letter policy is triggered, allowing them to craft specific payloads that may disrupt downstream applications or pollute data pipelines. While the attack does not permit reading, modifying, or deleting existing messages in the target topic, it significantly compromises data integrity and availability by consuming storage space and backlog capacity within the targeted namespace. Furthermore, injected messages carry properties such as dead letter message attributes and producer names which are not authenticated; relying on these metadata fields to verify message origin is unsafe as they can be manipulated during the injection process. This lack of provenance verification means that downstream consumers cannot reliably distinguish between legitimate system-generated errors and maliciously injected data without additional validation layers, potentially leading to incorrect business logic execution or security policy violations in dependent systems.
In terms of industry standards mapping, this vulnerability aligns with MITRE ATT&CK technique T1565 Data Manipulation, specifically the sub-technique of indirect command injection or data poisoning via trusted services. The attacker utilizes a privileged service component to perform actions that are otherwise restricted, effectively using the WebSocket proxy as an intermediary to bypass access controls. This scenario highlights the risks associated with multi-tenant architectures where shared infrastructure components like message brokers must strictly enforce isolation between tenant workloads. The failure to validate permissions for secondary operations such as dead letter routing represents a significant gap in defense-in-depth strategies, emphasizing the need for comprehensive authorization checks across all data flow paths within distributed messaging systems.
Mitigation strategies primarily involve upgrading to patched versions of Apache Pulsar, specifically version 4.0.14 or later for the 4.0.x branch and 4.2.5 or later for the 4.1.x and 4.2.x branches. For organizations unable to upgrade immediately due to operational constraints, disabling the WebSocket service entirely is recommended if it is not required by their architecture. If the WebSocket service must remain enabled, administrators should restrict network access to limit exposure to untrusted networks and carefully audit the permissions granted to the role used by the WebSocket service for broker connections. This role should be scoped strictly to the namespaces that legitimate WebSocket clients are intended to access, minimizing the blast radius of any potential exploitation. Additionally, enabling schema validation with enforcement at the topic or namespace level can prevent some injection attempts since the dead letter producer created by the vulnerable code path registers no schema and will be rejected if strict schema compliance is mandated. However, this mitigation relies on configuration settings that are not enabled by default and does not address the fundamental authorization flaw, making it a supplementary control rather than a primary fix.