Pulsar’s Anonymous Fallback Can Carry Superuser Roles
Apache Pulsar can give a failed authentication attempt much more than anonymous access when a particular token authorisation provider is combined with an anonymous fallback. A forged token can supply a role that the server treats as a superuser, without the client holding valid credentials. This is a configuration-dependent flaw, rather than a bypass of every Pulsar login.
Apache rates CVE-2026-105869 Critical, with a CVSS 4.0 score of 9.2. Its public CVE record was published on 21 October. The current advisory identifies corrected releases and separate broker HTTP and WebSocket conditions, which need checking independently.
The fallback retained a token it had not trusted
The affected provider, MultiRolesToken, reads the roles in a JSON Web Token, or JWT. It expected the authentication stage to have checked the token already. Instead, a request that failed authentication could continue as the configured anonymous role while retaining its original authorisation header. The provider then used role claims from that unverified token.
The vulnerable combination requires authentication and authorisation to be enabled, this provider to be selected, and anonymousUserRole to have a non-empty value. Where the fallback is possible, an attacker can submit a forged or unsigned token naming arbitrary roles. If one matches a configured superUserRoles entry, the resulting authority can extend to tenants, namespaces, topics, permissions and broker configuration.
This is a failure to separate authentication evidence from authorisation decisions. A request being assigned to an anonymous role should not give its rejected credentials a second opportunity to provide privileges. Inventory the configured provider and fallback together; the presence of JWT authentication by itself does not answer that question.
Broker HTTP and WebSocket are different paths
For broker HTTP endpoints, including the administration REST API, Apache describes requests that do not name an authentication method. The fallback also requires strictAuthMethod to be false, its default where the option is available. The WebSocket path does not enforce that option. Changing that broker setting therefore must not be treated as verification that the WebSocket service is protected.
The advisory excludes deployments using the default PulsarAuthorizationProvider or another authorisation provider. It also excludes an unset anonymous role, the default, and requests successfully authenticated with a valid token. Connections using Pulsar’s binary protocol are outside this issue because their anonymous fallback does not retain the same client authentication data. These are specific scope limits, not an assessment of unrelated weaknesses.
A security fix and a supported release are separate decisions
Apache lists affected versions from 2.8.1 up to, but excluding, 4.0.14, and from 4.1.0 up to, but excluding, 4.2.5. Its stated correction is at least 4.0.14 for 4.0.x users, and at least 4.2.5 for 4.1.x or 4.2.x users. Older deployments need an applicable patched or newer release, with their upgrade route checked.
The current release policy identifies 4.0.x and 5.0.x as supported lines. The 4.0 LTS line’s active support ended on 21 October 2026, while security support continues until 21 October 2027. Support for 4.2 ended on 24 September 2026. Apache can make occasional older-branch releases on a best-effort basis; a 4.2 fix does not restart that line’s support period.
Plan migration using the project’s compatibility rules, not just a comparison between version numbers. The policy calls for linear upgrades and testing the actual cluster configuration in staging. A maintenance decision should retain the supported route and recovery conditions for the cluster, its clients and its components.
Verify the failed-authentication path after maintenance
In the corrected behaviour, roles come only from tokens verified by the configured token authentication provider. Broker requests assigned to the anonymous role retain only that role’s permissions, while invalid tokens cannot add WebSocket roles. There is also a startup consequence: a broker using this multi-role provider with authorisation enabled will not start without a token authentication provider. Check that dependency before a rollout.
For an immediate interim measure, Apache recommends removing anonymousUserRole from both broker and WebSocket service configurations, or restricting their HTTP endpoints to trusted clients. Review the effect on legitimate users and retain a recoverable configuration. Restricting only one service leaves the other path to assess.
After authorised maintenance, verify the running release, the actual provider and anonymous-role settings, and the outcome of failed authentication on both relevant services. Keep evidence of earlier privileged changes separate from the patch result. The advisory describes what an attacker could do; it does not establish that a particular deployment has been compromised.
Sources: the Apache advisory linked above, the project’s release policy and its published CVE Program record.
