Kerngegevens
- Leverancier
- VMware (Broadcom)
- Product
- Cloud Foundry UAA
- Soort software
- virtualisatie
- Getroffen versies
- Cloud Foundry UAA Zie het advies van de leverancier
- Oplossing
- Nog geen oplossing
- Opgeloste versie
- Nog geen update
- CVE gepubliceerd
- 6 oktober 2026
- Gepubliceerd op LekkenRadar
- 6 oktober 2026
- Laatst gewijzigd bij NVD
- 6 oktober 2026
Simpel uitgelegd
Wat is er aan de hand?
In de OAuth-tokenendpoint van Cloud Foundry UAA zit een fout in de controle van de inloggegevens van een client. Bij een client_credentials-verzoek controleert UAA niet of de meegestuurde Bearer-gegevens echt een clientgeheim of een geldige clientauthenticatiemethode zijn. Elk geldig toegangstoken van een gebruiker met dezelfde client_id wordt geaccepteerd. Daardoor kan een aanvaller met een eigen gebruikerstoken een token met alle rechten van de client krijgen, zonder het geheim van die client te kennen.
Wie loopt risico?
Je loopt alleen risico als je UAA gebruikt met een client die zowel een openbare, gebruikersgerichte autorisatiestroom (authorization_code met PKCE) als het client_credentials-grant type ondersteunt op dezelfde client_id. Dat is geen standaardcombinatie. De aanvaller moet via het netwerk bij UAA kunnen en een geldig gebruikerstoken hebben, bijvoorbeeld door als gewone gebruiker in te loggen. Hoe groot de gevolgen zijn, hangt af van de rechten van de betreffende client. Heeft die bijvoorbeeld clients.write, dan kan de aanvaller nieuwe OAuth-clients aanmaken met zelfgekozen rechten.
Wat moet je doen?
Nog geen update beschikbaar
De leverancier werkt eraan. Hieronder lees je hoe je het risico tot die tijd kleiner maakt.
Lees het advies van Cloud Foundry
Bekijk het bericht op de site van Cloud Foundry over dit lek. In de beschikbare gegevens staat geen specifieke opgeloste versie, dus volg het advies van de leverancier voor de juiste update of maatregel.
Controleer je clientconfiguratie
Zoek uit of je UAA-clients hebben, waarbij dezelfde client_id zowel een openbare autorisatiestroom als het client_credentials-grant type ondersteunt. Alleen die clients zijn te misbruiken.
Beperk de blootstelling
Overweeg om voor zulke clients de twee functies te scheiden over verschillende client_id's, of om het client_credentials-grant type uit te zetten als je dat niet nodig hebt. Beperk ook de rechten van de client tot wat echt nodig is.
Controleer op ongebruikelijke clients
Kijk in je UAA-omgeving of er nieuwe of onbekende OAuth-clients zijn aangemaakt, vooral met brede rechten.
Deel dit lek
Technische detailsBeschrijving, CVSS-vector, EPSS en adviezen
Beschrijving
Het gaat om onjuiste authenticatie (CWE-287) in de OAuth-tokenendpoint van Cloud Foundry UAA. Bij een client_credentials-grantverzoek accepteert UAA een Bearer-credential als clientauthenticatie zonder te controleren of dit een clientgeheim of een geldige geconfigureerde authenticatiemethode is. Elk geldig toegangstoken waarvan de client_id overeenkomt met het verzoek wordt geaccepteerd. Een token uit een publieke authorization_code-flow met PKCE, met alleen scope uaa.user, een user_id en client_auth_method=none, voldoet aan die controle. Dat token kan zelf geen clients beheren (POST /oauth/clients geeft 403), maar bij hergebruik als Bearer op een client_credentials-verzoek geeft UAA een client-only token uit met alle rechten van de client, zoals clients.write.
CVSS-vector (versie 4.0, basisscore 7,6, bron: CNA)
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X- Zwakheid (CWE)
- CWE-287 · Onjuiste authenticatie
- Aanvalsroute
- Via het netwerk of internet
- EPSS, kans op misbruik binnen 30 dagen
- 0,3%
- Aanvalscode openbaar
- Nee