Cloud Foundry UAA CVE-2026-41005

Target UAA must have at least one SAML IdP provider configuration with wantAssertionSigned set to false (the vulnerable code path explicitly checks this flag), and either the OAuth 2.0 SAML2 bearer grant must be enabled at the token endpoint or the browser SSO ACS endpoint must be reachable by the attacker. The attacker needs network reachability to UAA's SAML endpoints and the SP's public encryption certificate (trivially obtainable from published SAML metadata), but does NOT need any prior authentication, user interaction, or a compromised IdP. Deployments where every IdP provider is configured with wantAssertionSigned=true are not exploitable via this flaw, which is the limiting factor - the CVSS AC:H reflects that the unsafe configuration is opt-in rather than default, though it is a common interoperability setting with legacy IdPs.

The CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H yields 9.0 (Critical) and is broadly consistent with the description: network-reachable SAML endpoints (AV:N), no authentication or user interaction required (PR:N/UI:N), and a scope change (S:C) reflecting that compromising UAA breaks the trust boundary into every downstream CF-managed resource. AC:H is justified because exploitation requires the target UAA to be configured with wantAssertionSigned=false and the attacker must craft a syntactically valid SAML message encrypted to the SP's public key - non-trivial but well within reach of any motivated attacker since SP metadata is public. There is no EPSS, KEV listing, or POC provided in the source data, and no public exploit identified at time of analysis; this is not in CISA KEV and exploitation is likely opportunistic rather than mass-scanned. The vendor-supplied tags 'Denial Of Service, Jwt Attack' appear mislabeled relative to the actual root cause (SAML signature bypass) and should not be relied on for triage - note the discrepancy and trust the description over the tags.

An attacker fetches the target UAA's public SAML SP metadata (typically exposed at /saml/metadata) to obtain the SP encryption certificate, then crafts a SAML Response or Assertion that names a privileged victim user (e.g., a Cloud Foundry admin) in the Subject, encrypts the assertion to the SP's public key, and omits any IdP signature. The attacker POSTs this to the UAA ACS endpoint or exchanges it at the token endpoint via the SAML2 bearer grant, and UAA - finding wantAssertionSigned=false and successfully decrypting the payload - issues an OAuth access token as the impersonated user, granting full platform control. No public exploit identified at time of analysis, but the building blocks (OpenSAML, python-saml) make weaponization straightforward for an attacker who has read the advisory.