Capgo.app CVE-2026-100624

Requires an authenticated caller holding the app.build_native permission for the target app in Capgo.app (self-hosted or hosted OTA update platform for Capacitor). The attacker must first have a native build request created (which stores a 'pending' status and a one-hour upload_expires_at in build_requests), then send TUS proxy traffic (POST/PATCH/HEAD) to /build/upload/:jobId after that expiry has passed or after the build has moved beyond the upload phase. Exploitation is limited by: (1) the authentication and app.build_native permission requirement (PR:L, not anonymous), (2) the fact that the proxy only loads app_id, owner_org, builder_job_id, and upload_path and checks only the permission - so no additional exploit is needed once authenticated - and (3) the downstream builder service, which may independently reject the stale/out-of-phase request and thereby neutralize the flaw entirely.

This is a genuinely low-to-moderate real-world risk, and the signals are internally consistent rather than conflicting. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) scores 5.3 (medium) and maps to CWE-613 (Insufficient Session Expiration): a network-reachable but authenticated flaw (PR:L) with no user interaction, no confidentiality impact, and only low integrity/availability impact. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data - so exploitation status is 'no public exploit identified at time of analysis.' The impact ceiling is low because the flaw only lets a caller who ALREADY holds app.build_native permission keep writing to their own build upload session past the 1-hour expiry or beyond the upload phase; there is no privilege escalation, no cross-tenant access implied, and the description explicitly notes the separate builder service may independently reject the stale request, further blunting impact. The one metadata conflict worth flagging: the 'Information Disclosure' tag contradicts the CVSS vector, which sets VC:N (no confidentiality impact) - this is fundamentally a stale-session/authorization-window bug affecting integrity/availability, not disclosure. Bottom line: not a patch-tonight priority, but a legitimate defense-in-depth fix.

An authenticated user (or compromised API credential) holding app.build_native permission for an app creates a native build request, then continues sending POST/PATCH/HEAD TUS upload traffic to /build/upload/:jobId after the stored 1-hour upload_expires_at has elapsed or after the build has advanced past the upload phase, because the proxy only checks the permission and never re-validates expiry or build lifecycle state. No public exploit code is identified. Given AV:N/AC:L/PR:L/UI:N, the action is straightforward to script but requires valid authenticated access and depends on the downstream builder not rejecting the stale write.