CVE-2026-105936 in Pulsar
Summary
by MITRE • 10/21/2026
The Pulsar Functions worker REST API provides two endpoints that return the catalog of Pulsar IO connectors installed on the functions worker: the worker connectors endpoint (/admin/v2/worker/connectors) and the deprecated functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors). When authorization is enabled, the worker connectors endpoint requires super-user access. The functions connectors endpoint, served both by the functions worker and by a broker running the functions worker, returns the same catalog without this check.
As a result, when authentication and authorization are enabled, any authenticated client can read the connector catalog through the functions connectors endpoint, regardless of the permissions granted to its role and without super-user access. Unauthenticated requests are rejected unless anonymous access is configured with an anonymous user role.
The catalog contains the connector type definitions installed in the functions worker's connectors directory: the connector name, its description, and the source, sink and configuration class names. It does not contain configured source or sink instances, their configuration values or credentials, and an installed connector type does not indicate that a connector is configured or running. The impact is limited to disclosure of this metadata, which can include the names and descriptions of custom connectors installed by the operator. The issue does not allow modifying the catalog or managing connectors. Connector definitions that have a source or sink class are also returned by the built-in sources and sinks endpoints to authenticated clients.
In fixed versions, the functions connectors endpoint applies the same checks as the worker connectors endpoint, so that it requires super-user access when authorization is enabled. Clients that are not super-users can use the built-in sources and sinks endpoints to list the available connector types.
This issue affects Apache Pulsar versions from 2.4.1 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/.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
Apache Pulsar, a distributed pub-sub messaging platform, contains an authorization bypass vulnerability within its Functions worker REST API that allows authenticated users to access sensitive metadata without proper privileges. This flaw specifically affects the deprecated functions connectors endpoints located at /admin/v2/functions/connectors and /admin/v3/functions/connectors. While the newer worker connectors endpoint correctly enforces super-user access requirements when authentication and authorization are enabled, the legacy functions connectors endpoints fail to perform this critical security check. Consequently, any authenticated client can retrieve a comprehensive catalog of Pulsar IO connectors installed on the functions worker, regardless of their assigned role or permission level. This inconsistency in access control logic creates an unauthorized information disclosure vector that undermines the intended security boundaries of the system.
The technical root cause lies in the divergent implementation of authorization checks between two related API endpoints within the same service component. The worker connectors endpoint properly validates super-user status before returning data, adhering to the principle of least privilege and ensuring that only administrators can view installed connector definitions. In contrast, the functions connectors endpoint serves identical catalog information but lacks this verification step. This discrepancy allows attackers who have obtained valid authentication credentials for a low-privilege account to enumerate all available connector types. The vulnerability is particularly insidious because it does not require exploitation of complex logic flaws or buffer overflows; rather, it relies on a simple oversight in the access control middleware that fails to apply consistent security policies across functionally similar endpoints.
The operational impact of this vulnerability is primarily informational disclosure rather than direct system compromise or data exfiltration. The returned catalog includes connector type definitions such as names, descriptions, and class names for sources, sinks, and configurations installed in the functions worker's connectors directory. This metadata can reveal details about custom connectors developed by operators, potentially exposing proprietary logic or internal architectural patterns to unauthorized parties. However, the vulnerability does not expose configured source or sink instances, their specific configuration values, nor any stored credentials. Furthermore, an installed connector type definition does not indicate that a connector is currently active or running. Therefore, while this information aids in reconnaissance and planning for further attacks, it does not directly lead to data leakage or service disruption on its own.
From a threat modeling perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting an authorization bypass where standard user privileges are insufficiently enforced against administrative endpoints. It also maps to the ATT&CK technique T1087 Account Discovery, as it allows adversaries to enumerate system components and capabilities available within the environment. The disclosure of custom connector names and class structures can assist attackers in identifying potential attack surfaces or understanding the specific integrations used by an organization, thereby facilitating more targeted subsequent attacks such as supply chain compromises or configuration-based exploits against known vulnerable connectors.
Mitigation for this issue requires upgrading Apache Pulsar to patched versions that enforce consistent authorization checks across all connector-related endpoints. Users operating version 4.0.x must upgrade to at least version 4.0.14, while users on the 4.1.x and 4.2.x release lines should upgrade to at least version 4.2.5. In these fixed versions, the functions connectors endpoint applies the same super-user access requirements as the worker connectors endpoint when authorization is enabled. For organizations unable to immediately patch their systems, a temporary mitigation involves restricting network-level access to the affected endpoints or ensuring that anonymous access is strictly disabled and no low-privilege accounts are granted any level of authentication against the Pulsar admin API until an upgrade can be performed. Regular auditing of REST API endpoint permissions and adherence to industry standards for consistent authorization enforcement across all service interfaces are recommended practices to prevent similar discrepancies in future deployments.