Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.44% for the current model date.
BlackTreeCVE IntelligenceApache Software Foundation · Apache Pulsar
Low technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Low technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Fix not verifiedThe 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.
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.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-863: Incorrect Authorization. The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:NCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 21 Oct 2026 · Last source change 21 Oct 2026, 18:00 UTC · CWE-863 · Incorrect Authorization
Core structured fields are present and their contributing authorities are shown above.