Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-26T14:16:43.977Z",
  "pubdate": "2026-09-26T14:16:43.977Z",
  "executiveSummary": "The vulnerability in capgo.app constitutes an improper authorization and policy enforcement failure within the API key management system. Specifically, it allows authenticated organization members to bypass mandatory API key expiration policies enforced at the organizational level.\nBy manipulating the parameters of the POST /apikey endpoint, an attacker can generate app-scoped API keys that lack an expiration date, even if the parent organization has explicitly configured 'require_apikey_expiration' and defined a 'max_apikey_expiration_days' constraint.\nThis flaw effectively negates security controls intended to limit the lifespan of programmatic access credentials, potentially resulting in long-term unauthorized access if a key is compromised. The vulnerability affects versions of capgo.app prior to 12.128.12. Successful exploitation requires valid authentication as an organization member, but does not require administrative privileges, representing a significant risk to organizations relying on automated key rotation or expiration policies to maintain a reduced attack surface.",
  "technicalDetails": "The root cause of this vulnerability lies in an incomplete validation logic within the POST /apikey endpoint of the capgo.app application. The system's security architecture relies on the validateExpirationAgainstOrgPolicies function to enforce organization-wide security configurations, such as mandatory expiration dates for API keys.\nWhen an API key is generated, the endpoint logic is designed to pass a list of relevant organization IDs to this validation function. However, the implementation fails to correctly identify and include the owning organization's ID when a request supplies an app_id but intentionally omits the org_id, limited_to_orgs, and expires_at parameters.\nThe attack flow proceeds as follows: An authenticated organization member initiates a POST request to the /apikey endpoint. By providing only the app_id, the request is correctly mapped to the target application. Because the org_id and related fields are omitted, the application logic fails to retrieve or resolve the owner organization ID associated with that app. Consequently, the list of organizations passed to the validateExpirationAgainstOrgPolicies function remains empty.\nThe validation function contains a short-circuit condition: if the provided list of organization IDs is empty, the function returns immediately without performing any checks or applying constraints. As a result, the backend proceeds to create the API key without enforcing the organization's require_apikey_expiration policy or the max_apikey_expiration_days limit. The generated key is subsequently created as a non-expiring credential.\nThis creates a scenario where an organization member can intentionally bypass security controls designed to mitigate the impact of credential leakage. Because the key is scoped to the application but lacks an expiration, the post-exploitation impact includes the potential for persistent, indefinite access to application resources, bypassing organizational lifecycle management for security tokens. This issue is resolved in version 12.128.12, which presumably ensures that the owning organization of the targeted application is correctly resolved and passed to the validation routine, regardless of the optional fields present in the request payload."
}