CVE-2026-105944 in Pulsar Manager
Summary
by MITRE • 10/21/2026
Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:
- The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later. - Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager's authentication. Version 0.2.0 checks the caller's permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager. - The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user's choosing, and the credential can then be used directly against the Pulsar cluster. - In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.
The impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.
Apache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.
Using Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.
Until a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
Apache Pulsar Manager serves as a web-based console for administering Apache Pulsar clusters, providing user accounts and login capabilities while utilizing configured HTTP authentication credentials or tokens to proxy requests to the underlying Pulsar admin API on behalf of users. However, significant security vulnerabilities exist within this architecture that allow unauthenticated attackers to gain full administrative control over both the management interface and the connected cluster infrastructure. These flaws stem from a fundamental failure in access control logic, specifically involving uninitialized state handling, insufficient authentication checks for proxied requests, insecure direct object references leading to credential leakage, and flat privilege models that ignore role distinctions.
The most critical vulnerability lies in the initialization process of the application. The operation required to create the initial administrator or superuser account is accessible without any form of prior authentication. Crucially, this endpoint remains active even after the instance has been initialized, meaning it does not disable itself once an admin exists. This design flaw allows anyone with network access to the Pulsar Manager interface to create a new administrative account at any time and subsequently log in using those credentials. This behavior aligns with CWE-284 Improper Access Control, as the system fails to enforce proper restrictions on privileged actions during critical setup phases or post-initialization states.
Beyond initial account creation, the application exhibits severe deficiencies in how it handles authentication for requests proxied to the Pulsar cluster itself. In versions prior to 0.3.0 and partially in later versions, requests sent by Pulsar Manager to the configured Pulsar admin API are not subject to Pulsar Manager's own authentication mechanisms. While version 0.2.0 attempted to check caller permissions for some endpoints, it failed to do so comprehensively. Consequently, an unauthenticated user can exploit this gap to send arbitrary commands to the Pulsar cluster through the manager proxy. The cluster processes these requests using the high-privilege credential configured within Pulsar Manager, effectively allowing attackers to perform any administrative operation that the managed credentials permit, such as creating topics, managing permissions, or altering configurations.
A related and equally dangerous flaw involves insecure direct object references and potential credential leakage through URL manipulation. The destination of a proxied request can be influenced by the requester, and Pulsar Manager automatically attaches its configured Pulsar admin credential to these outgoing requests. An unauthenticated user can manipulate the target host in their request, causing Pulsar Manager to forward the sensitive administrative credentials to an arbitrary server controlled by the attacker. This allows the attacker to capture or misuse the Pulsar cluster's authentication token directly against other services or clusters, representing a severe breach of confidentiality and integrity consistent with CWE-209 Generation of Error Message Containing Sensitive Information if error responses leak data, though primarily it is an issue of insecure configuration leading to credential exposure.
In versions 0.3.0 and later, the application fails to distinguish between different privilege levels among its user accounts. Every account created within the system, including those generated via the unauthenticated initialization flaw, effectively possesses full administrative privileges in Pulsar Manager. This flat permission model means there is no concept of least privilege; once an attacker gains access through any vector, they have unrestricted control over all features and functions available to administrators. This lack of role-based access control exacerbates the impact of the other vulnerabilities, ensuring that initial compromise leads immediately to total system takeover.
The operational impact of these combined flaws is severe depending on the deployment context. In versions 0.3.0 and later, any user who can reach Pulsar Manager over a network can take full control of the management interface itself. Across all affected versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any reachable user can perform administrative operations on that cluster using the manager's elevated privileges. Furthermore, if the manager is configured with the token signing key of a Pulsar cluster, an administrator account (which attackers can easily create) can generate valid tokens for the entire cluster, granting persistent access to the underlying messaging infrastructure even after initial credentials are rotated or revoked.
It is imperative to note that Apache Pulsar Manager has been officially retired by the Apache Pulsar Project Management Committee and is no longer maintained or supported. There are no further releases, fixes, or security updates available for any version of this software. The vulnerabilities described herein will not be patched because development has ceased entirely. This status renders the application fundamentally unsafe for use in any production environment where network exposure exists.
Users are strongly advised to cease using Pulsar Manager immediately and remove all existing deployments from their infrastructure. Migration should occur toward alternative administration interfaces recommended by the Apache Pulsar project, such as those detailed in the official Administration UI documentation. For organizations that have previously exposed Pulsar Manager configured with a Pulsar credential or token signing key, it is critical to rotate and replace these credentials immediately to mitigate any potential compromise resulting from past exposure. Until deployments are fully decommissioned, network access must be strictly restricted to trusted administrators via firewalls or private networks, although removal remains the only secure long-term solution.