CVE-2026-88862

Executive Summary

CVE-2026-88862 is an improper authorization / privilege escalation vulnerability (CWE-863) in the Capgo (capgo.app) backend through version 12.242.4. The middleware responsible for validating the x-limited-key-id header fails to enforce parent-child delegation, allowing an authenticated, low-privilege apikey_manager API key to assume the identity and effective secret of a more privileged, same-owner API key (such as an app_admin sibling) simply by supplying that key's numeric ID. When exploited, the attacker acts as the hijacked principal, exercising elevated RBAC permissions without ever knowing or transmitting the victim key's secret.

Because the flaw requires only a valid low-privilege authenticated API key and no user interaction, it provides a reliable privilege-escalation primitive against Capgo backends. With a CVSS v3.1 score of 8.8 (High) and high Confidentiality, Integrity, and Availability impact, affected organizations must assume full compromise of any RBAC principal sharing an owning user with a low-privilege key. No patch is currently available, and no CISA KEV listing or public PoC exists as of this writing.

Technical Analysis

Capgo is a live-update and over-the-air (OTA) delivery platform for mobile applications. Its backend uses Supabase Edge Functions and a Hono-based middleware layer to authenticate API requests. Within the backend, API keys are treated as independent RBAC principals: each key carries its own role binding and its own owning user_id. The middleware is expected to enforce delegation semantics — that a key presented in the x-limited-key-id header is genuinely a subordinate (child) of the authenticating (parent) key.

The vulnerability stems from that delegation check being absent or incomplete. The NVD description identifies three concrete implementation points:

1. checkKeyByIdPg() in supabase/functions/_backend/utils/hono_middleware.ts — resolves the attacker-supplied numeric API key ID using only:

   • the key ID itself,
   • the key's expiration state,
   • the authenticating key's user_id.

   Critically, it does not verify that the resolved key is a child of (i.e., delegated by) the authenticating key. Any key belonging to the same user_id is therefore reachable.

2. hasLimitedRbacSubkeyScope() — accepts any key with a non-organization (e.g., app-scoped) RBAC binding. It does not constrain the scope to a binding that is subordinate to the parent key.

3. validateSubkeyUser() — only compares owning user IDs. It confirms that parent and child share the same user_id, but never checks the parent-child relationship between keys.

The combined effect is that the "limited key" mechanism — intended to let an API key delegate a narrower set of permissions to a subkey — instead allows lateral movement to any sibling key owned by the same user. When the resolved key is accepted, the middleware calls setSubkeyAuthContext, which replaces the authenticated principal and the effective API-key secret with those of the resolved key. The attacker's original apikey_manager credential is discarded in favor of the more privileged sibling's context.

Because Capgo API keys function as RBAC principals with separate role bindings rather than as tokens derived from a single identity, this substitution grants the effective permissions of the target key. The description specifically calls out the app_admin role as an example sibling whose permissions can be exercised.

The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568). Notably, this reproduction occurred after the fix for a prior advisory, GHSA-8h52-44r7-w343, indicating that either the earlier fix was incomplete or a regression introduced the delegation gap. At the time of the advisory, no patched version was available.

Root cause classification: CWE-863 — Incorrect Authorization, specifically a broken object-level / principal-level authorization check (an IDOR-adjacent flaw where the "object" is an API key principal referenced by a numeric ID in a request header).

Exploitation Scenarios

No public PoC or exploit code is available; the chain below is inferred directly from the NVD description and the CVSS vector (network-exploitable, low privilege required, no user interaction).

1. Reconnaissance / target identification. The attacker needs network reachability to the Capgo backend endpoints that process the x-limited-key-id header, plus a valid low-privilege apikey_manager API key. Reconnaissance consists of identifying candidate sibling keys owned by the same user — most plausibly by enumerating numeric key IDs reachable via the same owner, since the only binding enforced is the owning user_id.

