CVE-2026-105938 in Pulsar
Zusammenfassung
von VulDB • 21.10.2026
In Apache Pulsar-Namesspaces können eingeschränkt werden, welche Rollen ein Abonnement verwenden dürfen, entweder durch den Authentifizierungsmodus „Prefix-Abonnement“, der erfordert, dass der Name des Abonnements mit dem Rollennamen beginnt, oder durch die Gewährung von Berechtigungen für bestimmte Rollen. Topic-Ebene-Abooperationen wie das Konsumieren, Überspringen von Nachrichten, Zurücksetzen eines Cursors oder Löschen eines Abos wenden diese Abo-Richtlinien an. Mehrere Admin-REST-API-Vorgänge, die sich auf Abonnements beziehen, haben sie jedoch nicht angewendet:
- Die Backlog-Bereinigungsvorgänge auf Namespace-Ebene und Bundle-Ebene, sowohl für ein benanntes Abonnement als auch für alle Abonnements; - Die Unsubscribe-Vorgänge (Abbestellen) auf Namespace-Ebene und Bundle-Ebene; - Der Vorgang auf Topic-Ebene, der Nachrichten für alle Abonnements eines Topics ablaufen lässt.
Bei Verwendung des Standard-Autorisierungsanbieters erfordern die Vorgänge auf Namespace-Ebene nur die Konsumberechtigung (consume permission), die dem Namespace gewährt wurde, und der Expire-all-Vorgang erfordert lediglich die Konsumberechtigung für das Topic. Infolgedessen kann ein authentifizierter Benutzer mit einer solchen Konsumberechtigung den Backlog löschen, Nachrichten ablaufen lassen oder ein Abonnement löschen, wenn Authentifizierung und Autorisierung aktiviert sind und ein Namespace den Prefix-Abonnement-Authentifizierungsmodus oder Abo-Berechtigungen verwendet. Die Richtlinien würden einem solchen Benutzer diese Aktionen verwehren. Ein Tenant-Admin-Zugriff oder Superuser-Zugang ist nicht erforderlich. Die Backlog-Bereinigungsvorgänge können auch auf die für Geo-Replikation verwendeten Cursors angewendet werden, sodass Nachrichten, die noch nicht in einen Remote-Cluster repliziert wurden, übersprungen werden. Bereitstellungen, die den Prefix-Abonnement-Authentifizierungsmodus oder Abo-Berechtigungen (die Standardwerte) nicht konfigurieren, sind von dieser Umgehung nicht betroffen, da eine Konsumberechtigung für das Namespace oder Topic diese Vorgänge dort bereits erlaubt. Diese Auswirkungsanalyse geht davon aus, dass Pulsar mit dem standardmäßigen Autorisierungsanbieter konfiguriert wurde. Für benutzerdefinierte Autorisierungsanbieter könnte die Auswirkung anders sein.
Die Integrität des Abo-Zustands ist betroffen. Das Löschen oder Ablaufenlassen des Backlogs verschiebt den Cursor des Abonnements nach vorne, sodass nicht bestätigte Nachrichten nicht mehr an die Konsumenten des Abonnements ausgeliefert werden. Der Unsubscribe-Vorgang löscht ein Abonnement, das keine verbundenen Konsumenten hat. Übersprungene Nachrichten können dauerhaft gelöscht werden, sobald kein anderes Abonnement oder die Aufbewahrungsrichtlinie (retention policy) des Namespaces sie noch hält. Das Problem ermöglicht nicht das Lesen von Nachrichteninhalten, das Ändern von Berechtigungen oder Richtlinien oder den Zugriff auf andere Namesspaces und beeinträchtigt auch nicht die Verfügbarkeit des Brokers.
In behobenen Versionen wenden die Vorgänge auf Namespace-Ebene und Bundle-Ebene für ein benanntes Abonnement die Abo-Richtlinien auf dieses Abonnement an, und die Vorgänge für alle Abonnements wirken sich, wenn sie von einem Benutzer angefordert werden, der kein Tenant-Admin oder Superuser ist, nur auf die Abonnements aus, auf die der Benutzer zugreifen darf. Das Löschen des Backlogs von Geo-Replikations-Cursoren erfordert einen Tenant-Admin-Zugriff oder Superuser-Zugang. Topic-Ebene-Abooperationen wenden die Abo-Richtlinien für alle Arten von Authentifizierungsdaten an, einschließlich der Rolle eines anonymen Benutzers.
Dieses Problem betrifft Apache Pulsar-Versionen ab 2.8.0 vor 4.0.14 und ab 4.1.0 vor 4.2.5.
- Benutzer von Versionen der Reihe 4.0.x sollten auf mindestens 4.0.14 aktualisieren. - Benutzer von Versionen der Reihen 4.1.x und 4.2.x sollten auf mindestens 4.2.5 aktualisieren.
Alle Broker in einem Cluster müssen aktualisiert werden, bevor man sich auf die Einschränkungen auf Namespace-Ebene verlässt, da nicht aktualisierte Brokers diese bei Empfang der internen pro-Bundle-Anfragen nicht anwenden.
Benutzer, die Versionen vor den oben genannten betreiben, sollten auf die vorgenannten gepatchten Versionen oder neuere Versionen aktualisieren.
Die aktuell unterstützten Apache Pulsar-Release-Reihen 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, können ihre Angriffsfläche reduzieren, indem sie den Netzwerkzugriff auf die Admin-REST-API des Brokers auf vertrauenswürdige administrative Clients beschränken.
VulDB is the best source for vulnerability data and more expert information about this specific topic.