CVE-2026-105935 in Pulsar
Summary
by MITRE • 10/21/2026
The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function's configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker's configured broker-client credentials rather than the credentials of the API caller.
When authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function's namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function's own tenant or namespace, and registering a function does not require produce permission on its input topics.
As a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker's broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted.
In fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published.
This issue affects Apache Pulsar versions from 2.0.0-rc1-incubating 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller's permission to manage functions.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The Apache Pulsar distributed streaming platform contains a critical authorization bypass vulnerability within its Functions Worker component that allows authenticated users to publish messages to topics they are not explicitly permitted to access. This flaw resides in the REST API endpoint designed for triggering function execution, which is intended to allow callers to supply values that get published to one of the function's configured input topics. The core technical issue stems from a disconnect between caller authentication and message publishing authorization. When an authenticated user triggers a function via this endpoint, the Functions Worker acts as a broker client to publish the supplied data. Crucially, this publication occurs using the credentials and identity of the Functions Worker itself rather than the identity of the API caller who initiated the request. In versions prior to 2.4.0, there was no authorization check for the trigger endpoint at all, allowing any authenticated user with access to the API to potentially abuse this mechanism if they could guess valid topic names or had other indirect means of influence. Starting in version 2.4.0 and continuing through affected releases up to but not including 4.0.14 and 4.2.5, a partial mitigation was introduced where the system checks whether the caller is authorized to perform function operations within the specific namespace associated with the target function. However, this check is insufficient because it fails to verify that the caller holds produce permissions on the actual input topic to which the message will be published.
This architectural oversight creates a significant integrity risk for data streams managed by Apache Pulsar. Function input topics are not restricted to the tenant or namespace of the function itself, and registering a function does not require the user to have produce permission on those input topics. Consequently, an authenticated user who possesses permissions to manage functions in a given namespace can exploit this gap to cause the Functions Worker to publish messages with caller-controlled content to any topic where the worker's broker-client identity is authorized to produce. This includes topics belonging to other tenants or namespaces that are completely outside the scope of the attacker's intended privileges. The attack does not require any function instance to be actively running nor does it necessitate the execution of arbitrary function code, which simplifies exploitation significantly. The primary condition for a successful exploit is that the Functions Worker's broker-client identity must have produce permissions on the target topic and, in versions 2.3.0 and later, list subscriptions for that topic. This scenario is particularly prevalent when the worker operates with superuser privileges or broad administrative rights to ensure reliable function execution across various topics.
The operational impact of this vulnerability centers entirely on data integrity rather than confidentiality or availability. Consumers subscribed to the affected input topics may receive messages originating from users who are not permitted to publish them, thereby corrupting the trust model of the streaming platform. This can lead to incorrect processing logic in downstream applications that rely on message provenance for security decisions, audit trails, or business rules enforcement. The vulnerability specifically impacts external clients interacting with the Functions Worker REST API and does not alter the fundamental security requirement that function code itself must be fully trusted by administrators. From a classification perspective, this flaw aligns with CWE-269 Improper Privilege Management as it involves an actor obtaining access to resources beyond their authorized scope through misconfigured authorization checks. It also maps to MITRE ATT&CK techniques related to lateral movement or data exfiltration if the attacker can inject malicious payloads into high-value topics, potentially leading to further compromise of downstream systems that consume these streams.
To remediate this issue, users must upgrade Apache Pulsar to version 4.0.14 for the 4.0.x branch or version 4.2.5 and later for the 4.1.x and 4.2.x branches. The fixed versions enforce a stricter authorization model where triggering a function requires the caller to be explicitly authorized to produce to the selected input topic before any message is published, thereby closing the privilege escalation gap. For organizations operating on older versions such as those prior to 2.3.0 or between 2.4.0 and the fixed releases who cannot immediately upgrade due to operational constraints, alternative mitigation strategies are necessary. Users of version 2.4.0 and later with authorization enabled should strictly limit the permission to manage functions in any namespace to highly trusted roles only, reducing the pool of users capable of triggering this endpoint. For versions before 2.4.0 where no caller authorization check exists for function management, access to the Functions Worker REST API must be restricted exclusively to trusted callers through network-level controls or strict identity provider policies. Regular auditing of topic permissions and worker identities is recommended to ensure that broker-client credentials do not possess overly broad produce rights across unrelated tenants.