CVE-2026-105934 in Pulsar
Zusammenfassung
von VulDB • 22.10.2026
Die Apache Pulsar Broker-Admin-REST-API bietet eine Truncate-Funktion für persistente Topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Das Ausführen von „Truncate“ versetzt alle Abonnement-Cursor des Topics an das Ende des Topics und löscht die inaktiven Ledgers des Topics. Für ein nicht-partitioniertes Topic oder eine einzelne Partition, die über ihren Partitionsnamen angesprochen wird, ist korrekt die Rolle eines Tenant-Administrators oder die Superuser-Rolle erforderlich. Wenn der Vorgang für den Namen eines partitionierten Topics angefordert wird, wendet der Broker diese Prüfung auf die Tenant-Admin-Rolle nicht beim Aufrufer an. Stattdessen führt er das Truncate jeder Partition mit dem internen Admin-Clients des Brokers aus, der sich mit den konfigurierten Client-Anmeldeinformationen des Brogers authentifiziert und nicht mit der Identität des Aufrufers. Jede pro-Partition angeforderte Truncate-Anfrage wird weiterhin auf die Tenant-Admin-Rolle oder die Superuser-Rolle geprüft, jedoch gegen die interne Identität des Brokers statt gegen den Aufrufer. Die Partitionen werden daher nur dann getrunctet, wenn die konfigurierte Client-Rolle des Brogers ein Superuser ist oder ein Administrator des Ziel-Tenants, was bei aktivierter Autorisierung der übliche Konfigurationszustand ist.
Infolgedessen kann ein authentifizierter Benutzer, der kein Tenant-Administrator ist, jedes partitionierte Topic truncaten, für das er Lookup-Berechtigungen hat. Die Authentifizierung des Aufrufers und die Lookup-Berechtigung allein reichen nicht aus: Wenn die interne Identität des Brogers über keine Tenant-Admin- oder Superuser-Autorisierung für den Ziel-Tenant verfügt, werden die pro-Partition-Anfragen abgelehnt. Mit dem Standard-Autorisierungsanbieter wird die Lookup-Berechtigung durch Produce- oder Consume-Berechtigungen auf das Topic oder dessen Namespace gewährt. Ein Benutzer ohne Berechtigungen auf das Topic kann das Problem nicht auslösen. Diese Auswirkungsanalyse geht davon aus, dass Pulsar mit dem standardmäßigen Autorisierungsanbieter konfiguriert ist. Für benutzerdefinierte Autorisierungsanbieter könnte die Auswirkung anders sein.
Das Truncate eines partitionierten Topics auf diese Weise versetzt die Cursors aller Abonnements in jeder Partition an das Ende des Topics, sodass ein nicht bestätigter Backlog übersprungen und den Verbrauchern nicht mehr zugestellt wird. Es werden auch ältere, für das Löschen geeignete Ledgers jeder Partition gelöscht, unabhängig von der konfigurierten Aufbewahrungspolitik (Retention Policy) des Namespaces, sodass Nachrichten, die in diesen Ledgers gespeichert sind, dauerhaft verloren gehen können. Der aktuell beschriebene Ledger wird durch den Truncate-Vorgang nicht gelöscht. Das Problem ermöglicht kein Lesen von Nachrichteninhalten oder Ändern von Berechtigungen oder Konfigurationen und gewährt keinen Zugriff auf Topics, für die der Benutzer keine Lookup-Berechtigung hat.
Dieses Problem betrifft Apache Pulsar-Versionen ab 2.8.0 vor 4.0.14 sowie 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.
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 ein Upgrade durchführen können, können ihre Angriffsfläche reduzieren, indem sie den Netzwerkzugriff auf die Admin-REST-API des Brokers (/admin/v2) auf vertrauenswürdige administrative Clients beschränken.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.