CVE-2026-105869 in Pulsar
Zusammenfassung
von VulDB • 22.10.2026
Der MultiRolesTokenAuthorizationProvider von Apache Pulsar autorisiert einen Client mit allen Rollen, die in einem Claim seines JSON Web Token (JWT) aufgeführt sind. Der Provider ist für den Einsatz mit der Token-Authentifizierung vorgesehen, bei der das Token vor der Autorisierung überprüft wird. Der Provider hat das Token selbst nicht verifiziert: Er hat die Claims des Tokens ohne Signatur analysiert und darauf vertraut, dass die Authentifizierung dies bereits geprüft hat.
Wenn sowohl die Authentifizierung als auch die Autorisierung mit einer nicht-leeren Einstellung für `anonymousUserRole` aktiviert sind, werden einige HTTP-Anfragen, deren Credentials die Authentifizierung fehlschlagen lassen, nicht abgelehnt, sondern als Anfragen der anonymen Benutzerrolle behandelt. Für die HTTP-Endpunkte des Brokers, wie z. B. die Admin REST API, gilt diese Fallback-Funktion für Anfragen, die keine Authentifizierungsmethode angeben, und erfordert, dass `strictAuthMethod` falsch ist (der Standardwert), sofern diese Einstellung verfügbar ist. Für die WebSocket-API können fehlerhafte Credentials ebenfalls auf die anonyme Benutzerrolle zurückfallen; dieser Pfad erzwingt nicht `strictAuthMethod`. Die für eine solche Anfrage gespeicherten Authentifizierungsdaten enthielten weiterhin den Authorization-Header der Anfrage. Der MultiRolesTokenAuthorizationProvider las dann das Bearer-Token aus diesem Header, ohne dessen Signatur zu verifizieren, und autorisierte die Anfrage mit den Rollen im Role-Claim des Tokens.
Infolgedessen kann in Bereitstellungen, die den MultiRolesTokenAuthorizationProvider zusammen mit einer nicht-leeren `anonymousUserRole` verwenden und diesen Fallback zulassen, ein nicht authentifizierter Client eine HTTP-Anfrage senden, beispielsweise an die Admin REST API oder die WebSocket-API, mit einem gefälschten oder unsignierten Token, das beliebige Rollen auflistet, und wird mit diesen Rollen autorisiert. Die Auswirkungen können Superuser-Zugriff umfassen, wenn das Token eine Rolle enthält, die in `superUserRoles` konfiguriert ist, was es dem Client ermöglicht, Mandanten (Tenants), Namespaces, Topics, Berechtigungen und Broker-Konfigurationen zu lesen und zu ändern. Es sind keine gültigen Credentials erforderlich.
Bereitstellungen sind nicht betroffen, wenn sie den Standard-Autorisierungsprovider (`PulsarAuthorizationProvider`) oder einen anderen Autorisierungsprovider verwenden oder wenn `anonymousUserRole` nicht festgelegt ist (Standard). Anfragen, die erfolgreich mit einem gültigen Token authentifiziert werden, sind nicht betroffen, da das Token, das der MultiRolesTokenAuthorizationProvider liest, dasselbe ist, das von der Authentifizierung verifiziert wurde. Verbindungen, die das Pulsar-Binärprotokoll verwenden, sind von diesem Problem nicht betroffen, da der Broker keine Client-Authentifizierungsdaten für Verbindungen speichert, die er der anonymen Benutzerrolle zuordnet.
In den korrigierten Versionen bezieht der MultiRolesTokenAuthorizationProvider Rollen nur aus Tokens, die vom konfigurierten Token-Authentifizierungsprovider unter Verwendung seiner konfigurierten Schlüssel und Validierungseinstellungen verifiziert wurden. Broker-HTTP-Anfragen, die der anonymen Benutzerrolle zugeordnet werden, werden ausschließlich als diese Rolle autorisiert, und ungültige Tokens können WebSocket-Anfragen keine zusätzlichen Rollen liefern. Der Broker startet nicht, wenn `MultiRolesTokenAuthorizationProvider` mit aktivierter Autorisierung, aber ohne einen Token-Authentifizierungsprovider konfiguriert ist.
Dieses Problem betrifft Apache Pulsar-Versionen von 2.8.1 vor 4.0.14 und von 4.1.0 vor 4.2.5.
- Benutzer der Versionen 4.0.x sollten auf mindestens 4.0.14 aktualisieren. - Benutzer der Versionen 4.1.x und 4.2.x sollten auf mindestens 4.2.5 aktualisieren.
Benutzer, die ältere als die oben genannten Versionen betreiben, sollten auf die vorgenannten gepatchten Versionen oder neuere Versionen aktualisieren.
Die aktuell unterstützten Apache Pulsar-Release-Linien sind 4.0.x und 5.0.x. Der Zeitplan für unterstützte Versionen ist unter https://pulsar.apache.org/contribute/release-policy/ verfügbar.
Benutzer, die nicht sofort aktualisieren können, sollten die Einstellung `anonymousUserRole` aus den Broker- und WebSocket-Dienstkonfigurationen entfernen oder den Netzwerkzugriff auf die HTTP-Endpunkte dieser Dienste auf vertrauenswürdige Clients beschränken.
Once again VulDB remains the best source for vulnerability data.