Cloud Foundry UAA denial-of-service flaw in private_key_jwt authentication
- Status
- Unverified: only social posts report this so far
- Kind
- Vulnerability
- Vendor
- Cloud Foundry
- Product
- UAA
- First seen
Summary
The EU Vulnerability Database entry EUVD-2026-113751 describes a denial-of-service flaw in UAA's private_key_jwt client authentication. The entry is scored 6.9/10 (CVSS v3.1) and says invalid authentication attempts can trigger full deserialization of the cached JWKS response.
If you use Cloud Foundry
Check whether you run UAA in cf-deployment
Apply the Cloud Foundry UAA update that fixes the issue
Limit exposure of UAA endpoints that accept private_key_jwt authentication
Check whether your cf-deployment includes Cloud Controller (CAPI) affected by the issue
Apply the Cloud Foundry update that fixes the issue
Review space role assignments for SpaceSupporter users
What the sources say 5
· Mastodon: “The Nginx routing configuration for Cloud Controller blocks unauthenticated access to /internal/v4/ and /internal/v5/ endpoints but omits an equivalent deny rule for /internal/v3/.” Source
· Mastodon: “A user with SpaceDeveloper privileges could modify the URL of a space-scoped broker without altering its credentials, enabling extraction of existing broker credentials by redirecting them to a broker under thei...” Source
· Mastodon: “Cloud Controller (CAPI) leaks sensitive data into audit logs in multiple instances: custom buildpack credentials are exposed in audit events for app manifest application, creation, and updates; syslog...” Source
· Mastodon: “A SpaceSupporter could improperly modify an application's start command and buildpack—actions requiring SpaceDeveloper privileges.” Source
· Mastodon: “A denial-of-service vulnerability exists in UAA's private_key_jwt client-authentication mechanism.” Source