Description

Capgo (Cap-go/capgo.app) server backend Supabase functions contain an incorrect authorization flaw in the API-key bundle promotion path. The PUT /bundle endpoint, available to "all" and "write" API keys, dispatches to setChannel, which authorizes with checkPermission(c, 'channel.promote_bundle', { appId: body.app_id }) and omits the request's channel_id. Because the omitted scope field is passed to rbac_check_permission_direct as SQL NULL, and channel-scope override evaluation is gated on p_channel_id IS NOT NULL, per-channel allow/deny overrides are never evaluated. A principal holding app-level channel.promote_bundle (granted by default to the app_developer and app_uploader roles) can therefore promote a bundle to a channel for which an explicit per-channel deny override exists, updating public.channels.version for the supplied channel_id; the target channel is only validated after authorization. The issue is confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and likely earlier versions; no patched version is known at the time of publication.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-26T14:16:43.837Z",
  "pubdate": "2026-09-26T14:16:43.837Z",
  "executiveSummary": "The Capgo server backend, specifically the Supabase functions, contains an incorrect authorization flaw within the bundle promotion process. The vulnerability resides in the PUT /bundle endpoint, where the authorization logic fails to propagate the required channel_id scope during permission verification.\nThis failure results in an authorization bypass where the system defaults to app-level permissions, completely ignoring explicit per-channel deny overrides. An attacker possessing 'all' or 'write' API keys with standard app-level permissions can promote unauthorized bundles to restricted channels, potentially overwriting live application versions.\nThe vulnerability affects the main branch up to commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43. The impact is significant as it undermines the integrity of the release management process, allowing unauthorized actors to perform administrative actions on channels they should be restricted from accessing. No fix is currently available.",
  "technicalDetails": "The vulnerability is located in the backend bundle promotion logic, specifically the handler for the PUT /bundle endpoint. This endpoint maps to the setChannel function, which performs a permission check using checkPermission(c, 'channel.promote_bundle', { appId: body.app_id }).\nThe root cause is a scope omission in the authorization call. While the function requires a channel_id to enforce granular security, the request's channel_id is omitted from the checkPermission arguments. Consequently, the internal rbac_check_permission_direct function receives a SQL NULL value for the p_channel_id parameter. Because the RBAC logic requires p_channel_id IS NOT NULL to process per-channel allow or deny overrides, the system defaults to evaluating only the user's app-level permissions.\nAn attacker with valid API credentials (specifically 'all' or 'write' roles) that include the app_developer or app_uploader roles possesses the app-level channel.promote_bundle permission. During the attack flow, the attacker sends a PUT request to the /bundle endpoint specifying an arbitrary channel_id. Because the authorization layer fails to bind the request to that specific channel_id, the RBAC check succeeds based on the broad app-level grant, bypassing any specific 'deny' policies assigned to that channel.\nThe target channel validation only occurs after the authorization check has passed, meaning the check is functionally useless for preventing unauthorized promotions to restricted channels. The post-exploitation impact includes the ability to modify the public.channels.version record for any channel associated with the app, effectively enabling the unauthorized deployment of arbitrary bundle versions to production or staging environments, bypassing organizational access controls."
}