CVE-2026-105944 · Apache Pulsar Manager unauthenticated admin creation and credential…

01 · The Real Story

Someone left the master key hanging on an unlocked front door of a house they already moved out of

CVE-2026-105944 bundles four distinct authentication and authorization failures in Apache Pulsar Manager versions 0.1.0 through 0.4.0 — which is every version ever released. The superuser-creation endpoint requires no authentication and remains open even after initialization, meaning anyone with network access can mint an admin account at will (v0.3.0+). Worse, Pulsar Manager proxies requests to the configured Pulsar cluster's admin API *without enforcing its own authentication*, and the destination of the proxied request is attacker-controllable — so the tool will happily attach your Pulsar admin credential to a request aimed at an attacker-owned host. The result: unauthenticated credential theft, full Pulsar cluster admin access, and complete console takeover.

The Apache CNA scored this CVSS 4.0 / 10.0, and the raw technical impact is real — zero-auth, network-reachable, credential-leaking. However, the CVSS 4.0 perfect score assumes maximal accessibility. In practice, Pulsar Manager is a niche administration console (~540 GitHub stars, fraction of Pulsar deployments) that should never be internet-facing. The product was simultaneously retired and declared EOL with the disclosure — no patch will ever ship. For the small population still running it, the severity is genuinely high: the exploit is trivial and the blast radius extends to the underlying Pulsar cluster. But calling this a universal CRITICAL overstates the reachable population. We assess it HIGH at 8.5 for organizations that actually run it, with an urgent directive to decommission.

"EOL admin console with zero auth gates your Pulsar cluster credentials. Rip it out."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach Pulsar Manager web interface

The attacker identifies a reachable Apache Pulsar Manager instance, typically listening on port 7750. In most deployments this should be an internal service, but misconfigured environments, flat networks, or cloud misconfigurations can expose it. No tooling beyond a browser or curl is needed.

Conditions required:

Network path to Pulsar Manager (default port 7750)

Where this breaks in practice:

Pulsar Manager is an internal admin tool; competent deployments restrict access to admin VLANs
Very small installed base (~540 GitHub stars) limits target population
Most Pulsar operators use CLI or alternative UIs, not Pulsar Manager

Detection/coverage: Network scanners (Shodan/Censys) can identify exposed instances by fingerprinting the /ui/index.html or /pulsar-manager/csrf-token endpoints.

STEP 02

Create unauthenticated admin account

On versions 0.3.0+, the attacker sends an unauthenticated PUT to /pulsar-manager/users/superuser with a chosen username and password. The endpoint remains available even after initial setup, so the attacker creates a new admin account alongside any legitimate ones. On versions prior to 0.3.0, this step is skipped since the proxy abuse in step 3 requires no account at all.

Conditions required:

Step 1 completed
Pulsar Manager v0.3.0+ for account creation (all versions for proxy abuse)

Where this breaks in practice:

None once network access is achieved — the endpoint has zero authentication

Detection/coverage: Audit logs (if enabled) would show unexpected user creation; however, Pulsar Manager's logging is minimal.

STEP 03

Abuse unauthenticated admin API proxy

The attacker sends requests through Pulsar Manager's proxy endpoint without authenticating. Pulsar Manager forwards these requests to the configured Pulsar cluster's admin API, attaching the stored HTTP authentication credential. The attacker can now enumerate tenants, namespaces, topics, subscriptions, and perform any administrative operation on the Pulsar cluster.

Conditions required:

Step 1 completed
Pulsar Manager has a configured Pulsar cluster with admin credentials

Where this breaks in practice:

None — the proxy does not enforce Pulsar Manager authentication on proxied requests

Detection/coverage: Pulsar broker audit logs would show admin API calls from the Pulsar Manager service IP; anomalous volume or unusual operations might trigger alerts if monitored.

STEP 04

Exfiltrate Pulsar admin credential

