CVE-2026-100628

Executive Summary

CVE-2026-100628 is an authorization policy bypass in capgo.app versions prior to 12.128.12, affecting the API key creation flow. An authenticated organization member can create a non-expiring, app-scoped API key even when the owning organization has enforced API key expiration policies (require_apikey_expiration and max_apikey_expiration_days). The vulnerability is a CWE-863 incorrect authorization flaw with a CVSS v3.1 base score of 4.3, reflecting low confidentiality impact but a meaningful integrity impact on the organization's security policy enforcement.

Technical Analysis

The vulnerability resides in the API key creation logic exposed via the POST /apikey endpoint of capgo.app. Capgo is a platform for managing live updates and over-the-air (OTA) distribution for mobile and web applications. Organizations on the platform can enforce API key expiration policies via two configuration flags referenced in the NVD description: require_apikey_expiration and max_apikey_expiration_days. When these are enabled, any API key created within the organization is expected to carry an expires_at value that respects the configured maximum lifetime.

The flaw is triggered by a specific combination of request parameters. When a caller submits a request to POST /apikey that supplies app_id but omits org_id, limited_to_orgs, and expires_at, the server correctly resolves the target application and scopes the new key to that application. However, in this code path the application's owner organization is never added to the list of organization IDs passed to the validateExpirationAgainstOrgPolicies function. Because that organization list is empty, the validation routine returns early without performing any expiration checks.

The result is a logic flaw rather than an injection or memory-safety issue: the enforcement function exists and is presumably correct, but it is invoked with an empty input set, causing a short-circuit return. The organization's require_apikey_expiration setting and max_apikey_expiration_days limit are therefore silently ignored for this specific request shape. An authenticated member of the organization—someone who already holds PR:L (low privileges)—can exploit the parameter-omission pattern to mint a permanent, app-scoped credential.

The attack surface is the REST API layer, specifically the API-key management endpoint. Because the endpoint is authenticated, the vulnerability is not remotely exploitable by unauthenticated attackers; it requires a valid account with membership in the target organization. No experimental proof-of-concept, exploit code, or Nuclei template is currently associated with this CVE, and the CVE has not been added to the CISA KEV catalog. The flaw is fixed in version 12.128.12.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-863: Incorrect Authorization) and the behavior described in the NVD entry.

1. Reconnaissance / target identification. The attacker obtains or already possesses a valid, low-privileged account that is a member of a target organization on a capgo.app deployment. The attacker identifies an application owned by that organization (for example, via normal application listing functionality available to members) and confirms that the organization has expiration policies enabled—observable through the fact that other key-creation flows require an expires_at value.

2. Triggering the specific flaw class. The attacker sends an authenticated POST /apikey request that includes the app_id parameter targeting the victim application, while deliberately omitting org_id, limited_to_orgs, and expires_at. This parameter-omission pattern is the exact trigger: because the owner organization is never added to the list of organization IDs handed to validateExpirationAgainstOrgPolicies, that list is empty and the function returns early without evaluating require_apikey_expiration or max_apikey_expiration_days.

3. Payload / execution method. The request is a standard JSON API call carrying no malicious payload in the classic sense—the "exploit" is the absence of parameters that would normally cause policy enforcement to run. The server resolves the app, scopes the new key to it, and returns a credential that has no expires_at value despite the organization's policy requiring one.

4. Post-exploitation impact. The attacker now holds a non-expiring, app-scoped API key. This credential persists indefinitely, bypassing the organization's intended credential-rotation and lifetime controls. It can be used for any action the key's scope permits against the target application. The integrity impact is low per the CVSS vector (I:L), because the attacker can subvert the organization's key-expiration security control; confidentiality and availability impacts are rated None (C:N, A:N). The primary risk is persistence: a credential that survives policy-driven rotation and remains valid long after the organization believes it should have expired.

Impact Assessment

The CVSS v3.1 base score is 4.3 (Medium), with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N. Breaking this down: the attack is network-reachable (AV:N), requires no special conditions (AC:L), needs only low privileges in the form of a valid organization membership (PR:L), and requires no user interaction (UI:N). The scope is unchanged (S:U). Confidentiality and availability impacts are None; integrity impact is Low, reflecting that the organization's API key lifetime policy is bypassed.

Business impact centers on weakened credential governance. Organizations that rely on mandatory key expiration as a compensating control for lost, leaked, or orphaned credentials will find those controls circumvented. In multi-tenant or regulated environments, this may translate into audit/compliance findings where credential rotation policies are contractually or regulatorily mandated.

Blast radius is bounded to the affected organization's applications: the created key is app-scoped, so its direct reach is limited to the targeted application rather than the whole organization. However, an indefinitely valid key expands the window during which a compromised credential can be abused.

Affected systems are capgo.app deployments running versions below 12.128.12 where organization-level API key expiration policies are enabled. The exposure requires an attacker to already hold a valid organization member account, which materially limits the population of potential attackers (insiders, compromised low-privilege accounts, or malicious contractors) but does not eliminate risk.

Detection Guidance

Sigma Rule

