What is the CVSS score of EUVD-2026-36311?

EUVD-2026-36311 has a CVSS 3.1 base score of 9.0 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Cloud Foundry UAA are affected by EUVD-2026-36311?

Cloud Foundry UAA versions 2.0.0 through 78.13.0 contain a critical authentication bypass vulnerability allowing remote attackers to forge SAML assertions and impersonate any user by exploiting XML…. A patch is available.

How to fix or mitigate EUVD-2026-36311?

Within 24 hours: Identify and inventory all Cloud Foundry UAA instances running versions 2.0.0-78.13.0; implement immediate network segmentation to restrict SAML assertion traffic to known, trusted Identity Providers only. Within 7 days: Deploy enhanced logging and SIEM alerting for SAML assertion processing and authentication events; implement strict ingress filtering and evaluate temporary disabling of SAML federation. Within 30 days: Establish vendor communication protocol to track patch availability; plan migration strategy to non-vulnerable architecture or UAA versions once patches are released.

Cloud Foundry UAA EUVD-2026-36311

| CVE-2026-41005 CRITICAL

Improper Verification of Cryptographic Signature (CWE-347)

2026-06-11 vmware

GHSA-wx8w-j86h-c458

Denial Of Service Jwt Attack Cf Deployment Cloud Foundry Uaa

9.0

CVSS 3.1 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

9.0 CRITICAL

AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

8.7 HIGH

Network-reachable SAML endpoint with no auth or user interaction; AC:H because exploitation requires non-default wantAssertionSigned=false config; S:C reflects platform-wide impersonation; A:N - described impact is identity spoofing, not availability.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jun 11, 2026 - 22:01 EUVD

Analysis Generated

Jun 11, 2026 - 21:29 vuln.today

DescriptionCVE.org

Cloud Foundry UAA incorrectly treated XML encryption to the Service Provider (confidentiality) as a substitute for XML signatures from the Identity Provider (authenticity) in two SAML flows: the OAuth 2.0 SAML2 bearer grant (token endpoint) and browser SSO (ACS) when wantAssertionSigned is set to false. Assertions or responses that were unsigned but contained encrypted content could still be accepted. Encryption uses the SP's public key from published metadata, therefore, any party, not only a trusted IdP, can produce ciphertext UAA can decrypt; successful decryption therefore does not prove the IdP issued the message.

Affected versions: Cloud Foundry UAA (uaa_release) 2.0.0 through 78.13.0. Cloud Foundry CF Deployment all versions through 56.1.0.

AnalysisAI

Authentication bypass in Cloud Foundry UAA (User Account and Authentication) versions 2.0.0 through 78.13.0 allows remote attackers to forge SAML assertions and impersonate users by exploiting a logic flaw where XML encryption was accepted as a substitute for XML signature verification. Because the Service Provider's public encryption key is published in SAML metadata, any party - not just a trusted Identity Provider - can craft encrypted-but-unsigned assertions that UAA will decrypt and trust, breaking the identity-assurance guarantee of SAML. No public exploit identified at time of analysis, but the cryptographic confusion (CWE-347) is well-understood and the impact (full identity spoofing into the platform IAM) is severe.

Technical ContextAI

Cloud Foundry UAA is the OAuth2/OIDC identity server underpinning Cloud Foundry platform deployments (BOSH-released as uaa_release and packaged via cf-deployment). It supports federated login via SAML 2.0 in two flows: the RFC 7522 OAuth 2.0 SAML2 Bearer Assertion grant at the token endpoint, and browser-based Web SSO via the Assertion Consumer Service (ACS) endpoint. The bug is a classic CWE-347 (Improper Verification of Cryptographic Signature) caused by conflating two orthogonal SAML primitives: XML encryption (which provides confidentiality from SP→whoever holds the SP private key) and XML signatures (which provide authenticity/integrity from IdP→SP). When the wantAssertionSigned configuration flag was false, UAA accepted assertions or responses that lacked an IdP signature provided the payload contained encrypted XML, on the false assumption that successful decryption implied IdP origin. In reality, the SP's encryption public key is by design distributed via SAML metadata to anyone - so any attacker can produce ciphertext UAA can decrypt.

RemediationAI

Upgrade uaa_release beyond 78.13.0 and cf-deployment beyond 56.1.0 to the patched release line per the Cloud Foundry advisory at https://www.cloudfoundry.org/blog/cve-2026-41005-uaa-accepts-saml-encrypted-assertions-authentication-bypass/; the input data does not state an exact fixed version, so consult the advisory for the current minimum safe release. As an immediate workaround, set wantAssertionSigned=true on every SAML IdP provider configuration in UAA so that unsigned assertions are rejected even when encrypted - the trade-off is that IdPs that do not sign assertions will stop working and must be reconfigured to sign. Additionally audit existing IdP configurations to confirm none rely on encryption-only trust, and rotate the SP signing/encryption keypair if you suspect prior exploitation, since the encryption public key is part of published metadata and cannot itself be kept secret. No vendor-released patch version is independently confirmed in the input - track the linked advisory for the exact fix version before deployment.