CVE-2026-100611

Executive Summary

CVE-2026-100611 is a privilege escalation vulnerability in the Capgo backend (capgo.app, versions ≤ 12.261.0) caused by improper privilege management (CWE-269). An authenticated user holding only the apikey_manager organization role can create API keys bound to higher-privileged deploy roles (app_developer, app_uploader, channel_developer, channel_uploader), even though that user does not hold those permissions. This allows a low-privileged operator who cannot upload bundles or promote channels to mint a deploy-capable API key and push arbitrary Over-The-Air (OTA) JavaScript updates to all end users of the organization's apps, directly compromising application integrity across the entire user base. No patched version is available.

Technical Analysis

Capgo is an OTA update delivery platform for mobile/web apps. Its backend exposes a REST API that manages organizations, users, roles, and API keys. The vulnerability resides in the role-binding authorization logic used when a new API key is created.

Per the NVD description, an authenticated session is not required to be highly privileged — the caller need only hold the apikey_manager organization role, which confers two permissions: org.manage_apikeys and org.read. When such a user invokes POST /apikey with a JWT session, the backend applies three checks, all of which are insufficient:

1. Permission check — the caller must possess org.manage_apikeys. This is satisfied by apikey_manager by design.
2. Deny-list check — the assignable role name is compared against a fixed deny-list, APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES, defined in public/apikey/scope.ts. Critically, this list omits the deploy roles app_developer, app_uploader, channel_developer, and channel_uploader.
3. Priority-rank comparison in createRoleBindingForPrincipal (private/role_bindings.ts). Each role carries a priority_rank. The apikey_manager role is seeded with priority_rank 78, whereas the deploy roles have ranks of 68 (app_developer), 66 (app_uploader), 58 (channel_developer), and 57 (channel_uploader). Because 78 is higher than all four, the rank comparison passes for each of the omitted deploy roles.

The fundamental defect is the absence of a fourth check: the system never verifies that the caller actually holds the permissions conferred by the role being assigned. Authorization is therefore inferred from a static deny-list and a numeric rank, not from the caller's effective permission set — a classic improper privilege management flaw. The result is that a role intended only to manage API key lifecycles can escalate itself, via API key creation, to deploy authority.

The vulnerability is remotely exploitable over the network with low attack complexity and low privileges (authenticated apikey_manager), requiring no user interaction. CVSS 3.1 scores it 6.5 (Medium) with Integrity impact High and Confidentiality impact None.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template is available. The attack chain below is inferred strictly from the vulnerability class and the technical details in the NVD description. No specific implementation artifacts beyond those named in the description are asserted.

1. Reconnaissance / target identification. The attacker identifies a Capgo deployment (capgo.app backend) and obtains a low-privileged account within an organization — specifically an account assigned the apikey_manager role. This role is legitimately provisioned to operators who manage API keys but are deliberately excluded from bundle/channel deployment. The attacker confirms the backend version is ≤ 12.261.0.

2. Triggering the specific flaw class. Authenticated with a JWT session carrying only apikey_manager, the attacker issues POST /apikey and specifies an assignable role of one of the omitted deploy roles (e.g., app_developer). The three existing checks are bypassed as described: org.manage_apikeys is present, the role name is absent from APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES, and the rank comparison in createRoleBindingForPrincipal passes because apikey_manager (78) outranks the target deploy role. No check confirms the caller holds the target role's permissions.

3. Execution method (vulnerability-class level). The API call succeeds, and the backend creates an API key bound to a deploy role. The attacker now possesses a credential that carries deployment authority they were never granted. This is privilege escalation via improper authorization on a credential-creation endpoint.

4. Post-exploitation impact. Using the newly minted deploy-capable API key, the attacker can push arbitrary OTA JavaScript updates. Because the key is inside the victim organization, updates propagate to all end users of the organization's apps. This yields code injection into every client app in the tenant — a full application-integrity compromise that does not require any further privilege escalation.

Impact Assessment

• Confidentiality: None (C:N) — the flaw is not described as exposing data.
• Integrity: High (I:H) — the attacker can inject arbitrary OTA JavaScript into all end users of the organization's apps, altering application behavior at scale.
• Availability: None (A:N) per the vector.
• Privileges Required: Low (PR:L) — only an authenticated apikey_manager is needed.
• User Interaction: None (UI:N) — the malicious update reaches end users without any action by them beyond normal app operation.
• Scope: Unchanged (S:U) — impact remains within the Capgo organization's authorization boundary.

Business impact is severe for affected organizations: a single low-privileged operator can silently hijack the OTA update channel, delivering malicious JavaScript to the entire user base. This is functionally a supply-chain-style compromise of the organization's mobile/web app distribution. Detection is difficult because the updates originate from a legitimate API key and the legitimate update infrastructure. Affected systems are any Capgo backend at version ≤ 12.261.0 that has provisioned apikey_manager accounts. The blast radius is all apps and end users within the compromised organization.

Detection Guidance

Sigma Rule

title: Capgo apikey_manager Privilege Escalation via POST /apikey Deploy Role Binding
id: 6b7c1e2a-capgo-privesc-001
status: experimental
description: Detects creation of an API key bound to a deploy role by a caller holding only apikey_manager, exploiting CVE-2026-100611 in Capgo <= 12.261.0.
logsource:
  product: capgo
  service: apikey
