CVE-2026-56293: Capgo Authorization Bypass Vulnerability

CVE-2026-56293 Overview

CVE-2026-56293 is an authorization flaw in Capgo versions prior to 12.128.2. The vulnerability resides in the transfer_app() function, which fails to update the deploy_history.owner_org field when applications are transferred between organizations. This omission produces stale cross-organization authorization state in deployment history records.

Attackers with low-privilege access in the source organization can exploit this flaw to retain unauthorized visibility into deployment history for transferred applications. The destination organization may also lose legitimate access to those same records. The issue is classified as an Improper Authorization weakness [CWE-285].

Critical Impact
Stale authorization data in deploy_history allows the original organization to retain access to deployment records of transferred applications, while the receiving organization loses access to records it should own.

Affected Products

Capgo versions before 12.128.2
Deployments relying on the transfer_app() cross-organization workflow
Multi-tenant Capgo installations with shared deployment history

Discovery Timeline

2026-07-08 - CVE-2026-56293 published to the National Vulnerability Database (NVD)
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-56293

Vulnerability Analysis

Capgo is an over-the-air (OTA) update platform for Capacitor mobile applications. It supports multi-tenant deployments where applications can be transferred between organizations using the transfer_app() routine. The routine updates ownership metadata on the application record, but it does not propagate the ownership change to the deploy_history table.

As a result, historical deployment records continue to reference the previous owner_org value. The authorization layer uses deploy_history.owner_org to gate access to deployment records. Because the field remains stale, access decisions for those records diverge from the actual ownership of the parent application.

The flaw is a business logic error in the multi-tenant authorization model rather than an injection or memory safety issue. Exploitation requires an authenticated account in the source organization and does not require user interaction.

Root Cause

The transfer_app() implementation performs an incomplete ownership update. It changes the primary application ownership record but omits an update to the deploy_history.owner_org column for related deployment history rows. This creates a mismatch between the current owner of an application and the recorded owner of its deployment history.

Attack Vector

An attacker with a low-privilege account in the source organization retains query access to deployment history rows after the transfer completes. Conversely, users in the destination organization are denied access to deployment history rows they legitimately own. The vulnerability manifests entirely through the application's authorization checks against stale database state. Refer to the GitHub Security Advisory GHSA-854w-xj7g-prv3 and the VulnCheck Security Advisory for further technical detail.

Detection Methods for CVE-2026-56293

Indicators of Compromise

Mismatched values between the owner_org field on an application record and the owner_org field on its corresponding deploy_history rows.
Access log entries showing users from a prior organization reading deployment history for applications now owned by another organization.
Support tickets from destination organizations reporting missing deployment history after an application transfer.

Detection Strategies

Run periodic database consistency queries that join application ownership against deploy_history.owner_org and flag divergent rows.
Audit API access to deployment history endpoints and correlate the requesting user's organization with the current owner of the target application.
Review historical transfer_app() invocations and validate that all downstream ownership fields were updated atomically.

Monitoring Recommendations

Enable audit logging on all transfer_app() calls, including before-and-after state of ownership fields.
Alert on any read access to deploy_history where the caller's organization does not match the current application owner_org.
Track anomalous cross-organization data access patterns in centralized log aggregation for review by the security team.

How to Mitigate CVE-2026-56293

Immediate Actions Required

Upgrade Capgo to version 12.128.2 or later, which corrects the transfer_app() ownership propagation logic.
Enumerate all historical application transfers and reconcile deploy_history.owner_org to match the current application owner.
Revoke any lingering sessions or API tokens for users in source organizations that transferred applications during the affected window.

Patch Information

The vendor addressed the vulnerability in Capgo 12.128.2. The fix ensures transfer_app() updates deploy_history.owner_org alongside the primary application ownership record. Details are published in the GitHub Security Advisory GHSA-854w-xj7g-prv3.

Workarounds

If upgrading is not immediately feasible, restrict use of the transfer_app() workflow through administrative policy.
Manually update deploy_history.owner_org after each transfer using an out-of-band database migration that mirrors application ownership.
Add an application-layer authorization check that resolves deployment history ownership through the current applications.owner_org value rather than the cached deploy_history.owner_org column.

bash

# Configuration example: reconcile deploy_history ownership after transfer
# Review the advisory before applying in production
UPDATE deploy_history dh
SET owner_org = a.owner_org
FROM applications a
WHERE dh.app_id = a.id
  AND dh.owner_org <> a.owner_org;