The attacker crafts a proxied request specifying an attacker-controlled host as the destination. Pulsar Manager blindly attaches the configured Pulsar admin credential to this outbound request (SSRF + credential relay). The attacker captures the credential on their server. This credential can then be used directly against the Pulsar cluster, bypassing Pulsar Manager entirely.

Conditions required:

Step 1 completed
Pulsar Manager can make outbound HTTP requests to attacker-controlled host

Where this breaks in practice:

Egress filtering or network segmentation could block outbound connections to external hosts
Credential may be a short-lived token rather than a long-lived password in well-configured deployments

Detection/coverage: Network monitoring for unexpected outbound HTTP requests from the Pulsar Manager host to external IPs. DLP or SSRF-detection rules at the proxy/firewall layer.

STEP 05

Direct Pulsar cluster compromise

With the stolen admin credential, the attacker authenticates directly to the Pulsar cluster admin API. They can create/delete tenants, read/write to topics, modify retention policies, extract message data, create backdoor subscriptions, or destroy cluster configuration. The blast radius is the entire Pulsar messaging infrastructure managed by this credential.

Conditions required:

Stolen credential from step 4 OR proxy access from step 3
Network path to Pulsar broker admin API

Where this breaks in practice:

If credential was rotated or is a short-lived token, the window may be limited
Network segmentation between Pulsar Manager network and direct broker access may limit step 4 utility

Detection/coverage: Pulsar broker audit logs showing admin operations from unexpected source IPs or at unusual times.

03 · Compensating Control

HIGH 8.5→IGNORE 0.0

SEVERITY REDUCED

Decommission Pulsar Manager entirely — The product is permanently EOL with no fix forthcoming. The only true remediation is removal. Disable the pulsar_manager component in your Helm chart or stop/remove the container/service. Migrate to the Pulsar CLI (pulsar-admin), StreamNative Console, or other alternatives listed at pulsar.apache.org/docs/administration-ui. Per noisgate mitigation SLA for HIGH, begin decommission within 30 days; complete removal within 180 days (remediation SLA).

HIGH 8.5→MEDIUM 5.5

SEVERITY REDUCED

Place Pulsar Manager behind an authenticating reverse proxy immediately — If decommission cannot happen within days, deploy an authenticating reverse proxy (e.g., OAuth2 Proxy, Authelia, or cloud IAP) in front of Pulsar Manager to enforce authentication before any request reaches the application. This breaks attack path steps 2-4 by requiring valid credentials before the unauthenticated endpoints are reachable. Deploy within 30 days per noisgate mitigation SLA for HIGH.

HIGH 8.5→MEDIUM 4.5

SEVERITY REDUCED

Restrict network access to Pulsar Manager to admin-only VLAN/security group — Firewall Pulsar Manager (default port 7750) so only authorized administrator IPs or jump hosts can reach it. This reduces the attacker population to those who have already compromised an admin workstation or jump host. Deploy within 30 days per noisgate mitigation SLA for HIGH.

HIGH 8.5→HIGH 7.0

Rotate Pulsar admin credentials configured in Pulsar Manager — Assume the configured Pulsar admin credential may already be compromised. Rotate the HTTP authentication credential or token-signing key used by Pulsar Manager to authenticate to the Pulsar cluster. This limits the blast radius of any past exploitation. Do this immediately regardless of other controls.

HIGH 8.5→HIGH 7.5

Block Pulsar Manager outbound HTTP to non-Pulsar hosts — Apply egress filtering so the Pulsar Manager host can only communicate with known Pulsar broker endpoints. This breaks the credential-exfiltration SSRF vector in attack path step 4 by preventing Pulsar Manager from sending the admin credential to attacker-controlled hosts.

What doesn't work

