CVE-2026-100628 in Capgo.appinfo

Summary

by MITRE • 09/26/2026

capgo.app before 12.128.12 fails to enforce an organization's API key expiration policy when creating app-scoped API keys. In the POST /apikey endpoint, requests that supply app_id but omit org_id, limited_to_orgs, and expires_at resolve the target app and scope the key to it, but never add the app's owner organization to the list of organization IDs passed to validateExpirationAgainstOrgPolicies; because that list is empty, the validation returns early. As a result, an authenticated organization member can create a non-expiring app-scoped API key even when the owning organization has require_apikey_expiration enabled and a max_apikey_expiration_days limit configured. The issue is fixed in version 12.128.12.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 09/26/2026

The vulnerability identified in capgo.app prior to version 12.128.12 represents a critical logic flaw within the API key generation subsystem, specifically affecting how organization-level security policies are enforced for application-scoped credentials. This issue stems from an incomplete implementation of policy validation during the creation process via the POST /apikey endpoint. When an authenticated user submits a request to generate a new API key by providing only the app_id while omitting specific parameters such as org_id, limited_to_orgs, and expires_at, the system correctly resolves the target application and scopes the resulting key to that application context. However, the subsequent step responsible for validating expiration policies against organizational constraints fails due to an empty list of organization identifiers being passed to the validation function validateExpirationAgainstOrgPolicies. Because this list is devoid of data, the validation routine executes a premature return without performing any checks, effectively bypassing security controls designed to enforce key lifecycles.

From a technical perspective, this flaw allows for the creation of non-expiring API keys even when the owning organization has explicitly enabled the require_apikey_expiration setting and configured a max_apikey_expiration_days limit. The root cause lies in the failure to automatically associate the app owner's organization with the validation scope during key generation. In secure systems, application-scoped resources are inherently tied to their parent organizations for policy enforcement; here, that linkage is broken at the point of credential issuance. This oversight means that security policies defined at the organizational level do not propagate correctly to individual API keys generated under specific applications if certain optional fields are omitted from the request payload. The vulnerability essentially creates a configuration-dependent bypass where default behaviors override explicit security mandates set by administrators.

The operational impact of this vulnerability is significant, as it undermines the principle of least privilege and limits access control through time-based restrictions. Non-expiring API keys pose a severe risk because they remain valid indefinitely unless manually revoked or rotated. If such a key is compromised due to credential leakage, phishing attacks, or insider threats, attackers gain persistent unauthorized access to application resources without the natural expiration mechanism that typically mitigates long-term exposure. This persistence increases the window of opportunity for malicious actors to exfiltrate data, perform unauthorized actions, or pivot within the environment. For organizations relying on automated key rotation and strict lifecycle management as part of their compliance frameworks, this flaw renders those controls ineffective for application-scoped keys generated through the affected endpoint.

This vulnerability aligns with CWE-284 Improper Access Control, specifically regarding insufficient validation of access control policies during resource creation. It also relates to CWE-613 Insufficient Session Expiration, as it allows sessions or credentials that should have a defined lifespan to persist indefinitely. In terms of the MITRE ATT&CK framework, this flaw facilitates Initial Access and Persistence tactics by enabling attackers to establish long-lived footholds using stolen API keys that would otherwise expire automatically. The lack of proper enforcement means that even authenticated users can inadvertently or intentionally create high-value targets for credential stuffing or replay attacks due to the absence of expiration constraints.

To mitigate this risk, organizations must upgrade capgo.app to version 12.128.12 or later, where the logic has been corrected to ensure that the app owner's organization is always included in the validation scope regardless of which parameters are explicitly provided in the request. Until an update can be applied, administrators should implement compensating controls such as strict monitoring for API key creation events and regular audits of existing keys to identify any non-expiring credentials generated through this vector. Additionally, enforcing mandatory expiration dates at the application level or restricting the ability to generate app-scoped keys without explicit expiration parameters can help reduce exposure. Regular rotation of all active API keys remains a best practice regardless of software version, but fixing this specific logic error is essential for restoring trust in automated policy enforcement mechanisms.

Responsible

VulnCheck

Reservation

09/26/2026

Disclosure

09/26/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!