CVE-2026-100627: Capgo bundle promotion API channel RBAC deny override bypass
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.promotebundle', { appId: body.appid }) and omits the request's channelid. Because the omitted scope field is passed to rbaccheckpermissiondirect as SQL NULL, and channel-scope override evaluation is gated on pchannelid IS NOT NULL, per-channel allow/deny overrides are never evaluated. A principal holding app-level channel.promotebundle (granted by default to the appdeveloper and appuploader 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 channelid; 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.
Affected Software
Event History
Frequently Asked Questions
Which principals can bypass a channel-specific deny override?
A principal needs app-level channel.promote_bundle permission and an API key with either the "all" or "write" capability. The app_developer and app_uploader roles receive the required app-level permission by default.
Are deployments using explicit per-channel deny overrides still exposed?
Yes. The affected authorization path does not evaluate channel-scope allow or deny overrides, so an explicit deny for the target channel does not prevent a permitted app-level principal from promoting a bundle to it.
What can an attacker change through this issue?
They can promote a bundle to a supplied channel and update that channel's public.channels.version value. The target channel is validated only after the authorization decision.
Is a patched version available?
No patched version is known at the time of publication. The issue is confirmed on main at commit de66fa51e7ff2f50283cc1455c3d80ab3eb0ae43 and is likely present in earlier versions.