Patching / upgrading Pulsar Manager — no patch exists and never will. The product is permanently retired by Apache. All versions are vulnerable.
WAF rules — the exploitation uses legitimate API endpoints with standard HTTP methods (PUT, GET) and JSON payloads. There are no malicious payloads or injection patterns for a WAF to detect.
Pulsar Manager's built-in authentication — the vulnerability IS the absence of authentication on critical endpoints. The built-in auth does not protect the affected code paths.
Rate limiting — a single request is sufficient for account creation or credential theft. Rate limiting provides no meaningful protection.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	Not observed. No known campaigns. Not listed on CISA KEV. Disclosed 2026-10-21 — only one day old at time of assessment.
Proof-of-concept	No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-105944), ExploitDB, and nuclei templates. However, exploitation is trivially reproducible with `curl` — a single unauthenticated HTTP PUT creates an admin account; no weaponized tooling is needed.
EPSS score	Not yet assigned. CVE was published 2026-10-21; EPSS typically populates within days. Given the niche product and trivial-but-targeted nature, expect a low-to-moderate EPSS probability.
KEV status	Not listed as of 2026-10-22.
CVSS vector	CVSS 4.0: `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` = 10.0 (Apache CNA). No CVSS 3.1 vector published. The 4.0 score reflects maximum theoretical impact without accounting for deployment context.
Affected versions	All releases: Apache Pulsar Manager 0.1.0 through 0.4.0. Version 0.3.0+ additionally vulnerable to unauthenticated admin account creation and privilege escalation (no privilege separation between account types).
Fixed versions	None. Product is EOL. Apache Pulsar PMC retired Pulsar Manager simultaneously with disclosure. No patch, no future releases. Maven artifact: `org.apache.pulsar:pulsar-manager`.
Internet exposure	Very low. ~540 GitHub stars, 239 forks. Niche admin console for Apache Pulsar operators. No specific Shodan/Censys/FOFA exposure data found, consistent with a tool that should only exist on internal networks. If you find one internet-facing, it is almost certainly misconfigured.
Disclosure date	2026-10-21. Disclosed by Apache Pulsar PMC concurrent with project retirement announcement.
Reporter	Apache Pulsar PMC (self-disclosed during EOL retirement audit). No external researcher credited.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (8.5/10)

Why this verdict

Zero-authentication exploitation: All four flaws require no credentials and no user interaction. An attacker with network access can create admin accounts, proxy admin API requests, and steal credentials with nothing more than curl. This keeps the floor firmly above MEDIUM.
Credential theft extends blast radius beyond the console: The SSRF-style credential relay means compromising Pulsar Manager compromises the underlying Pulsar cluster itself — message data, topic configuration, tenant administration. The impact is not contained to a web UI.
EOL with no fix ever: Unlike most CVEs where you patch and move on, this product is permanently abandoned. Every day it remains deployed is a day of unmitigated exposure. This is a permanent vulnerability.
Role multiplier: Apache Pulsar Manager's deployment role is (a) admin console for Pulsar messaging clusters, not a canonical high-value-role component like an IdP, hypervisor, or DC. (b) In its typical role, compromising it yields Pulsar cluster admin access — impacting message integrity, confidentiality, and availability for that cluster. (c) In a high-value role where Pulsar is a critical streaming backbone (financial event processing, telemetry pipelines), the blast radius extends to data integrity for all downstream consumers — but remains bounded to the Pulsar ecosystem, not fleet-scale or domain-scale. Approximately 100% of Pulsar Manager installs are vulnerable (no patched version exists), but the overall installed base is very small. The floor is HIGH given the credential-theft-to-cluster-compromise chain, but does not reach CRITICAL because the component is not itself a canonical high-value-role system.
Small installed base limits population risk: ~540 GitHub stars and a deprecated product mean the total number of vulnerable deployments is small and shrinking. This is not a ubiquitous component.
Internal-only expected deployment: Pulsar Manager is an admin tool that should never be internet-facing. Most exploitation requires prior internal network access or a misconfigured cloud deployment, which adds a compounding friction factor.

Why not higher?

CRITICAL would require either a canonical high-value-role component (this is a niche admin console, not an IdP or hypervisor) or a fleet-scale blast radius. Pulsar Manager's compromise extends to the Pulsar cluster it manages — significant but bounded. The very small installed base (~540 stars, deprecated project) means the total population at risk is tiny. Internal-only expected deployment adds friction for external attackers.

