Cloud Foundry CAPI EUVD-2026-113755

Exploitation requires an authenticated principal holding the SpaceDeveloper role within a Cloud Foundry space that already contains a space-scoped service broker with stored credentials worth harvesting. The specific prerequisite is the ability to update that broker's registration URL (a SpaceDeveloper-permitted operation) while leaving its credentials unchanged, causing the platform to forward the existing credentials to the attacker-supplied endpoint; the indirect method exists precisely because the CF API forbids reading broker credentials directly. Limiting factors: the attacker must already have SpaceDeveloper authorization in the relevant space (PR:H, authenticated), a space-scoped broker must exist, and impact is confined to the credentials of that broker (C:L, no integrity or availability effect). This is not exploitable by an unauthenticated or external attacker against a default deployment.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The CVSS 3.1 base score is 2.7 (Low) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N: network-reachable and low-complexity, but gated behind high privileges (PR:H - an authenticated SpaceDeveloper role) with only limited confidentiality impact and no integrity or availability impact. The vuln.today decision label is 'monitor', the lowest urgency tier, and the vulnerability is not listed in CISA KEV. No EPSS exploitation-probability score was supplied in the input, so quantitative exploitation likelihood cannot be stated; this absence is a data gap, not evidence of either high or low probability. No public exploit or PoC reference appears in the input (the only reference is the vendor advisory blog). Taken together - low CVSS, high privilege requirement, confidentiality-only impact, 'monitor' decision, no KEV, no PoC - this is a high-privilege insider/lateral-movement credential-disclosure issue rather than an externally weaponizable flaw, and should be patched on a routine cycle. The one caveat worth noting to a security team: the real-world impact depends on how sensitive the stored space-scoped broker credentials are, which the input does not quantify.

An authenticated user who already holds the SpaceDeveloper role in a Cloud Foundry space edits an existing space-scoped service broker, changing only its URL to point at a broker endpoint the attacker controls while leaving the stored credentials untouched. When the platform next contacts the broker, it transmits those existing credentials to the attacker's endpoint, giving the attacker the credentials that the CF API otherwise does not allow them to read directly. No public exploit was identified at time of analysis, and the technique requires the attacker to already possess SpaceDeveloper privileges.