Cloud Foundry UAA EUVD-2026-42518

Exploitation requires the deployment to authenticate users against LDAP over StartTLS using simple-bind - that specific configuration is the trigger, and deployments not using LDAP StartTLS are unaffected. The attacker must hold an active adversary-in-the-middle position on the network path between the UAA server and the LDAP directory (e.g., same VLAN/segment, or control of a routing/DNS/switching element on that path), and must possess any certificate signed by any CA in UAA's trust store - no matching hostname, no private key for the real directory, and no prior authentication to UAA are needed (CVSS PR:N, UI:N). The primary limiting factor is therefore the network-position requirement: an attacker with no path between UAA and the directory cannot exploit this, which is why it is best characterized as a targeted interception risk rather than an unauthenticated internet-facing exposure.

The vendor (VMware/Cloud Foundry Foundation) scored this CVSS 4.0 9.3 with AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H, reflecting unauthenticated network reach and high confidentiality and integrity impact (password harvesting plus admin-scope forgery). The one signal that tempers raw severity is the precondition that the attacker already occupy a man-in-the-middle position on the UAA-to-LDAP segment; the vendor encoded this as AC:L, but a MITM position is a genuine attack requirement, so an independent assessment leans toward AC:H (CVSS 3.1) or AT:P (CVSS 4.0). No EPSS score, KEV listing, or POC was supplied, so real-world exploitation is unconfirmed and likely opportunistic/targeted rather than mass-automatable - this is an interception attack, not an internet-scannable service flaw. Net: a real, high priority for any environment authenticating UAA users against LDAP over StartTLS, especially where UAA-to-directory traffic crosses untrusted network segments, but the MITM prerequisite means it is not remotely automatable at scale. Note the conflict to verify: the vendor's AC:L implies trivial exploitation, whereas the description ('network attacker positioned between') implies a privileged network position - treat AC/AT as the key uncertainty.

An attacker who gains a foothold on the network segment between UAA and the corporate LDAP server (via ARP spoofing, rogue DHCP/DNS, or a compromised switch/router) presents a valid-but-unrelated certificate signed by any trusted CA. UAA accepts it because hostname verification is disabled, so the attacker relays or terminates the StartTLS session, captures the LDAP bind password and each user's plaintext simple-bind password, and returns a crafted directory response asserting attacker-chosen group memberships. No public POC is currently identified, but the technique relies only on standard MITM tooling and a certificate from a trusted CA.