Gardener Dashboard: Fehlendes Cookie laesst die OIDC-Pruefung entfallen

State und PKCE werden nur geprueft, wenn das zugehoerige Cookie vorhanden ist; fehlt es, entfaellt die Pruefung statt die Anfrage abzulehnen.

Advisory-ID: TP-2026-097
Produkt: Gardener Dashboard (Weboberflaeche zur Verwaltung von Kubernetes-Clustern, Node.js und Vue)
Schwachstellentyp: Cross-Site Request Forgery im Anmelderueckruf (CWE-352)
CVE: beantragt (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 5.4 (Mittel) · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Betroffene Versionen: >= 1.80.0, <= 1.84.4
Hersteller-Advisory: GHSA-hc35-5329-c78r
Behoben in: 1.84.5 und 1.85.0
Gemeldet: 27. Juli 2026

Zusammenfassung

Der Anmelderueckruf GET /auth/callback tauscht einen Autorisierungscode gegen eine Dashboard-Sitzung, ohne zu pruefen, ob die Anfrage zu einem Anmeldevorgang gehoert, den dieser Browser begonnen hat. Die Bindung an den Vorgang tragen zwei Cookies, eines fuer den State und eines fuer den PKCE-Pruefwert. Beide werden innerhalb einer Abfrage gelesen, ob das Cookie ueberhaupt vorhanden ist, und fehlt es, entfaellt die zugehoerige Pruefung, statt die Anfrage abzuweisen. Die verwendete Bibliothek deutet einen fehlenden erwarteten State als Anweisung, gar keinen State zu erwarten, weshalb ein Rueckruf ohne Cookie und ohne State-Parameter die Pruefung besteht. Ein Angreifer mit einem Autorisierungscode fuer sein eigenes Konto pflanzt damit per Link eine vollstaendige Sitzung in den Browser des Opfers.

Ursache

authorizationCallback kopiert den State nur dann aus dem Cookie __Host-gStt, wenn dieses Cookie existiert, sodass eine Anfrage ohne Cookie state auf undefined belaesst und diesen Wert als expectedState in den Code-Tausch gibt (backend/lib/security/index.js:332-346). Die Bibliothek oauth4webapi 3.8.6 liest diesen Wert als Anweisung, ueberhaupt keinen State zu erwarten, und wirft nur dann, wenn trotzdem einer mitgeschickt wird (build/index.js:2074-2083). Dieselbe Auslassung entfernt bei oeffentlichen Klienten die PKCE-Pruefung, da auch der Pruefwert nur bei vorhandenem Cookie __Host-gCdVrfr gelesen wird. Da die Route eine GET-Anfrage ist und den Rueckruf unmittelbar aufruft, greift die ansonsten vorhandene CSRF-Pruefung ueber einen eigenen Header hier nicht. Der verwundbare Block findet sich in backend/lib/security/index.js je nach Version an den Zeilen 301 bis 319, 315 bis 333 beziehungsweise 322 bis 340.

Proof of Concept

# Der Angreifer startet beim Identitaetsanbieter der Landschaft einen
# eigenen Anmeldevorgang und bricht ihn nach Erhalt des Codes ab.

# Dann bringt er das Opfer dazu, diesen Link zu oeffnen:
https://dashboard.example/auth/callback?code=<code-des-angreifers>

# Der Browser des Opfers traegt keines der beiden __Host-Cookies,
# also entfaellt die State- und die PKCE-Pruefung, der Code wird
# getauscht, und das Opfer sitzt in der Sitzung des Angreifers.

Eine Sitzung, die das Opfer bereits hatte, wird dabei stillschweigend ersetzt. Betroffen sind Installationen mit eingerichtetem OIDC; die Standard-Konfiguration liefert den Abschnitt auskommentiert aus, setzt OIDC aber an die erste Stelle der Anmeldereiter, sobald er vorhanden ist.

Auswirkung

  • Einpflanzen einer vollstaendigen Dashboard-Sitzung in den Browser des Opfers ueber einen einzigen Link.
  • Stilles Ersetzen einer bestehenden Sitzung, sodass das Opfer unbemerkt im Konto des Angreifers arbeitet.
  • Anschliessende Einsicht in alles, was das Opfer in dieser Sitzung anlegt oder eingibt, einschliesslich der Cluster-Zugaenge, die es dort hinterlegt.
  • Betroffen sind sowohl vertrauliche Klienten als auch oeffentliche Klienten mit PKCE; Installationen, die nur die Token-Anmeldung nutzen, erreichen den Pfad nicht.

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