abraxas/cve-2026-59358Proof-of-Concept-Lab und Exploit-Client für CVE-2026-59358, der die Wiederverwendung eines Benutzer-PKCE-Tokens durch Cloud Foundry UAA als client_credentials Bearer demonstriert, um privilegierte Client-Tokens zu erzeugen.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · CVE-2026-59358
Klasse: Privilegien-Überrest Reichweite: Remote
Cloud Foundry UAA v79.6.0 - VMware by Broadcom / Cloud Foundry Foundation
Ich bin @abraxas_null. Loopback-Lab. Der Client ist CVE-2026-59358-Abraxas-Labs.py.
Ein öffentliches PKCE-Benutzerzugriffstoken wird als Bearer-Client-Authentifizierung bei grant_type=client_credentials für denselben Dual-Grant-Client akzeptiert. UAA stellt ein reines Client-Token mit den Berechtigungen dieses Clients aus (clients.write in diesem Lab). Das Benutzertoken selbst liefert 403 bei POST /oauth/clients. Das übrig gebliebene Token erstellt einen neuen OAuth-Client. Unabhängiges Lab der veröffentlichten CVE. Danksagung: Minseong Kim (mak3bread).
| CVE | CVE-2026-59358 · CVE.org |
| Klasse | Privilegien-Überrest (Benutzertoken wiederverwendet als client_credentials-Bearer; kein RCE) |
| Reichweite | Remote (eigenes Benutzerzugriffstoken des Angreifers) |
| CWE | CWE-287 |
| CVSS | Hoch: 7.6 CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N |
| Produkt | Cloud Foundry UAA |
| Betroffen | UAA v3.7.0 bis v79.6.0; cf-deployment bis v60.4.0 |
| Gepatcht | UAA v79.7.0; cf-deployment v60.5.0 |
| Auth | authentifiziert (eigenes PKCE-Benutzertoken des Angreifers) |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Anmeldung über einen öffentlichen OAuth-Client, der auch client_credentials auflistet. Dieses Benutzer-JWT als Authorization: Bearer bei POST /oauth/token mit grant_type=client_credentials wiedergeben. UAA gibt ein reines Client-Token mit den Berechtigungen des Clients zurück. Wenn diese clients.write enthalten, können neue OAuth-Clients mit vom Angreifer gewählten Berechtigungen erstellt werden. Kein Client-Secret erforderlich.
Das Benutzertoken kann Clients nicht allein administrieren. Der Überrest ist die Prüfung am Token-Endpunkt, die jedes gültige Zugriffstoken, dessen client_id übereinstimmt, als Client-Authentifizierung behandelt.
Die Auswirkung skaliert mit den Berechtigungen dieses Clients. Die Kombination (öffentlicher Benutzer-Flow plus client_credentials auf einer client_id) ist nicht Standard.
Cloud Foundry veröffentlichte CVE-2026-59358 am 5. Okt. 2026. Ich habe die letzte betroffene Version cfidentity/uaa:v79.6.0 gepinnt, einen dedizierten öffentlichen Dual-Grant-Client labpub aufgesetzt und PKCE als Standardbenutzer marissa durchlaufen. Negativkontrolle: Benutzertoken bei POST /oauth/clients ergibt 403. Angriff: derselbe Bearer bei client_credentials ergibt 200, dann 201 beim Erstellen von labwit-CVE-2026-59358-WITNESS.
Bereits dokumentierte Irrwege: Pinnen von v79.7.0 (gepatcht); Aufruf von /oauth/token ohne den /uaa-Kontextpfad; Vermischen von localhost und 127.0.0.1 in Issuer und Redirect; Verwenden des Standard-login-Clients (kein clients.write); Password-Grant statt PKCE; Senden von Basic client_id:secret plus dem Benutzer-Bearer (das ist legitime Client-Authentifizierung).
HTTP 18258 auf Loopback. Image docker.io/cfidentity/uaa:v79.6.0 (linux/amd64). Compose-Projekt cve-2026-59358. ./run.sh.
Ziel nur 127.0.0.1:18258 (oder das Loopback, an das du gebunden hast).
python3 CVE-2026-59358-Abraxas-Labs.py
Das wechselt per chdir in lab/ und führt run.sh aus (compose up, warten auf /uaa/info, dann poc.py).
Witness: Das ausgestellte client_credentials-JWT trägt clients.write, und POST /oauth/clients gibt 201 für labwit-CVE-2026-59358-WITNESS zurück. Benutzertoken am selben Endpunkt ergibt 403.
SUCCESS CVE-2026-59358 grant=client_credentials clients.write create-http=201 id=labwit-CVE-2026-59358-WITNESS CVE-2026-59358-WITNESS
Wege, nichts zu lernen:
v79.7.0 oder neuerAktualisiere UAA auf v79.7.0 oder neuer, oder cf-deployment auf v60.5.0. Bis dahin: Setze keinen öffentlichen benutzerorientierten Grant und client_credentials auf dieselbe client_id, und halte clients.write auf dedizierten, nicht-öffentlichen Clients.
Führe CVE-2026-59358-Abraxas-Labs.py erneut gegen den gepatchten Build aus: Der Benutzer-Bearer bei client_credentials muss non-200 bleiben.
hub.docker.com/r/cfidentity/uaa Tag v79.6.0
Abraxas Labs: abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected]
GNU Affero GPL v3.0. Siehe LICENSE.
Der Client kommuniziert mit Loopback. Die Verwendung gegen Systeme, die dir nicht gehören, ist von Abraxas Labs nicht autorisiert. Keine Gewährleistung.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected]