Executive brief
Capgo, a tool for managing application deployments, contains a flaw in how it handles the transfer of applications between different organizations. When an application is moved, its deployment history records are not correctly updated to reflect the new owner. This allows the original organization to retain unauthorized access to sensitive deployment logs, while the new owner may be unable to view the history of the application they now control.
Technical details
An improper authorization vulnerability (CWE-285) exists in Capgo's `transfer_app()` function due to an incomplete database update during application migration between organizations. While the function updates the `owner_org` field for the application and its versions, it omits the `public.deploy_history` table. Because Row-Level Security (RLS) policies for deployment history are based on the `owner_org` column within that specific table rather than a join to the current application owner, the authorization boundary remains tied to the original organization. A remote attacker with standard user privileges can exploit this to maintain access to deployment logs of a transferred app or disrupt the data integrity for the new owner. The issue is resolved in version 12.128.2.
Affected products
- Capgo Capgo before 12.128.2
Timeline
- 2026-05-07: advisory: GitHub Security Advisory published
- 2026-07-08: disclosed: NVD publication date