Which versions of Cloud Foundry UAA are affected by CVE-2026-47840?

Cloud Foundry UAA's LDAP integration disables hostname verification on TLS connections, allowing an attacker positioned on the network path to impersonate the LDAP directory, steal all credentials…. A patch is available.

How to fix or mitigate CVE-2026-47840?

Within 24 hours: Identify all Cloud Foundry deployments and determine UAA and cf-deployment versions (vulnerable: UAA prior to v78.13.0, cf-deployment prior to v56.2.0). Within 7 days: Implement network-layer controls restricting UAA-to-LDAP traffic to designated directory endpoints only; enable continuous monitoring for anomalous LDAP authentication attempts and certificate validation failures. Within 30 days: Contact Pivotal/VMware for patched version availability and deploy v78.13.0 (UAA) and v56.2.0 (cf-deployment) immediately upon release; interim risk reduction includes disabling LDAP authentication for non-critical workloads and forcing password resets for all platform users post-remediation.

Cloud Foundry UAA CVE-2026-47840

Q: What is the CVSS score of CVE-2026-47840?

CVE-2026-47840 has a CVSS 4.0 base score of 9.3 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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. EPSS exploitation probability: 0.1%.

EUVD-2026-42518 CRITICAL

2026-07-09 vmware

GHSA-rh75-5vxf-83m5

Information Disclosure Uaa Cf Deployment

9.3

CVSS 4.0 · Vendor: vmware

Severity by source

Vendor (vmware) PRIMARY

9.3 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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

vuln.today AI

7.4 HIGH

MITM position is a real prerequisite so AC:H rather than the vendor's AC:L; no auth needed (PR:N); password capture gives C:H and forged admin scopes give I:H, with no availability impact.

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

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

Primary rating from Vendor (vmware).

CVSS VectorVendor: vmware

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 09, 2026 - 08:01 EUVD

Analysis Generated

Jul 09, 2026 - 07:24 vuln.today

Severity Changed

Jul 09, 2026 - 07:22 NVD

HIGH CRITICAL

CVSS changed

Jul 09, 2026 - 07:22 NVD

7.5 (HIGH) 9.3 (CRITICAL)

DescriptionCVE.org

A network attacker positioned between UAA and its LDAP directory can impersonate the directory using any certificate from any trusted CA, then harvest the LDAP bind password and every end-user password sent during simple-bind authentication, and return forged group memberships that grant themselves admin scopes. This affects every deployment that authenticates users against LDAP over StartTLS. Affected versions: UAA versions prior to v78.13.0; Cf-deployment versions prior to v56.2.0.

AnalysisAI

Adversary-in-the-middle credential theft and privilege escalation affects Cloud Foundry UAA (User Account and Authentication server) prior to v78.13.0 and cf-deployment prior to v56.2.0, where LDAP StartTLS unconditionally disables TLS hostname verification. An attacker positioned on the network path between UAA and its LDAP directory can present any certificate issued by any trusted CA to impersonate the directory, harvesting the LDAP bind password plus every end-user password submitted during simple-bind authentication and injecting forged group memberships that grant attacker-controlled admin scopes. There is no public exploit identified at time of analysis, no CISA KEV listing, and EPSS was not provided, but the CVSS 4.0 base score is 9.3 (Critical).

Technical ContextAI

UAA is the OAuth2/OIDC identity provider at the core of the Cloud Foundry platform and is commonly deployed via cf-deployment (BOSH). The flaw lies in the LDAP-over-StartTLS authentication path: StartTLS upgrades a plaintext LDAP connection to TLS in-band, so the client must independently validate that the server certificate's subject/SAN matches the expected directory hostname. UAA validates the certificate chain (that it was issued by a trusted CA) but skips hostname verification entirely, so any certificate from any publicly or privately trusted CA satisfies the check regardless of which host presents it. Although the advisory lists CWE as N/A, the root cause is the classic certificate-validation class: CWE-297 (Improper Validation of Certificate with Host Mismatch), a subtype of CWE-295 (Improper Certificate Validation). The affected components identified by CPE are cloudfoundry_foundation:uaa and cloudfoundry_foundation:cf-deployment.

RemediationAI

Vendor-released patch: upgrade UAA to v78.13.0 or later, and cf-deployment to v56.2.0 or later, per the Cloud Foundry advisory (https://www.cloudfoundry.org/blog/cve-2026-47840-ldap-starttls-unconditionally-disables-hostname-verification/). If patching cannot be performed immediately, reduce exposure by hardening the UAA-to-LDAP network path: restrict LDAP traffic to a dedicated, trusted network segment with no intermediary hosts, and enforce mutual TLS or IPsec between UAA and the directory so an impersonating endpoint cannot complete the handshake (trade-off: additional PKI/config management on both endpoints). Where feasible, switch from StartTLS to LDAPS on port 636 if that path enforces hostname verification, or pin the directory to a private CA that only issues the directory certificate (trade-off: any compromise of that CA re-enables the attack, and this does not fix the missing hostname check on its own). After patching, rotate the LDAP bind password and force a reset of any end-user passwords that may have transited an unverified connection, since credentials could already be compromised.