Apache Pulsar Manager is end of life, so discovery must lead to removal
Apache Pulsar Manager is no longer a supported administration interface. The Pulsar project's security advisory for CVE-2026-105944 describes missing authentication and authorization, disclosure of the configured Pulsar admin credential, and a proxy path that does not apply Pulsar Manager authentication to Pulsar admin API requests. The advisory states that Pulsar Manager is retired, has no supported versions, and will not receive further fixes.
The correct response is removal
This is not a case for a long migration project that leaves the interface online in the meantime. Apache's guidance says users should stop using Pulsar Manager, remove existing deployments, and move to an alternative administration UI. The advisory also says deployments that configured a Pulsar credential or token-signing key should consider replacing those secrets.
Until removal is complete, the service should not be reachable from untrusted networks. Restrict access to trusted administrators and record who still depends on it. A reverse proxy login alone does not repair the unsupported application's internal authorization gaps, so the interim control must be a network boundary and a removal plan with an owner.
A bounded ZoomEye observation
On 2026-10-31, app="Apache Pulsar Manager" returned 6 matches and title="Pulsar Manager" returned 10. Both used page 1, page size 1, and sub_type=all. These are small counts in this query scope. They are discovery observations, not confirmed vulnerable instances. The advisory's impact depends on whether the interface is reachable and how it was configured.
The title query may include documentation and references in addition to live managers. The app query is narrower but still requires validation. Neither count replaces ownership data from the organization running the deployment.
Find every deployment path
Search infrastructure inventories, package lists, container images, DNS records, and reverse-proxy configuration for Pulsar Manager. Include side deployments used only for testing. A test instance with production Pulsar credentials can expose the same data even if it is not listed in the primary production inventory.
Trace the credential path. A Pulsar Manager deployment may hold a Pulsar admin credential or a token-signing key. Identify every secret it could access and plan rotation where exposure is possible. Check logs for requests to the manager and to the Pulsar admin API through the proxy. A request from an unexpected source is a reason to investigate, not proof of compromise.
Verify removal
Remove the service and its public route. Confirm that the listener is gone, not merely that the UI returns a new error page. Revoke or rotate secrets that the manager could reach. Remove stale DNS records and update monitoring so the retired service does not trigger false availability alerts.
After migration, verify the replacement UI's authentication and authorization independently. The advisory recommends moving to an alternative administration UI, but the replacement has its own trust model. Do not treat the migration as complete until the new interface has a tested identity boundary and the old one is unreachable.
Record the evidence
Keep the advisory link, the query fields and counts, the collection time, the deployment inventory, and the removal ticket together. ZoomEye can help prioritize an external review, but the finding comes from the unsupported product and its configuration, not from the count alone. Accurate evidence supports a prompt removal decision without overstating what a search result can prove.
Top comments (0)