title: Capgo API Key Creation Bypassing Organization Expiration Policy
id: 8f2a1c74-3b6e-4d19-9a57-capgo100628
status: experimental
description: Detects POST requests to the Capgo /apikey endpoint that create an app-scoped key without an expires_at value, matching the CVE-2026-100628 policy-bypass pattern.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-100628
author: valtersit.com
date: 2026/01/01
logsource:
  category: web
  product: capgo
detection:
  selection:
    http.method: 'POST'
    url.path|endswith: '/apikey'
    http.request.body|contains: 'app_id'
  filter_expiration:
    http.request.body|contains: 'expires_at'
  filter_org:
    http.request.body|contains: 'org_id'
  condition: selection and not filter_expiration and not filter_org
falsepositives:
  - Legitimate administrative tooling that explicitly manages non-expiring keys outside the org policy scope.
level: medium
tags:
  - attack.t1078
  - cve.2026-100628

YARA Rule

rule CVE_2026_100628_Capgo_Apikey_Expiration_Bypass
{
    meta:
        description = "Detects Capgo /apikey request bodies that omit expires_at, org_id and limited_to_orgs while supplying app_id (CVE-2026-100628)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100628"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $app = "\"app_id\"" ascii nocase
        $org = "\"org_id\"" ascii nocase
        $lim = "\"limited_to_orgs\"" ascii nocase
        $exp = "\"expires_at\"" ascii nocase
        $ep = "/apikey" ascii nocase

    condition:
        $ep and $app and not $org and not $lim and not $exp
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-100628 Capgo API Key Expiration Policy Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/apikey"; http.request_body; content:"app_id"; http.request_body; content:!"expires_at"; http.request_body; content:!"org_id"; http.request_body; content:!"limited_to_orgs"; classtype:attempted-user; sid:2026100628; rev:1; reference:cve,2026-100628; metadata:created_at 2026_01_01;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ network where http.request.method == "POST" and url.path == "/apikey" and http.request.body contains "app_id" ]
  [ network where http.request.method == "POST" and url.path == "/apikey" and not http.request.body contains "expires_at" and not http.request.body contains "org_id" ]

Splunk SPL Query

index=web sourcetype=capgo_access
| where method="POST" AND match(uri, "/apikey$")
| eval has_app = if(like(request_body, "%app_id%"), 1, 0)
| eval has_exp = if(like(request_body, "%expires_at%"), 1, 0)
| eval has_org = if(like(request_body, "%org_id%"), 1, 0)
| eval has_lim = if(like(request_body, "%limited_to_orgs%"), 1, 0)
| where has_app=1 AND has_exp=0 AND has_org=0 AND has_lim=0
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, user, uri
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="capgo,web,api">
  <rule id="100628" level="8">
    <decoded_as>json</decoded_as>
    <field name="http.method">POST</field>
    <field name="url.path">/apikey</field>
    <match>app_id</match>
    <description>CVE-2026-100628 - Possible Capgo API key creation bypassing organization expiration policy (app_id supplied without expires_at/org_id/limited_to_orgs).</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_100628,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description states the issue is fixed in version 12.128.12, but no vendor advisory, commit reference, or tracked patch source has been confirmed; treat all deployments below 12.128.12 as vulnerable until vendor confirmation is obtained.

1. Immediate mitigations.

   • Where feasible, restrict the ability to create API keys to a small set of trusted administrators, reducing the population of low-privilege members who could trigger the flaw.
   • Audit existing app-scoped API keys for keys lacking an expires_at value despite the organization policy requiring expiration; revoke or rotate any that should have expired under max_apikey_expiration_days.
   • Monitor logs for the parameter-omission pattern described in the Detection Guidance section.
   • Enforce compensating controls: manual key rotation schedules, short-lived service tokens issued out-of-band, and least-privilege scoping so any non-expiring key has minimal reach.

2. Patch/upgrade steps.

   • Upgrade capgo.app to version 12.128.12 or later once the vendor release is verified.
   • Following upgrade, re-test the POST /apikey flow with and without org_id, limited_to_orgs, and expires_at to confirm that validateExpirationAgainstOrgPolicies now receives the owner organization and enforces require_apikey_expiration and max_apikey_expiration_days.
   • Rotate all API keys created or suspected of being created before remediation.

3. Long-term hardening.

   • Fail closed: validation routines should treat an empty organization list as a denial condition rather than a reason to return early.
   • Add regression tests that assert expiration policy enforcement across every parameter permutation of the API key creation endpoint.
   • Apply defense-in-depth by enforcing maximum key lifetime at the database/persistence layer in addition to the application validation layer.
   • Continuously inventory and monitor API keys for missing or anomalous expiration metadata.

References

• NVD — CVE-2026-100628: https://nvd.nist.gov/vuln/detail/CVE-2026-100628
• CWE-863: Incorrect Authorization — https://cwe.mitre.org/data/definitions/863.html
• Capgo project and API key management documentation — https://capgo.app
• FIRST EPSS (currently not scored for this CVE) — https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (this CVE is NOT listed as of the latest published catalog) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No threat actor campaigns, exploit-in-the-wild evidence, public PoC, or Nuclei template have been observed for CVE-2026-100628 at the time of writing. The flaw requires authenticated organization membership, which limits mass-exploitation potential.