Capgo EUVD-2026-87716

Requires an attacker to hold a valid Capgo API key with bundle write/upload permission, and the target bundle version must be in the r2-direct storage_provider state - the state the enforce_encrypted_bundle_trigger/check_encrypted_bundle_on_insert content lock exempts, leaving columns (name, app_id, session_key, key_id, storage_provider, r2_path, external_url, checksum, manifest, native_packages) mutable. The version must also be assigned to a channel so that the /updates endpoint (which filters only deleted versions and does not exclude r2-direct rows) selects it for delivery. Limiting factors: exploitation is confined to bundles the API key can already write, no unauthenticated path exists, and impact is metadata tampering served over OTA rather than direct code execution on the server. Affects all versions with no patch available at publication.

This is a moderate, authenticated integrity issue - not a critical or widely-exploitable flaw. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N, score 5.3) is internally consistent with the description: network-reachable via PostgREST, low complexity, but requires an attacker to already hold a valid Capgo API key with bundle write/upload permission (PR:L), and the only impact is limited integrity (VI:L) - no confidentiality or availability loss. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so exploitation status is 'no public exploit identified at time of analysis.' The genuine concern is qualitative rather than statistical: this is an OTA update delivery path, so tampered checksum/session_key/manifest metadata is served to downstream devices, giving the bug a supply-chain flavor that a raw 5.3 understates. However, it is gated behind possession of a write-capable API key and there is no patch available at publication, so it should be treated as a defense-in-depth immutability regression to monitor rather than an emergency. Note the CWE is CWE-284 (Improper Access Control) and the description explicitly says the attacker already holds a valid API key - so the 'Authentication Bypass' tag is a misnomer; this is an authorization/content-lock bypass by an authenticated principal.

An attacker who has obtained a Capgo API key with bundle write/upload permission creates or retains a bundle version in the r2-direct storage_provider state (which the content-lock trigger exempts), assigns it to a channel, then issues direct PostgREST requests to mutate delivery-critical columns such as checksum, session_key, and manifest. Because the /updates join does not exclude r2-direct versions, the altered bundle metadata is then served to end-user devices via OTA. No public exploit code is identified in the supplied data.