2. Triggering the flaw. The attacker sends an authenticated request to the Capgo backend while presenting their legitimate apikey_manager key, and adds the x-limited-key-id header containing the numeric ID of a more privileged key (for example, an app_admin key) owned by the same user_id. The middleware invokes checkKeyByIdPg(), which resolves the supplied ID using the ID, expiration state, and owner user_id — but performs no parent-child validation. hasLimitedRbacSubkeyScope() accepts the target because it carries a non-organization (app-scoped) RBAC binding, and validateSubkeyUser() passes because the owner user_id matches. Since capability checks are absent at each stage, the malicious delegation is accepted.

3. Execution / principal substitution. Once the subkey is accepted, setSubkeyAuthContext replaces the authenticated principal and effective API-key secret with those of the resolved key. The attacker never needs to know or transmit the victim key's secret. From the backend's perspective, the request now runs as the privileged sibling.

4. Post-exploitation impact. The attacker exercises the hijacked key's RBAC permissions — for example, app_admin capabilities — resulting in unauthorized read and write access (C:H/I:H) and potential service disruption (A:H) within the scope of the compromised principal's applications. Because the substitution happens server-side at the middleware layer, there is no need for the attacker to possess the higher-privilege credential at any point.

Impact Assessment

This is a network-exploitable (AV:N), low-complexity (AC:L), low-privilege-required (PR:L), no-user-interaction (UI:N) privilege escalation with high impact across all three CIA dimensions. The CVSS v3.1 base score is 8.8 (High).

• Confidentiality (C:H): The attacker can read any data the hijacked principal is authorized to access.
• Integrity (I:H): The attacker can perform any write operations the hijacked principal permits — including, in the case of an admin sibling, configuration or release-management changes.
• Availability (A:H): Actions performed as a privileged principal can disrupt the affected applications or Capgo release delivery.

Blast radius. Any Capgo deployment (through 12.242.4) where a user account holds multiple API keys with divergent privilege levels is affected. The attack is scoped to keys sharing the same owning user_id, so cross-tenant escalation is not described — but within a single tenant, all sibling keys are reachable. Organizations that rely on "limited keys" as a least-privilege control for CI/CD, contractor access, or automation should treat that control as broken and assume those keys can reach sibling permissions.

Business impact. Because Capgo is used for live/OTA mobile application updates, unauthorized access to an app_admin-equivalent principal could allow manipulation of release channels and application content delivered to end users. That elevates the issue beyond a data-access bug to a potential integrity compromise of downstream mobile clients, though the description does not detail specific update-manipulation APIs, so this remains an extrapolation of RBAC scope rather than a confirmed capability.

Detection Guidance

Detection should focus on anomalous use of the x-limited-key-id header, especially where the presented limited key's ID does not correspond to a key that the authenticating key is legitimately delegated to manage. Because the flaw is an authorization-context substitution, the strongest signals are request-header anomalies and correlated principals.

Sigma Rule

title: Capgo Backend Privilege Escalation via x-limited-key-id Delegation Bypass
id: 8c1a0f2e-7b4d-4f9a-9c2e-capgo88862
status: experimental
description: Detects requests supplying the x-limited-key-id header that reference API keys not associated with the presented authenticating key, indicative of CVE-2026-88862 delegation bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-88862
author: ValtersIT Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
detection:
  selection_header:
    cs-header|contains: 'x-limited-key-id'
  selection_suspicious:
    cs-uri|contains:
      - '/functions/'
      - '/api/'
  condition: selection_header and selection_suspicious
fields:
  - c-ip
  - cs-method
  - cs-uri
  - cs-header
falsepositives:
  - Legitimate delegation by an authorized parent key
level: high

YARA Rule

