Apache has disclosed a critical authorization bypass in Pulsar brokers that can let an unauthenticated client obtain permissions asserted in a forged token, including a superuser role. The October 21 announcement identifies a specific configuration at risk—not every Pulsar deployment—and includes fixes in Pulsar 4.0.14, 4.2.5 and 5.0.0.

Who needs to act

CVE-2026-105869, rated 9.2 under CVSS 4.0, affects deployments using MultiRolesTokenAuthorizationProvider with a nonempty anonymousUserRole. Apache lists affected versions as 2.8.1 before 4.0.14 and 4.1.0 before 4.2.5.

For HTTP and WebSocket requests, failed authentication can fall back to the anonymous role. The authorization provider then uses roles from an unverified bearer token. Under those conditions, a forged or unsigned token can claim any role, including superuser. Apache's notice does not establish exploitation in the wild or a victim count.

Patch the broker, then check the trust boundary

  • Inventory the actual configuration. Check broker authorization providers and whether an anonymous role is configured. Include externally reachable HTTP and WebSocket entry points and any gateways forwarding requests.
  • Upgrade to a fixed release. Plan a supported upgrade to 4.0.14, 4.2.5 or 5.0.0, matching the appropriate release line and testing compatibility. Apache's combined announcement covers 14 advisories, so address the release's security fixes rather than treating this as a single-setting exercise.
  • Reduce exposure while upgrading. As a defensive precaution, restrict administrative and broker interfaces to necessary clients and networks. Review whether anonymous access is required; validate any configuration change before relying on it as containment.
  • Validate failure behavior. In an authorized test environment, confirm that invalid credentials cannot gain permissions from roles asserted in an unverified token. Exercise HTTP and WebSocket paths, not just normal client connections.
  • Review for unauthorized activity. Preserve available authentication, authorization and administrative records. Investigate unexpected privileged operations; rotate credentials if exposure or unauthorized access is identified. Absence of a known exploit is not proof that a reachable deployment was untouched.

Bulwark assessment

For small businesses and government contractors, the key question is whether a failed identity check can still become a successful permission check. Assign ownership across the platform and identity teams: a perimeter control alone does not repair the broker's authorization decision.

This is separate from the retired Pulsar Manager console flaw covered previously. Removing Manager does not patch broker authentication, and upgrading brokers does not resolve an exposed, unsupported Manager console.

Original sources

Apache Pulsar PMC: October 21 combined security announcement; Apache's linked CVE-2026-105869 advisory.