detection:
  selection_endpoint:
    http.method: 'POST'
    http.path: '/apikey'
  selection_role:
    assignable_role|contains:
      - 'app_developer'
      - 'app_uploader'
      - 'channel_developer'
      - 'channel_uploader'
  selection_caller:
    actor_role: 'apikey_manager'
  condition: selection_endpoint and selection_role and selection_caller
fields:
  - actor_id
  - actor_role
  - assignable_role
  - api_key_id
falsepositives:
  - Legitimate administrators whose role set appears as apikey_manager in truncated logs
level: high
tags:
  - attack.t1078.004
  - attack.privilege_escalation
  - cve.2026-100611

YARA Rule

rule CVE_2026_100611_Capgo_Role_Escalation_Artifacts
{
    meta:
        author = "valtersit.com Threat Intel"
        description = "Detects Capgo role-binding source artifacts referencing the vulnerable deny-list and rank logic (CVE-2026-100611)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100611"
        date = "2026-01-01"
        severity = "high"
    strings:
        $deny = "APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES" ascii
        $scope = "public/apikey/scope.ts" ascii
        $bind = "createRoleBindingForPrincipal" ascii
        $rbind = "private/role_bindings.ts" ascii
        $r1 = "app_developer" ascii
        $r2 = "app_uploader" ascii
        $r3 = "channel_developer" ascii
        $r4 = "channel_uploader" ascii
    condition:
        (uint16(0) == 0x0a0a or true) and
        ( ($deny and $scope) or ($bind and $rbind) ) and
        any of ($r*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-100611 Capgo API Key Creation Bound to Deploy Role by apikey_manager"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/apikey"; http.request_body; content:"assignable"; nocase; http.request_body; content:"app_developer"|20|"app_uploader"|20|"channel_developer"|20|"channel_uploader"; nocase; classtype:attempted-privilege-escalation; sid:2026100611; rev:1; metadata:affected_product Capgo, cve CVE-2026-100611;)

Elastic Detection

sequence by user.id with maxspan=1m
  [http where http.request.method == "POST" and url.path == "/apikey"]
  [authentication where event.action == "api_key_created" and
     capgo.api_key.assignable_role in ("app_developer","app_uploader","channel_developer","channel_uploader") and
     capgo.actor.role == "apikey_manager"]

Splunk SPL Query

index=capgo sourcetype=capgo:apikey
| search http_method="POST" uri_path="/apikey"
| eval risky_role=if(match(assignable_role,"^(app_developer|app_uploader|channel_developer|channel_uploader)$"),1,0)
| where risky_role=1 AND actor_role="apikey_manager"
| table _time actor_id actor_role assignable_role api_key_id src_ip
| sort - _time

Wazuh OSSEC Rule

<group name="capgo,cve-2026-100611,">
  <rule id="100611" level="12">
    <decoded_as>json</decoded_as>
    <field name="http_method">POST</field>
    <field name="uri_path">/apikey</field>
    <field name="actor_role">apikey_manager</field>
    <regex field="assignable_role">^(app_developer|app_uploader|channel_developer|channel_uploader)$</regex>
    <description>CVE-2026-100611: Capgo apikey_manager created API key bound to privileged deploy role - possible privilege escalation</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1) Immediate mitigations

• Restrict and audit all accounts holding the apikey_manager role; treat it as a privileged role until fixed.
• Add deploy roles (app_developer, app_uploader, channel_developer, channel_uploader) to the deny-list APIKEY_MANAGER_DENIED_ASSIGNABLE_ROLES in public/apikey/scope.ts as a compensating control.
• Enforce a server-side check that the caller holds the permissions of any role being assigned, and reject POST /apikey requests that bind a role exceeding the caller's effective permissions.
• Place the POST /apikey endpoint behind additional monitoring/approval, and reduce apikey_manager priority_rank below all deploy-role ranks.

2) Patch/upgrade steps

• No patched version was available as of advisory publication. Monitor the Capgo project for a fixed release of the capgo.app backend beyond 12.261.0 and upgrade immediately when published.
• Validate any future fix by confirming that role assignment verifies the caller's effective permissions, and that deploy roles are included in the deny-list.

3) Long-term hardening

• Replace static deny-list + rank-based authorization with attribute/permission-based checks that compare the requested role's granted permissions against the caller's actual permission set (deny-by-default).
• Apply least privilege to seeded roles so that lifecycle-management roles never outrank deployment roles.
• Log and alert on all API key creation events, especially those binding elevated roles, and periodically reconcile API keys against the roles that created them.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-100611
• Capgo project / capgo.app backend advisory (vendor) — versions ≤ 12.261.0, no patched version available as of publication
• CWE-269: Improper Privilege Management — https://cwe.mitre.org/data/definitions/269.html
• MITRE ATT&CK T1078.004 (Valid Accounts: Cloud Accounts) — https://attack.mitre.org/techniques/T1078/004/
• CISA Known Exploited Vulnerabilities catalog — CVE-2026-100611 is NOT listed; no known exploit-in-the-wild evidence, no public PoC, no Nuclei template at time of writing.