Cloud Foundry UAA incorrectly treats XML encryption to the Service Provider (SP) as a stand‐in for XML signatures issued by the Identity Provider (IdP). During the OAuth 2.0 SAML2 bearer grant and browser SSO (ACS) flows, when the configuration flag wantAssertionSigned is set to false, UAA accepts assertions or responses that are unsigned but contain encrypted content. Because the encryption uses the SP’s public key from the published metadata, any entity—not just a trusted IdP—can encrypt a payload and submit it to UAA. Successful decryption proves only that the payload was encrypted for UAA, not that it originated from the legitimate IdP, allowing an attacker to craft a SAML assertion and obtain authentication tokens or access as a legitimate user. This flaw is a classic XML Encryption to Signature confusion (CWE‑347).

Affected products include Cloud Foundry UAA versions 2.0.0 through 78.13.0 and all Cloud Foundry CF Deployment releases up to 56.1.0. Users running these older UAA or CF Deployment versions are vulnerable to an authentication bypass exploit.

The vulnerability has a CVSS score of 9, indicating high severity. EPSS data is not available, so the exploitation likelihood is uncertain but potentially significant in environments that rely heavily on SAML for authentication. The issue is not listed in the CISA KEV catalog. The attack requires the ability to reach UAA’s token or ACS endpoints, but no privileged credentials or prior trust relationship with a legitimate IdP are needed; an attacker only needs to craft and send a suitably encrypted SAML assertion.