Evidence used
- No CISA KEV confirmation is currently recorded.
- A structured source references public exploit or proof-of-concept material.
- EPSS is 0.44% for the current model date.
BlackTreeCVE IntelligenceCap-go · capgo.app
Official source article: GitHub GHSA-5HJR-XHX8-X5J7 ↗. Check the applicable product and release in the original source.
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
Fix not verifiedCapgo (capgo.app) backend through 12.242.4 does not validate parent-child delegation when processing the x-limited-key-id header. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, while hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding and validateSubkeyUser() only compares owning user IDs. Because Capgo treats API keys as independent RBAC principals with separate role bindings, an authenticated apikey_manager API key with no application access can supply the numeric ID of a more privileged same-owner key and have the middleware replace the authenticated principal and effective API-key secret with that key (setSubkeyAuthContext), exercising an app_admin sibling's permissions without knowing or submitting its secret. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568) after the fix for GHSA-8h52-44r7-w343; at the time of the advisory no patched version was available.
Capgo (capgo.app) backend through 12.242.4 does not validate parent-child delegation when processing the x-limited-key-id header. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, while hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding and validateSubkeyUser() only compares owning user IDs. Because Capgo treats API keys as independent RBAC principals with separate role bindings, an authenticated apikey_manager API key with no application access can supply the numeric ID of a more privileged same-owner key and have the middleware replace the authenticated principal and effective API-key secret with that key (setSubkeyAuthContext), exercising an app_admin sibling's permissions without knowing or submitting its secret. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568) after the fix for GHSA-8h52-44r7-w343; at the time of the advisory no patched version was available.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
Capgo (capgo.app) backend through 12.242.4 does not validate parent-child delegation when processing the x-limited-key-id header. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts resolves the attacker-supplied numeric API key ID using only the key ID, its expiration state, and the authenticating key's user_id, while hasLimitedRbacSubkeyScope() accepts any key with a non-organization (e.g., app-scoped) RBAC binding and validateSubkeyUser() only compares owning user IDs. Because Capgo treats API keys as independent RBAC principals with separate role bindings, an authenticated apikey_manager API key with no application access can supply the numeric ID of a more privileged same-owner key and have the middleware replace the authenticated principal and effective API-key secret with that key (setSubkeyAuthContext), exercising an app_admin sibling's permissions without knowing or submitting its secret. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568) after the fix for GHSA-8h52-44r7-w343; at the time of the advisory no patched version was available.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
CISA Vulnrichment records proof-of-concept exploitation in its SSVC data. BlackTree has not independently executed or validated exploit material.
CWE-863: Incorrect Authorization. The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 10 Sept 2026 · Last source change 30 Sept 2026, 17:20 UTC · CWE-863 · Incorrect Authorization
Core structured fields are present and their contributing authorities are shown above.