Capgo App EUVD-2026-87722

Requires an authenticated account that is a member of a Capgo organization which has explicitly enabled require_apikey_expiration and set a max_apikey_expiration_days limit (the policy this flaw defeats). The attacker must call POST /apikey supplying app_id while deliberately omitting org_id, limited_to_orgs, and expires_at - this specific parameter combination causes the owner org to be excluded from validateExpirationAgainstOrgPolicies. Limiting factors: the actor must already hold valid org credentials with permission to create app-scoped keys (PR:L), the target org must actually have the expiration policy configured (otherwise there is nothing to bypass), and the resulting key grants no privileges beyond what the member could already scope - the only gain is indefinite key lifetime. Fixed in version 12.128.12.

This is CWE-863 (improper authorization) mislabeled as 'Authentication Bypass' - no authentication is defeated. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a low-privileged authenticated org member is the attacker, so this is NOT remote-unauthenticated. The vendor's 8.7 CRITICAL rating rests on VC:H/VI:H/VA:H, which is generous and internally inconsistent with the actual flaw: the bug does NOT grant any new access. The created key is app-scoped to exactly what the member could already scope it to; the only thing bypassed is the organization's expiration policy, so the marginal impact is a credential that lives longer than the org intended, extending the exposure window if it later leaks. Real technical impact is therefore Low (C:L/I:L), not High. No EPSS score, no CISA KEV listing, and no public POC are present in the input - meaning no evidence of active exploitation or automatable mass abuse. Weighing all signals: this is a governance/policy-control weakness with low real-world urgency, not the CRITICAL the raw score implies. Note the discrepancy explicitly: vendor VC:H/VI:H/VA:H overstates impact versus a description that only shows an expiration-policy bypass by an already-authorized member.

An authenticated member of an organization that has enforced API-key expiration (require_apikey_expiration with a max_apikey_expiration_days limit) calls POST /apikey supplying only app_id and omitting org_id, limited_to_orgs, and expires_at. The validateExpirationAgainstOrgPolicies check receives an empty org-ID list and returns early, so the server issues a permanent, non-expiring app-scoped key that outlives the organization's rotation policy. No public exploit code is identified at time of analysis; exploitation requires an existing valid org account.