Answer in brief
CVE-2026-100624 records a Medium severity (CVSS 5.3) vulnerability in Capgo.app before 12.264.5 Upload Expiry Bypass via build upload. The current sources do not mark it as known exploited. The current feed maps Cap-go/capgo.app (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Cap-go/capgo.app (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Cap-go/capgo.appgeneric | >=0 <12.264.5 | 12.264.5 |
Published upstream
Sep 26, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 26, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 26, 2026
Capgo.app before 12.264.5 does not enforce upload expiry or build lifecycle state in the /build/upload/:jobId TUS proxy endpoint. When a native build request is created, an upload_expires_at timestamp (one hour) and a 'pending' status are stored in build_requests, but the upload proxy loads only app_id, owner_org, builder_job_id, and upload_path and checks only the app.build_native permission before forwarding POST, PATCH, and HEAD requests to the internal builder. As a result, an authenticated caller holding app.build_native permission for the app can continue writing to the build upload session after the stored expiry has passed or after the build has moved beyond the upload phase, unless the separate builder service independently rejects the request. The issue is fixed in 12.264.5.
Quoted source text, attributed separately from HOL analysis.