
Proof-of-concept lab and exploit client for CVE-2026-59358, demonstrating Cloud Foundry UAA reuse of a user PKCE token as client_credentials Bearer to mint privileged client tokens.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · CVE-2026-59358
Class: Privilege leftover Reach: Remote
Cloud Foundry UAA v79.6.0 - VMware by Broadcom / Cloud Foundry Foundation
I am @abraxas_null. Loopback lab. The client is CVE-2026-59358-Abraxas-Labs.py.
A public PKCE user access token is accepted as Bearer client authentication on grant_type=client_credentials for the same dual-grant client. UAA mints a client-only token with that client's authorities (clients.write in this lab). The user token itself 403s on POST /oauth/clients. The leftover token creates a new OAuth client. Independent lab of the published CVE. Credit: Minseong Kim (mak3bread).
| CVE | CVE-2026-59358 · CVE.org |
| Class | Privilege leftover (user token reused as client_credentials Bearer; not RCE) |
| Reach | Remote (attacker's own user access token) |
| CWE | CWE-287 |
| CVSS | High: 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 |
| Product | Cloud Foundry UAA |
| Affected | UAA v3.7.0 through v79.6.0; cf-deployment through v60.4.0 |
| Patched | UAA v79.7.0; cf-deployment v60.5.0 |
| Auth | authenticated (attacker's own user PKCE token) |
| License | GNU Affero GPL v3.0 |
| Lab | 127.0.0.1 only |
Log in through a public OAuth client that also lists client_credentials. Replay that user JWT as Authorization: Bearer on POST /oauth/token with grant_type=client_credentials. UAA returns a client-only token with the client's authorities. If those include clients.write, create new OAuth clients with attacker-chosen authorities. No client secret required.
The user token cannot administer clients by itself. The leftover is the token-endpoint check treating any valid access token whose client_id matches as client authentication.
Impact scales with that client's authorities. The combo (public user flow plus client_credentials on one client_id) is not default.
Cloud Foundry published CVE-2026-59358 on 5 Oct 2026. I pinned last-affected cfidentity/uaa:v79.6.0, stood up a dedicated dual-grant public client labpub, and walked PKCE as the stock user marissa. Negative control: user token on POST /oauth/clients is 403. Attack: same Bearer on client_credentials is 200, then 201 creating labwit-CVE-2026-59358-WITNESS.
Wrong turns already recorded: pinning v79.7.0 (patched); hitting /oauth/token without the /uaa context path; mixing localhost and 127.0.0.1 in issuer and redirect; using the stock login client (no clients.write); password grant instead of PKCE; sending Basic client_id:secret plus the user Bearer (that is legitimate client auth).
HTTP 18258 on loopback. Image docker.io/cfidentity/uaa:v79.6.0 (linux/amd64). Compose project cve-2026-59358. ./run.sh.
Target only 127.0.0.1:18258 (or the loopback you bound).
python3 CVE-2026-59358-Abraxas-Labs.py
That chdirs into lab/ and runs run.sh (compose up, wait for /uaa/info, then poc.py).
Witness: minted client_credentials JWT carries clients.write and POST /oauth/clients returns 201 for labwit-CVE-2026-59358-WITNESS. User token on the same endpoint is 403.
SUCCESS CVE-2026-59358 grant=client_credentials clients.write create-http=201 id=labwit-CVE-2026-59358-WITNESS CVE-2026-59358-WITNESS
Ways to lose without learning anything:
v79.7.0 or laterUpgrade UAA to v79.7.0 or newer, or cf-deployment to v60.5.0. Until then, do not put a public user-facing grant and client_credentials on the same client_id, and keep clients.write on dedicated non-public clients.
Re-run CVE-2026-59358-Abraxas-Labs.py against the patched build: the user Bearer on client_credentials must stay non-200.
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. See LICENSE.
The client talks to loopback. Using it against systems you do not own is not authorized by Abraxas Labs. No warranty.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected]