CVE-2026-56233: Capgo Path Traversal in Builder Upload Proxy – Privilege Escalation Risk
Capgo versions before 12.128.2 contain a path traversal vulnerability that allows authenticated users with build permissions to upload files to unintended locations on the server. By manipulating the upload path with traversal sequences (like `../`), attackers can bypass upload restrictions and access internal administrative endpoints. This grants them privileged API access that should only be available to administrators, leading to server-level privilege escalation. The vulnerability requires prior authentication and build permissions, but once exploited, results in significant system compromise.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.3 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
- Weaknesses (CWE)
- CWE-22
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-30 / 2026-07-01
NVD description (verbatim)
Capgo before 12.128.2 contains a path traversal vulnerability in the builder upload proxy that allows authenticated users with build permissions to bypass upload restrictions. Attackers can append traversal sequences to the upload path, which are normalized by the WHATWG URL parser, enabling access to internal administrative endpoints with the privileged BUILDER_API_KEY header and resulting in server-side privilege escalation.
3 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-56233 is a path traversal flaw in Capgo's builder upload proxy mechanism. The vulnerability stems from insufficient path validation: while the application attempts to normalize paths using the WHATWG URL parser, this normalization does not adequately prevent traversal sequences from reaching the filesystem or routing layer. Authenticated users with build permissions can craft malicious upload requests containing path traversal payloads that, after normalization, resolve to administrative endpoints. When these requests are processed, they are issued with the BUILDER_API_KEY header, granting them the same privileges as the builder service itself. This allows attackers to perform actions restricted to privileged accounts, including potential configuration changes, credential theft, or system reconnaissance.
Business impact
Organizations using Capgo for build automation face potential insider threat and supply-chain risk. An attacker with build account access (whether through credential compromise or malicious employee) can escalate to full server administration without additional exploitation steps. This threatens the integrity of build artifacts, the confidentiality of private keys and secrets stored on build infrastructure, and the availability of the CI/CD pipeline. For teams using Capgo to manage mobile app builds, compromise could allow injection of malicious code into production releases, affecting end-user security and potentially triggering compliance violations or reputational damage.
Affected systems
Capgo versions prior to 12.128.2 are affected. The vulnerability requires that the attacker possess valid authentication credentials and build permissions on the target Capgo instance. It does not require user interaction or network access restrictions beyond standard HTTP connectivity. The attack surface includes any Capgo deployment accepting authenticated build uploads, which is typically exposed to developers and CI/CD systems within an organization.
Exploitability
Exploitability is moderate to high. The vulnerability requires prior authentication and build-level permissions, which narrows the attack surface compared to unauthenticated exploits. However, build credentials are often widely distributed across development teams and CI/CD environments, increasing the likelihood of exposure or compromise. The WHATWG URL parser normalization may create a false sense of security; documented techniques for bypassing similar parsers exist. No evidence of public exploit code or active exploitation has been confirmed at publication, but the conceptual simplicity of path traversal attacks suggests rapid weaponization is probable once details circulate.
Remediation
Immediately upgrade Capgo to version 12.128.2 or later. This version addresses the path traversal validation issue. For organizations unable to patch immediately, implement network-level controls to restrict the builder upload endpoint to trusted CI/CD systems and developer networks. Review and rotate build API keys, audit build account access logs for suspicious upload patterns, and consider temporarily restricting build permissions to a minimal set of users pending patching.
Patch guidance
Verify compatibility of version 12.128.2 against your current Capgo deployment and dependent services. Review the vendor's release notes and changelog for any breaking changes or migration steps. Test the patch in a non-production build environment first. After patching, validate that build permissions and upload functionality continue to work as expected. Consider scheduling the upgrade during a maintenance window to minimize disruption to active build pipelines.
Detection guidance
Monitor build upload requests for suspicious path patterns, particularly those containing `../`, `..\`, URL-encoded variants (`%2e%2e%2f`), or repeated slash sequences. Log and alert on upload requests that deviate from expected file paths or that target administrative endpoints. Review authentication logs for build account access from unexpected IP ranges or at unusual times. Examine web server logs for 400-level or 500-level errors during upload operations, which may indicate failed traversal attempts. If available, inspect the builder proxy logs for requests containing the BUILDER_API_KEY header being used for unexpected endpoints.
Why prioritize this
This vulnerability merits urgent attention due to its HIGH CVSS score (8.3), the direct path to privilege escalation, and the likelihood that build credentials are already distributed across development infrastructure. While it requires authentication, the blast radius—including potential compromise of release artifacts and embedded secrets—justifies prioritizing this patch ahead of many unauthenticated vulnerabilities. The age of the advisory (published June 2026) means active patching campaigns may already be underway.
Risk score, explained
The CVSS 3.1 score of 8.3 reflects: network-accessible vector (AV:N), low attack complexity (AC:L), requirement for low-level privileges (PR:L), no user interaction (UI:N), unchanged scope (S:U), high impact on confidentiality and integrity (C:H, I:H), and low impact on availability (A:L). The score appropriately penalizes the authentication requirement while recognizing that authenticated users with modest privileges can achieve high-impact outcomes. The intact scope (not crossing trust boundaries) prevents a critical rating, but the combination of confidentiality and integrity impact to the server justifies the HIGH classification.
Frequently asked questions
Can an unauthenticated attacker exploit this vulnerability?
No. The vulnerability requires valid authentication credentials and build permissions. However, build credentials are often shared across development teams, CI/CD systems, and sometimes stored in configuration files, increasing the practical risk of compromise.
What exactly can an attacker do after exploiting this?
An attacker gains the ability to interact with administrative endpoints using the BUILDER_API_KEY, which is intended only for the builder service itself. This can include accessing privileged build configurations, modifying build parameters, exfiltrating secrets, or triggering unauthorized build operations.
Does the WHATWG URL parser protect against this attack?
The parser does provide some normalization, but the implementation in Capgo's upload proxy is insufficient. The vulnerability shows that normalization alone does not prevent all traversal sequences from reaching their intended targets. Proper mitigation requires strict allowlist validation, not just parser normalization.
If we rotate our build API keys after patching, are we fully remediated?
Patching is the primary remediation. Key rotation is a secondary hardening step that reduces the window of exposure if keys were compromised during an undetected exploit. Combined with audit log review, it provides defense-in-depth but should not be considered a substitute for patching.
This analysis is based on the published CVE record and vendor advisory as of the date indicated. No active exploitation or public proof-of-concept code has been confirmed at the time of publication, but organizations should assume adversaries are developing exploits rapidly. Patch testing should be conducted in isolated environments before production deployment. SEC.co provides this information for security planning purposes; consult your vendor's official advisories and your organization's security team for final patching decisions and timelines. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2016-20076HIGHWordPress Simple-Backup 2.7.11 Unauthenticated File Access & Deletion Vulnerability
- CVE-2016-20081HIGHHB Audio Gallery Lite Path Traversal Vulnerability – Unauthenticated File Download
- CVE-2017-20248HIGHApptha Slider Gallery Path Traversal Vulnerability
- CVE-2017-20250HIGHMac Photo Gallery 3.0 Path Traversal File Download Vulnerability
- CVE-2018-25408HIGHOpen ISES Project Path Traversal Vulnerability (High Severity)
- CVE-2024-32729HIGHPath Traversal in QuantumCloud Conversational Forms for ChatBot (CVSS 7.5)
- CVE-2024-40646HIGHVertex Path Traversal Vulnerability – Remote File Access Risk
- CVE-2025-60223HIGHWPBot Pro Arbitrary File Deletion Vulnerability – HIGH Risk Exploit