EUVD-2026-107479
GHSA-436h-c7mw-9wgf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach Pulsar Manager over network
-
DeliveryCall unauthenticated superuser-create endpoint
-
ExploitGain full admin account
-
ExecutionProxy requests with cluster credential
-
PersistExfiltrate credential to attacker host
-
ImpactTake full control of Pulsar cluster
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication required for critical functions
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | No special conditions for the core authentication bypass - remote unauthenticated exploitation works against default configurations of Apache Pulsar Manager (versions 0.3.0 and later), where the initial-superuser-creation operation remains reachable and accounts carry no privilege separation. The credential-theft and admin-API-proxy impact additionally requires that Pulsar Manager was configured with an HTTP authentication credential (e.g., a token) or the cluster's token signing key for the target Pulsar cluster; without such a configured credential, the proxy abuse yields no cluster access. The only meaningful limiting factor is network reachability: impact is confined to whoever can reach the Pulsar Manager instance, so deployments restricted to trusted administrator networks are not exposed. There is no fix - risk persists until the deployment is removed. |
| Impact | All exploitability signals point to maximum severity: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes remote, low-complexity, unauthenticated exploitation with no user interaction, and the high impact to both the vulnerable system and subsequent systems (VC/VI/VA:H, SC/SI/SA:H) yields the 10.0 base score - consistent with CWE-306 (missing authentication for a critical function). The technical impact is total: an unauthenticated network attacker can create a superuser account, proxy arbitrary Pulsar admin API calls using the configured cluster credential, and even exfiltrate that credential or token signing key, giving full control of both Pulsar Manager and the backing Pulsar cluster. However, no EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so there is no evidence of active exploitation or automated weaponization at this time - the risk is driven by severity and triviality rather than confirmed in-the-wild activity. A critical mitigating/aggravating nuance: Apache has retired the product with NO fix forthcoming, so the only remediation is decommissioning; exposure is therefore a persistent, unpatchable condition for anyone still running it. Net assessment: a genuine top-priority issue for any environment still exposing Pulsar Manager, but its real-world blast radius is bounded by the product's declining/niche deployment and its being retired rather than widely internet-facing. |
| Exploit ScenarioDerived | An attacker who can reach the Pulsar Manager web console over the network invokes the unauthenticated 'create initial superuser' operation (still available post-initialization) to add their own administrator account and logs in with full privileges. Alternatively, without any account, they abuse the credential-attaching proxy to issue Pulsar admin API calls against the cluster or redirect a proxied request to an attacker-controlled host to capture the configured Pulsar admin credential. No public exploit code was identified in the provided data, but the operations require only ordinary HTTP requests given AV:N/AC:L/PR:N/UI:N. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Unauthenticated remote attackers can take full administrative control of Apache Pulsar Manager 0.3.0 and later by creating an administrator account through an endpoint that remains reachable after initialization, and every account has effective full privileges. In all versions, the manager proxies requests to the Pulsar admin API without enforcing its own authentication and can attach its configured Pulsar credential to a requester-chosen destination, allowing unauthenticated users to perform permitted admin operations and steal the credential. No public exploit code was identified at time of analysis, but the product is retired, unsupported, and will not receive fixes, so exposure persists until deployments are removed.
RemediationAI
No vendor-released patch is available; Apache Pulsar PMC has retired Pulsar Manager and states these issues will not be fixed. Remove existing Pulsar Manager deployments and migrate to an alternative described in https://pulsar.apache.org/docs/administration-ui, and replace any Pulsar HTTP authentication credential or token signing key that was configured in an exposed deployment. Until removal, restrict network access to trusted administrator networks using firewall rules, security groups, or network policies, and do not expose the manager to untrusted networks; placing it behind an authenticating reverse proxy can reduce exposure but does not fix the underlying missing authorization and may not prevent credential forwarding if the application remains reachable. See the vendor advisory at https://pulsar.apache.org/security/CVE-2026-105944/.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Pulsar Manager is a web console for administering Pulsar clusters; it maintains local accounts and can be configured with an HTTP authentication credential or token signing key used to call the Pulsar admin API on behalf of its users. The core issue is CWE-306, missing authentication for a critical function: the initial superuser creation operation is not gated after initialization, proxied admin API routes are not covered by Pulsar Manager's authentication, and the proxy destination is requester-controlled while the manager's configured Pulsar admin credential is attached to the request. Versions 0.3.0 and later also lack privilege separation, so any account, including one created through the unauthenticated endpoint, is effectively administrative; version 0.2.0 checks caller permissions for only some proxied requests. The affected CPE range is cpe:2.3:a:apache_software_foundation:apache_pulsar_manager:*:*:*:*:*:*:*:*.
Know when Apache Pulsar Manager gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Unauthenticated network access with trivial requests (AV:N/AC:L/PR:N/UI:N); compromise of Pulsar Manager pivots to the separate Pulsar cluster via its credential, justifying S:C and full C/I/A:H.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
Apache Pulsar Manager, the web console used to administer Apache Pulsar clusters, carries a maximum-severity flaw that allows a network attacker to seize full administrative control of the manager and extract the Pulsar credential it stores. Because the product has been retired and will never receive a fix, any organization still running version 0.3.0 or later holds permanent exposure until the component is removed. Leadership should treat this as an architectural risk requiring decommissioning rather than a routine patch-cycle item.
No vendor-released patch identified at time of analysis; the product is retired and unsupported, so no fix will be forthcoming. No public exploit identified at time of analysis, but the exposure is permanent until removal. Interim mitigations: isolate or remove Pulsar Manager 0.3.0+ from untrusted networks, front it with an authenticating reverse proxy, block the account-initialization/creation endpoint, rotate the configured Pulsar credential, restrict and monitor the Pulsar admin API for unauthorized operations, and treat decommissioning as the only durable remediation.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB