CVE-2026-100625 in Capgo
Summary
by MITRE • 09/26/2026
Capgo (capgo.app) exposes a native build TUS upload proxy (supabase/functions/_backend/public/build/upload.ts) that 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. All versions are affected; no patch was available at the time of advisory publication.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Capgo involves a critical authorization bypass within its native build TUS upload proxy mechanism located at supabase/functions/_backend/public/build/upload.ts. This component is designed to facilitate file uploads for application builds by acting as an intermediary between clients and the internal builder service. The security flaw stems from a fundamental disconnect between the authentication layer and the resource access control logic. Specifically, while the system correctly validates that the caller possesses valid credentials—such as an all or write Capgo API key with app.build_native permission—and verifies that these credentials are authorized for a specific build job identified by the supplied builder_job_id, it fails to enforce this authorization on the actual data destination. The validation process checks only whether the provided job ID is associated with a stored upload_path and validates against that static path configuration rather than binding the active session or resource context to the authenticated request parameters.
This architectural weakness allows an attacker who holds legitimate API keys for one application to manipulate uploads intended for different build jobs within the same organization or potentially across organizations if identifiers are predictable. The core of the exploit lies in how the proxy handles the TUS resource suffix extracted from the URL path /build/upload/:jobId/*. Although the initial request is authenticated against job A, the system forwards a user-controlled suffix to the builder service without verifying that this suffix corresponds to the authorized upload_path or upload_session_key for job A. By injecting Capgo's privileged builder API key into the forwarded request, the proxy grants elevated access to the underlying storage infrastructure. Consequently, if an attacker can determine or guess the resource suffix associated with a different build job B, they can route their malicious payload through the authenticated endpoint of job A and successfully write data to job B’s upload resources.
The operational impact of this vulnerability is severe, primarily centering on integrity violations and potential supply chain compromise. An adversary who exploits this flaw can corrupt the artifacts generated for another developer's build process by overwriting or injecting unauthorized files into the TUS upload resource of a target job. This corruption may lead to failed builds, deployment of malicious code if the compromised artifacts are subsequently used in production environments, or disruption of continuous integration pipelines. Since the vulnerability relies on known or exposed suffixes, it is particularly dangerous in scenarios where build identifiers or file paths follow predictable patterns, allowing for targeted attacks against specific high-value targets within a development ecosystem. The lack of binding between the authenticated job context and the actual resource being modified means that standard API key permissions do not provide adequate isolation between distinct build processes.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Given that no patch was available at the time of advisory publication, organizations relying on Capgo should immediately restrict network access to the affected endpoint if possible or implement strict rate limiting and monitoring for anomalous upload patterns. From a development perspective, future implementations must enforce strict object-level authorization by ensuring that every write operation validates that the target resource identifier matches the authorized job context associated with the caller's credentials. This includes binding the upload_session_key directly to the request lifecycle rather than relying solely on static path configurations. Additionally, implementing randomized and non-guessable identifiers for build jobs and their associated resources would significantly reduce the attack surface by preventing adversaries from predicting valid suffixes for other jobs.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to properly validate user input against authorization policies before performing sensitive operations. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as the attacker leverages legitimate API credentials but abuses their scope through flawed access control logic rather than credential theft. The scenario exemplifies how insufficient separation of duties and lack of context binding in proxy services can lead to privilege escalation effects even when initial authentication appears secure. Addressing this requires a shift toward zero-trust principles where every resource access is explicitly verified against the specific identity and intent of the caller, ensuring that authorization checks are dynamic and tightly coupled with the actual data being modified rather than static configuration values.