Apache Pulsar Manager: Missing Authentication for Critical Functionality
CVE-2026-105944 is a critical-severity missing authentication for critical functionality vulnerability in Apache Pulsar Manager from Apache, with a CVSS 4.0 base score of 10.0 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected Apache Pulsar Manager versions: 0.1.0 through 0.4.0. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.7% chance of exploitation within 30 days, higher than 54% of scored CVEs.
Critical severity: a successful attack would have severe impact.
What to do
- Check which version of Apache Pulsar Manager you run against the affected versions below, and install the vendor's latest release.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Apache | Apache Pulsar Manager | 0.1.0 through 0.4.0 | Not stated |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Attack requirements
- NoneThe attack does not depend on a particular deployment or configuration.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Confidentiality (vulnerable system)
- HighSerious loss of confidentiality on the vulnerable system.
- Integrity (vulnerable system)
- HighSerious loss of integrity on the vulnerable system.
- Availability (vulnerable system)
- HighSerious loss of availability on the vulnerable system.
- Confidentiality (other systems)
- HighSerious loss of confidentiality on systems beyond the vulnerable one.
- Integrity (other systems)
- HighSerious loss of integrity on systems beyond the vulnerable one.
- Availability (other systems)
- HighSerious loss of availability on systems beyond the vulnerable one.
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. Scored by CNA (apache.org).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Missing Authentication for Critical Functionality
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
How developers prevent this class of flaw
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator.
- When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data.
More Missing Authentication for Critical Functionality vulnerabilities (CWE-306)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Other references
Recent Missing Authentication for Critical Functionality vulnerabilities
- 8.8 High severity
- 7.5 High severity
- 9.0 Critical severity
- 7.8 High severity
- 7.5 High severity
- 9.1 Critical severity
Spotted an error? Tell us.