Capgo EUVD-2026-87717

Exploitation requires the attacker to possess a valid, previously-issued cached bundle URL for the capgo.app public file read endpoint; the flaw is that this endpoint does not verify an artifact's deletion status before serving it. No authentication is required (PR:N) and no user interaction is needed, but the attacker cannot generate access from nothing - a leaked/recorded cache URL for a since-deleted bundle is the concrete precondition. A cache hit is required to trigger the R2 restoration side-effect. Affected: capgo.app through 12.129.0. The dependence on a valid cached URL and on the target bundle being one that was cached-then-deleted is the primary limiter on realistic risk.

The vendor (VulnCheck) CVSS 4.0 vector rates this 8.7 with AV:N/AC:L/AT:N/PR:N/UI:N/VC:H - network-reachable, unauthenticated, low complexity, high confidentiality impact. However, the real-world risk is materially lower than 8.7 implies. Two limiters temper it: (1) exploitation requires possessing a valid previously-issued cached bundle URL - this is an attack requirement (AT:P), not a truly unconditional attack, so VC:H is generous; (2) the disclosed content is DELETED OTA bundles, i.e. artifacts an operator already chose to remove, which are also the same JS/asset bundles that were at some point publicly served to devices. The description ALSO establishes an integrity effect the vendor's VI:N ignores: a cache hit RESTORES the deleted object back into R2 storage, reviving data that was meant to be gone. So this is a mixed disclosure+integrity issue mislabeled as pure info disclosure. No EPSS score, no CISA KEV listing, and no public exploit are present in the input - there is no evidence of active exploitation or automation. Net: a real but moderate-priority defect, not a drop-everything CVSS-8.7 emergency. Key data gap: the guessability/enumerability of cached URLs is undocumented - if URLs are unpredictable and expire, real risk is low; if they are stable and leak (logs, CDN caches, referrers), risk rises. Verify with vendor.

An attacker who recorded or intercepted a cached bundle URL (from CDN logs, browser history, or a shared link) that was later deleted by the app owner replays that URL against the public file read endpoint. Because the endpoint never checks deletion status, the request is served from cache and simultaneously re-writes the deleted artifact back into R2, letting the attacker retrieve removed bundle contents and undo the deletion. No public exploit code is identified at time of analysis.