Skip to main content
CVE-2026-88862VulnerabilityPublished 09/10/2026Updated 09/30/2026

CVE-2026-88862: Cap-go capgo.app · Incorrect Authorization

Affects Cap-go capgo.appSource CVE Database V5

0

Not known to be exploited · CVSS 8.7 High.

Data as of 10/25/2026, 16:58:58 UTC

CVSS 4.0 base score
8.7High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

Affected software

ProductAffectedFixed in
Cap-gocapgo.appAffected
  • <=12.242.4
Fixed in–

AI-suggested

At the time of the advisory, no patched version was available. Users should monitor the vendor's official channels for updates and apply patches once released. Until then, restrict issuance and use of apikey_manager keys to trusted parties only and consider additional access controls to limit potential abuse.

Description

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.

Impact

An attacker with an authenticated apikey_manager key can escalate privileges by impersonating a more privileged sibling API key owned by the same user. This allows unauthorized access to application administration capabilities without needing the secret of the privileged key, potentially leading to unauthorized actions within the application environment.

Summary

Capgo backend versions up to 12.242.4 have a flaw in the authorization logic related to API key delegation. The function checkKeyByIdPg() resolves API keys based on key ID, expiration, and user ID but does not verify proper delegation hierarchy. Because API keys are treated as independent RBAC principals, an authenticated apikey_manager key lacking application access can supply the numeric ID of a more privileged key owned by the same user. This causes the middleware to replace the authenticated principal and effective API key secret with that of the privileged key, allowing unauthorized use of app_admin permissions without the secret. The vulnerability was confirmed on version 12.242.4 after a previous fix (GHSA-8h52-44r7-w343), and no patch was available at the time of the advisory.

References

Community reviews

Loading reviews…