Capgo’s native build TUS upload proxy authorizes a caller against a single build job identified by the supplied builder_job_id and validates only that job’s stored upload_path, but then forwards the user‑controlled TUS resource suffix taken from /build/upload/:jobId/* to the builder service while injecting Capgo’s privileged builder API key. Because the forwarded suffix is never bound to the authorized job’s upload_path or upload_session_key, a caller holding a valid ‘all’ or ‘write’ Capgo API key with app.build_native permission for one application can use its authorized proxy path for job A to write to the TUS upload resource of another job B, provided that resource suffix is known or exposed, corrupting that build’s artifacts. The flaw allows an attacker to modify or replace build artifacts, effectively tainting the native build output and potentially introducing malicious code. This represents a serious integrity violation (CWE‑441).

All Cap‑go:capgo.app installations are affected; the vulnerability applies to every released version, and no patch was available at the time of advisory publication.

The CVSS base score of 8.7 indicates a high‑severity flaw. The EPSS score is currently not available, so the exact likelihood of exploitation is unknown, but the lack of KEV listing suggests no documented public exploits yet. The attack vector requires possession of a Capgo API key with app.build_native permission. The attacker must also know or discover the suffix of the target job’s TUS resource, a condition that is often trivial to satisfy via enumeration or information leakage. Once those prerequisites are met, the attacker can overwrite or corrupt build artifacts with minimal effort, potentially enabling downstream compromise of distributed applications.