Cloud Foundry EUVD-2026-113753

The attacker must already hold the SpaceSupporter role on the target Cloud Foundry space; the flaw is an authorization gap that lets that role perform start-command and buildpack-action changes reserved for SpaceDeveloper, which is then abused to read credentials of services bound to the app. Limiting factors: exploitation requires a valid account with an assigned SpaceSupporter role (not anonymous or remote-unauthenticated access), access to a space containing apps with bound services, and an app staging/restart event for the malicious start command or buildpack to execute - so impact is scoped to spaces where the attacker has been deliberately granted this role.

This is a genuine but contained privilege-escalation issue rather than a top-tier emergency. The input CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N, 6.5) marks it as network-reachable and low-complexity but requiring privileges and no user interaction - consistent with the description, where the actor is an already-authenticated Cloud Foundry user holding the limited SpaceSupporter role who escalates to actions reserved for SpaceDeveloper. The vuln.today decision label is 'this_month' (not act_now/emergency), and no KEV listing, no EPSS score, and no PoC/exploit reference are present in the input, so there is no evidence of active or at-scale exploitation. The main caveat is a signal tension on privileges: the supplied vector uses PR:H, but SpaceSupporter is by design a lower-privilege role than SpaceDeveloper, so PR:L is arguably more faithful and would raise the real severity - the exact privilege model should be confirmed against the Cloud Foundry advisory. Overall this is a real, authenticated insider/role-boundary flaw with high confidentiality and integrity impact (service-credential disclosure) but a meaningful precondition (a granted SpaceSupporter role on a space), placing it as a planned-remediation priority rather than a drop-everything event.

An authenticated user who has only been granted the SpaceSupporter role on a Cloud Foundry space modifies a targeted application's start command or supplies a malicious/custom buildpack - actions that should require SpaceDeveloper privileges. When the app is (re)staged or restarted, the attacker's injected logic runs in the application context and reads the credentials of bound services, exposing them to the attacker. No public exploit identified at time of analysis; the only reference is the Cloud Foundry Foundation advisory, not working exploit code.