Capgo EUVD-2026-87713

Requires an authenticated, app-limited WRITE API key for at least one app on the Capgo instance (per the advisory description), so this is not remote-unauthenticated despite the vendor's PR:N. The attacker uses the PUT /app/:id endpoint's user-controlled icon parameter with a path pointing outside the target app's own image namespace (org/{owner_org}/{app_id}/...). Exploitation depends on the on_app_update trigger and the cleanStoredImageMetadata() worker running with service-role (supabaseAdmin()) credentials, which is the default server-side design. What limits impact: the attacker cannot READ the targeted private object (no confidentiality leak), cannot supply arbitrary replacement content (the worker re-uploads the referenced object after metadata cleaning), and must already possess a scoped write API key on the platform.

This is a genuine cross-tenant authorization flaw (CWE-639 / confused-deputy) but the vendor's 8.7 CVSS 4.0 score materially overstates real-world severity. The vendor vector (AV:N/AC:L/PR:N/UI:N/VC:H/VI:N/VA:N) is internally inconsistent with its own description on two points: (1) it sets PR:N despite the description explicitly requiring 'an authenticated holder of an app-limited write API key' - this is NOT unauthenticated, so PR should be at least PR:L; (2) it sets VC:H (high confidentiality) even though the attack causes the privileged worker to REWRITE an out-of-scope object via cleanStoredImageMetadata() and never returns that object's contents to the attacker - the actual impact is INTEGRITY (tampering with another org's private storage object across the RLS authority boundary), not confidentiality. Corrected, this is a scope-changing integrity-only issue of bounded impact (the worker re-uploads the referenced object; the attacker does not control replacement content beyond metadata stripping/corruption). No EPSS score, no CISA KEV listing, and no public proof-of-concept are present in the provided data - exploitation signals are absent. Net: a real, valid confused-deputy privilege boundary violation worth patching, but not the near-critical priority the raw 8.7 implies; realistic severity is medium.

An attacker who legitimately holds an app-limited write API key for one app issues PUT /app/:id with a crafted icon value pointing outside that app's own storage namespace (e.g. another organization's private logo path). Because the endpoint does not validate the path belongs to org/{owner_org}/{app_id}/..., the on_app_update trigger fires and the service-role worker downloads and re-uploads that out-of-scope private object with upsert:true, tampering with an object the API key could never touch directly under Supabase Storage RLS. No public exploit code is identified at time of analysis.