Graylog: Rechteausweitung von Manager zu Owner bei Dashboards und gespeicherten Suchen

Ein Nutzer, dem ein Dashboard oder eine gespeicherte Suche lediglich als Manager freigegeben wurde, vergibt über das Update-Endpunkt die Owner-Capability an ein beliebiges weiteres Konto und löscht die Entität anschließend darüber oder entzieht dem ursprünglichen Eigentümer den Zugriff.

Advisory-ID: TP-2026-038
Produkt: Graylog (Open-Source-Plattform für zentrales Log-Management und Security-Analytics mit Streams, Dashboards und gespeicherten Suchen)
Schwachstellentyp: Fehlende Autorisierungsprüfung beim Ändern von Entity-Freigaben (CWE-862, CWE-639)
CVE: CVE-2026-69190
CVSS 3.1: 6.3 (Mittel) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Hersteller-Advisory: GHSA-m9c2-85gv-8xr5
Betroffene Versionen: >= 6.3.0
Behoben in: 6.3.14, 7.0.9, 7.1.4
Gemeldet: 12. Juni 2026

Zusammenfassung

Graylog ist eine Open-Source-Plattform für zentrales Log-Management, deren Dashboards und gespeicherte Suchen ihre Eigentümer über ein Capability-Modell mit den Stufen Viewer, Manager und Owner an andere Nutzer freigeben. Der Endpunkt zum Aktualisieren einer solchen Ansicht nimmt im selben Request eine Änderung der Freigaben an, prüft dafür aber nur das Editier-Recht und nicht die Eigentümerschaft, während der eigens dafür vorgesehene Freigabe-Endpunkt genau diese Prüfung durchführt. Ein Nutzer, dem ein Dashboard lediglich als Manager freigegeben wurde, vergibt darüber die Owner-Capability an ein beliebiges weiteres Konto. Über dieses Konto löscht er anschließend die Entität oder entzieht dem ursprünglichen Eigentümer den Zugriff, beides Operationen, die ihm mit seiner eigenen Manager-Capability verweigert werden. Die Ausweitung bleibt auf Entitäten beschränkt, die dem Angreifer bereits als Manager freigegeben wurden, und erreicht keine System- oder Administratorrechte; turingpoint hat den Fund live verifiziert und an den Hersteller gemeldet, der ihn in 6.3.14, 7.0.9 und 7.1.4 behoben hat.

Ursache

ViewsResource.update (graylog2-server/src/main/java/org/graylog/plugins/views/search/rest/ViewsResource.java:389-404) nimmt im Request-Body das optionale Feld share_request an und gibt es am Ende der Methode über updateViewSharing (:402, :287-292) unverändert an entitySharesService.updateEntityShares weiter. Die einzige Autorisierungsprüfung dieses Pfades ist validateDto mit searchUser.canUpdateView (:398, :408, plugins/views/search/permissions/SearchUser.java:96-101), also das Recht view:edit, das von der Capability MANAGE abgedeckt wird und nicht von OWN. Der für Freigaben vorgesehene Endpunkt POST /api/authz/shares/entities/{grn} prüft an derselben Stelle die Eigentümerschaft: checkOwnership (security/rest/EntitySharesResource.java:160-165, security/rest/RestResourceWithOwnerCheck.java:31) verlangt Permission.ENTITY_OWN, bevor derselbe Service aufgerufen wird. EntitySharesService.updateEntityShares (security/shares/EntitySharesService.java:237-258) selbst prüft den Aufrufer nicht, und die einzige Absicherung dort verhindert lediglich, dass eine Entität ohne Eigentümer zurückbleibt (:397). CapabilityRegistry.java:39-82 bündelt ENTITY_OWN ausschließlich in OWN (:60) und nicht in MANAGE, weshalb der Update-Pfad die schwächere Prüfung anwendet und ein Manager Owner-Rechte an ein Konto seiner Wahl vergibt.

Proof of Concept

# Ausgangslage: Angreifer A hält auf dem Dashboard <view-id> nur MANAGE,
# <puppet-id> ist ein zweites, von A kontrolliertes Konto mit Reader-Rolle.

# 1) Der vorgesehene Freigabe-Endpunkt lehnt die Owner-Vergabe ab:
POST /api/authz/shares/entities/grn::::dashboard:<view-id>
X-Requested-By: cli
{"selected_grantee_capabilities":{"grn::::user:<puppet-id>":"own"}}
# -> 403 {"message":"Not authorized to access entity ..."}

# 2) Derselbe Grant im share_request des View-Updates wird angenommen:
PUT /api/views/<view-id>
X-Requested-By: cli
{"entity":{ ...unveraenderte View-Felder inkl. "id" ... },
 "share_request":{"selected_grantee_capabilities":{"grn::::user:<puppet-id>":"own"}}}
# -> 200, der Grant erscheint in active_shares mit der Capability "own"

# 3) Das aufgewertete Konto besteht das OWN-Gate und loescht die Entitaet:
DELETE /api/views/<view-id>
# -> 200, das anschliessende GET auf dieselbe ID -> 404

Der Unterschied liegt allein im Pfad: Schritt 1 und Schritt 2 rufen denselben Service mit derselben Nutzlast auf, nur prüft Schritt 1 vorher die Eigentümerschaft und Schritt 2 nicht. Live verifiziert auf Version 7.1.3 mit drei Konten der Rolle Reader: der Eigentümer teilt sein Dashboard an A als Manager, A vergibt über den Update-Pfad own an das Puppet-Konto, und das Puppet-Konto löscht das Dashboard erfolgreich, während A dieselbe Löschung mit HTTP 403 verweigert wird.

Auswirkung

  • Vergabe der Owner-Capability auf ein fremdes Dashboard oder eine fremde gespeicherte Suche an ein beliebiges Konto, ohne selbst Eigentümer zu sein.
  • Löschen der Entität über das so aufgewertete Konto, obwohl dieselbe Person die Löschung mit ihrer Manager-Capability nicht ausführen darf.
  • Entzug des Zugriffs für den ursprünglichen Eigentümer, der sein eigenes Dashboard danach nicht mehr öffnen kann.
  • Als Ausgangsposition genügt eine gewöhnliche Kollaborationsfreigabe auf Manager-Stufe; die Ausweitung bleibt jedoch auf die bereits freigegebene Entität begrenzt und führt nicht zu System- oder Administratorrechten.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen