Capgo EUVD-2026-38738

Requires an authenticated Capgo account that holds the app.build_native permission on at least one app the attacker controls (so PR:L, not unauthenticated), and knowledge or guess of a victim jobId for the /build/start/:jobId or /build/cancel/:jobId endpoint. No user interaction is needed on the victim side, no non-default configuration is required, and the flaw is reachable on default Capgo deployments before 12.128.2. The principal limit on exploitation is jobId discoverability and the fact that the impact is confined to build-lifecycle actions - the bug does not directly expose source code or build artifacts of other tenants.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and score of 7.2 are consistent with the described condition: a low-privileged but authenticated tenant user can reach the endpoints over the network with no user interaction and no special attack requirements, and the VA:H reflects the high availability impact of cancelling or hijacking other tenants' production builds. Confidentiality and integrity are rated Low because the endpoints return builder status rather than tenant data, and they do not modify build artifacts directly. There is no CISA KEV listing, no EPSS data provided, and no public POC referenced - exploitation requires only a valid Capgo account with app.build_native permission on any app, which is a low bar for any paying or trial customer, so the real-world risk for Capgo-using organizations is meaningful despite the lack of in-the-wild exploitation signals. Note that the input mixes a CVSS 4.0 vector with a 7.2 score, which is internally consistent for v4.0 (High); no v3.1 vector was supplied, so v3.1-equivalent severity is inferred rather than confirmed.

An attacker registers (or already holds) a Capgo tenant with at least one app and grants themselves app.build_native on it, then enumerates or guesses victim jobIds - for example numeric or UUID identifiers leaked via logs, status pages, or prior interactions - and issues POST /build/cancel/:victimJobId with their own app_id in the body, causing the trusted builder to terminate the victim's in-flight production build. Repeating the pattern against /build/start/:jobId lets the attacker re-trigger or replay builder jobs on other tenants' behalf, racking up compute charges and disrupting release pipelines. No public POC is referenced, but the described request shape is trivially reproducible from the advisory.