Why not lower?

The zero-authentication, network-reachable credential theft chain is too powerful for MEDIUM. Once reached, exploitation is instant and grants full Pulsar cluster admin access. The permanent EOL status means this exposure never gets patched — only decommissioning resolves it. Any organization still running Pulsar Manager has an open door to their messaging infrastructure that will never close on its own.

06 · Verification

Crowdsourced verification payload.

Run from any auditor workstation or jump host with network access to the Pulsar Manager instance. No special privileges required. Non-destructive — does not create accounts or modify state. Usage: bash check_cve_2026_105944.sh http://pulsar-mgr.internal:7750

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash\n# CVE-2026-105944 Checker - Apache Pulsar Manager Missing Authentication\n# Non-destructive: probes read-only endpoints only.\n# Exit 0 = check complete, 2 = unknown, 3 = usage error\nset -euo pipefail\n\nif [ $# -lt 1 ]; then\n  echo \"Usage: $0 <PULSAR_MANAGER_URL>\"\n  echo \"Example: $0 http://pulsar-mgr.internal:7750\"\n  exit 3\nfi\n\nTARGET=\"${1%/}\"\necho \"[*] Probing ${TARGET} for Apache Pulsar Manager...\"\n\n# Probe 1: CSRF token endpoint (present on all Pulsar Manager versions)\nCSRF_CODE=$(curl -s -o /dev/null -w \"%{http_code}\" --connect-timeout 5 \"${TARGET}/pulsar-manager/csrf-token\" 2>/dev/null || echo \"000\")\necho \"[*] CSRF endpoint: HTTP ${CSRF_CODE}\"\n\nif [ \"$CSRF_CODE\" = \"000\" ]; then\n  echo \"[!] Cannot connect to ${TARGET}\"\n  echo \"UNKNOWN\"\n  exit 2\nfi\n\n# Probe 2: Unauthenticated environments list (read-only)\nENV_CODE=$(curl -s -o /dev/null -w \"%{http_code}\" --connect-timeout 5 \"${TARGET}/pulsar-manager/environments\" 2>/dev/null || echo \"000\")\necho \"[*] Environments endpoint: HTTP ${ENV_CODE}\"\n\n# Probe 3: Check login page for Pulsar Manager fingerprint\nLOGIN_BODY=$(curl -s --connect-timeout 5 \"${TARGET}/ui/index.html\" 2>/dev/null || true)\nHAS_PULSAR=$(echo \"$LOGIN_BODY\" | grep -ci \"pulsar\" 2>/dev/null || echo \"0\")\n\n# All versions 0.1.0-0.4.0 are vulnerable. No patched version exists.\nif [ \"$CSRF_CODE\" = \"200\" ] || [ \"$HAS_PULSAR\" -gt 0 ] 2>/dev/null; then\n  echo \"============================================\"\n  echo \"VULNERABLE\"\n  echo \"============================================\"\n  echo \"[!] Apache Pulsar Manager detected.\"\n  echo \"[!] ALL versions (0.1.0-0.4.0) are affected.\"\n  echo \"[!] CVE-2026-105944: Zero-auth admin creation,\"\n  echo \"    API proxy abuse, and credential theft.\"\n  echo \"[!] Product is EOL. No patch exists or will exist.\"\n  echo \"[!] ACTION: Decommission Pulsar Manager immediately.\"\n  if [ \"$ENV_CODE\" = \"200\" ]; then\n    echo \"[!] CONFIRMED: Unauthenticated API access verified.\"\n  fi\n  exit 0\nfi\n\nif echo \"$CSRF_CODE\" | grep -qE \"^[23]\"; then\n  echo \"[?] Service responded but could not confirm Pulsar Manager.\"\n  echo \"[?] If this IS Pulsar Manager, it is VULNERABLE (no fix exists).\"\n  echo \"UNKNOWN\"\n  exit 2\nfi\n\necho \"[+] Target does not appear to be running Pulsar Manager.\"\necho \"PATCHED\"\nexit 0