Apache Pulsar Manager has no safe upgrade destination. The Apache Pulsar PMC’s October 21 announcement identifies CVE-2026-105944, rated CVSS 4.0 10.0, across every released Manager version, 0.1.0 through 0.4.0. The console is retired and unsupported; Apache says these issues will not be fixed and directs operators to remove existing deployments.

The console can expose the cluster’s authority

Pulsar Manager is a separate web administration console, not the Pulsar broker itself. An unauthenticated requester can abuse its proxy to perform cluster-admin operations using the HTTP credential configured in Manager. The requester can also choose a destination that receives that credential. Impact therefore follows the credential’s permissions; it is not automatically identical across deployments.

In Manager 0.3.0 and later, network-reachable users can create an additional administrator without authentication, even after initialization. Accounts effectively receive full Manager privileges. Where Manager holds a cluster token-signing key, a Manager administrator can create cluster tokens.

Remove the component, recover the trust

Apache recommends limiting access to trusted administrators until removal and considering replacement of credentials or signing keys configured in an exposed deployment. Current Apache documentation confirms the retirement, provides alternative administration UIs and says Helm-chart users can disable the pulsar_manager component.

Those instructions address different boundaries. Removing the console closes that access path; replacing exposed authority addresses what could remain usable afterward.

Bulwark priorities for small teams

  • Find the actual deployment. Check cluster inventories, Helm values, containers and old operations environments. Assign an owner to each console and document which cluster it can reach. An unused UI is still relevant if its credential remains valid.
  • Preserve before dismantling. Retain available access logs, configuration history and relevant cluster audit records through your normal incident process. Record exposure dates and permission scope without copying secret values into tickets or chat.
  • Plan credential retirement. Identify every consumer before replacement, validate the new least-privilege path, and confirm the old authority no longer works. Signing-key changes need coordinated token and client planning; a rushed change can interrupt legitimate workloads.
  • Verify the replacement boundary. Evaluate the alternative UI’s authentication, authorization and secret handling before deployment. Do not transfer a broadly privileged credential unchanged simply to restore a familiar dashboard.

Evidence limits

The announcement establishes critical weaknesses, not a confirmed intrusion in any particular cluster. It does not establish in-the-wild exploitation. Manager removal is not a substitute for separately maintaining the Pulsar broker and other components.

Original sources: Apache PMC announcement mirrored on oss-sec, October 21 at 20:32:29 UTC; original Apache mailing-list thread; Apache administration UI documentation.