CVE-2026-105930 in Pulsar
Summary
by MITRE • 10/22/2026
When package management is enabled, Pulsar Functions, Sources and Sinks can be registered or updated from a package stored in the Pulsar Packages Management Service by supplying a package URL. The Pulsar Functions worker authorized these requests only against the namespace in which the component was being registered or updated. It did not check whether the requesting user was permitted to access packages in the namespace that the package URL refers to, and it retrieved the package from the broker using the worker's own credentials. The permission check of the Packages Management Service was therefore applied to the worker's identity instead of the requesting user's. Package URLs of transform functions supplied when registering or updating a sink were handled in the same way.
An authenticated user who is permitted to register or update functions, sources or sinks in any namespace of their own tenant could use this to obtain the contents of a package stored in a namespace of another tenant, without having the packages permission on that namespace. The impact is limited to disclosure of package contents, which may include application code, business logic or embedded credentials. The issue does not allow packages to be modified or deleted and does not affect availability.
This issue only affects deployments that have authentication and authorization enabled and in which package management has been enabled: the broker setting enablePackagesManagement and, in current releases, the functions worker setting functionsWorkerEnablePackageManagement. Both settings are disabled by default.
This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.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/.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
Apache Pulsar, a distributed pub-sub messaging system, contains an authorization bypass vulnerability within its Package Management Service that allows authenticated users to access packages stored in namespaces they do not have permission to view. This flaw arises from the way the Functions worker handles requests for registering or updating functions, sources, and sinks when package management is enabled. Specifically, while the worker correctly verifies that a user has permissions to register components within their own namespace, it fails to validate whether the requesting user possesses access rights to the specific namespace where the target package resides. Instead of checking the requester's credentials against the package's location, the system retrieves the package using the worker's elevated privileges and applies permission checks only to the worker identity rather than the initiating user. This architectural oversight effectively bypasses the intended isolation between tenants in multi-tenant deployments.
The technical root cause lies in the decoupling of authentication context from authorization logic during package retrieval operations. When a user supplies a package URL for a transform function or sink, the broker processes this request by authenticating the worker process itself rather than maintaining the original caller's security context throughout the entire operation chain. Consequently, any authenticated tenant member who has basic permissions to create functions in their own namespace can construct a malicious request pointing to a package hosted in another tenant's namespace. Because the system trusts the worker to fetch resources without re-verifying access control for that specific resource against the original user, it grants unauthorized read access to sensitive data stored within those packages. This behavior violates the principle of least privilege and fails to enforce proper cross-namespace isolation boundaries defined by the platform's security model.
The operational impact of this vulnerability is primarily limited to information disclosure rather than system compromise or denial of service. An attacker can exploit this flaw to extract the contents of arbitrary packages stored in other tenants' namespaces. These packages often contain application code, business logic implementations, and potentially embedded credentials such as API keys, database passwords, or cloud provider tokens. While the vulnerability does not permit modification or deletion of existing packages nor does it impact service availability, the exposure of proprietary source code or sensitive configuration data can lead to significant intellectual property theft and further downstream attacks if exposed secrets are leveraged against other systems. The severity is heightened in environments where strict multi-tenant isolation is required for compliance with industry standards such as SOC 2 or ISO 27001, which mandate robust access controls over shared resources.
This vulnerability maps to CWE-862 Missing Authorization and CWE-94 Improper Control of Generation of Code (Code Injection) if the retrieved code were executed in an insecure manner, though here it is strictly a data exposure issue. In terms of MITRE ATT&CK frameworks, this behavior aligns with T1530 Data from Cloud Storage Object as well as aspects of T1078 Valid Accounts since exploitation requires valid authentication but abuses those credentials to access unauthorized resources. The flaw specifically affects deployments where both broker-level and worker-level package management features are explicitly enabled via the enablePackagesManagement and functionsWorkerEnablePackageManagement settings, respectively. It is critical to note that these features are disabled by default in Apache Pulsar releases prior to version 4.0.14 for the 4.0.x line and before 4.2.5 for the 4.1.x and 4.2.x lines. Therefore, organizations running unpatched versions with package management enabled are at risk, while those using default configurations remain unaffected unless they have manually activated these features.
To mitigate this vulnerability, administrators must upgrade Apache Pulsar to version 4.0.14 or later for the 4.0 series, and version 4.2.5 or later for the 4.1 and 4.2 series. For users on older unsupported versions, upgrading to a currently supported release line such as 4.0.x or 5.0.x is strongly recommended to ensure receipt of all security patches. In addition to software updates, organizations should review their package management configurations and disable the enablePackagesManagement settings if not strictly required for operational workflows. Implementing strict network segmentation between tenants and employing runtime application self-protection tools can provide additional layers of defense against potential exploitation attempts. Regular audits of access control lists and monitoring logs for anomalous package retrieval patterns will also help in detecting any unauthorized access activities that may have occurred prior to remediation.