rule CVE_2026_88862_Capgo_Delegation_Bypass
{
    meta:
        description = "Detects references to Capgo vulnerable middleware delegation logic associated with CVE-2026-88862"
        author = "ValtersIT Threat Intelligence"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-88862"
        severity = "high"

    strings:
        $fn1 = "checkKeyByIdPg" ascii wide
        $fn2 = "hasLimitedRbacSubkeyScope" ascii wide
        $fn3 = "validateSubkeyUser" ascii wide
        $fn4 = "setSubkeyAuthContext" ascii wide
        $hdr = "x-limited-key-id" ascii nocase
        $path = "supabase/functions/_backend/utils/hono_middleware.ts" ascii

    condition:
        uint32(0) != 0x0a1a0a0d and
        (
            (1 of ($fn*)) or
            ($hdr and $path)
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-88862 Capgo x-limited-key-id Delegation Privilege Escalation Attempt"; flow:established,to_server; http.header; content:"x-limited-key-id"; nocase; http.uri; content:"/functions/"; nocase; threshold: type both, track by_src, count 5, seconds 60; classtype:attempted-admin; reference:cve,2026-88862; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-88862; sid:202688862; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [http where http.request.headers.values contains "x-limited-key-id"]
  [http where http.request.method in ("POST", "PUT", "PATCH", "DELETE") and
   http.response.status_code in (200, 201, 204)]

Splunk SPL Query

index=web sourcetype=access_combined
| eval hdr=lower(cs_headers)
| where like(hdr,"%x-limited-key-id%")
| rex field=cs_uri "^(?<endpoint>/functions/[^?]+)"
| stats count values(endpoint) as endpoints by src_ip, cs_method
| where count > 3
| sort - count

Wazuh OSSEC Rule

<group name="capgo,cve-2026-88862,">
  <rule id="100862" level="12">
    <decoded_as>json</decoded_as>
    <field name="request_headers.x-limited-key-id">\.+</field>
    <regex field="request_uri">/functions/</regex>
    <description>CVE-2026-88862: Capgo x-limited-key-id delegation header observed - possible API key privilege escalation</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>privilege_escalation,attempted_admin,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch is available from any tracked source, and no vendor fix or workaround is documented at the time of the advisory. The issue was reproduced on release 12.242.4 (commit b3d02cdbc23ac59990785acacd1f113c07458568), and Capgo had not published a fixed version. Operators must rely on compensating controls until a vendor patch is released.

1. Immediate mitigations

• Eliminate same-owner multi-privilege key arrangements. Where possible, ensure no single user account owns both a low-privilege apikey_manager key and a high-privilege sibling (e.g., app_admin). Because the flaw hinges on same-user_id sibling access, segregation across distinct owning users reduces but does not eliminate exposure.
• Audit and restrict API keys. Enumerate all API keys per user, identify any pair where a lower-privileged key shares an owner with a more privileged key, and remove or rotate the higher-privilege keys.
• Block or strip the x-limited-key-id header at the edge (reverse proxy / WAF) if the feature is not actively required, preventing attacker-controlled delegation.
• Monitor and alert on any request presenting x-limited-key-id (see Detection Guidance) and treat unexpected use as a security incident.

2. Patch / upgrade steps

• There is no patched version. Track Capgo advisories and the vendor repository for a fix and monitor the original advisory (related to GHSA-8h52-44r7-w343) for follow-up guidance. When a patched release is published, upgrade immediately and verify the parent-child delegation check is enforced in checkKeyByIdPg(), hasLimitedRbacSubkeyScope(), and validateSubkeyUser() before re-enabling any limited-key workflows.

3. Long-term hardening

• Treat API keys as identity principals and enforce strict parent-child delegation at every layer: a subkey must be verifiably bound to the delegating key, not merely to the same owner.
• Adopt least privilege so no single owner accumulates both low- and high-privilege keys.
• Add automated regression tests for delegation semantics so prior fixes (e.g., GHSA-8h52-44r7-w343) cannot silently regress.
• Instrument authorization decisions and alert on principal substitution events.

References

• NVD — CVE-2026-88862: https://nvd.nist.gov/vuln/detail/CVE-2026-88862
• Capgo (capgo.app) — vendor project / backend source and advisory channel
• Prior related advisory referenced in the description: GHSA-8h52-44r7-w343
• CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• CVSS v3.1 — Specification: https://www.first.org/cvss/v3.1/specification-document

No CISA KEV listing, public PoC, exploit code, or known in-the-wild campaign evidence is associated with CVE-2026-88862 at the time of this report.