CVE-2026-56310: Cap-go API Key Authorization Bypass in Organization Members Endpoint

Technical summary

The GET /organization/members endpoint in Cap-go fails to properly validate the limited_to_orgs restriction on organization-scoped API keys. An attacker possessing a valid org-limited API key can submit requests to enumerate or retrieve member records from organizations outside their assigned scope. The authorization check does not sufficiently gate access before returning sensitive user attributes (uid, email, image_url, role, is_tmp). This is classified as an improper authorization flaw under CWE-285, requiring authenticated access but permitting unauthorized cross-organization data disclosure.

Business impact

For Cap-go customers relying on API key segmentation to enforce multi-tenant or team-based access controls, this vulnerability undermines a key security boundary. An insider, compromised service account, or supply-chain partner with a restricted API key could enumerate users across the entire platform, enabling reconnaissance for social engineering, targeted attacks, or competitive intelligence gathering. The risk is elevated in environments where API keys are shared across teams or contractors and treated as a primary access control mechanism.

Affected systems

All Cap-go installations running versions prior to 12.128.2 are affected. The vulnerability is present in the GET /organization/members endpoint and only impacts deployments that issue organization-limited API keys and rely on that restriction to enforce access boundaries. Customers on version 12.128.2 and later are not affected.

Exploitability

This vulnerability requires an attacker to possess a valid, org-limited API key—meaning it is not remotely exploitable without prior credential compromise or authorized access. The barrier to exploitation is therefore moderate; it assumes the attacker has already obtained legitimate credentials, either through credential theft, employee departure without key rotation, or intentional provisioning to an untrusted party. Once a key is in hand, exploitation is straightforward: repeated requests to the /organization/members endpoint with different organization identifiers will return unauthorized member data.

Remediation

Upgrade to Cap-go version 12.128.2 or later, which corrects the authorization logic on the /organization/members endpoint. Organizations should also audit API key usage during the interim period: identify which keys have been issued, to whom, and rotate any keys whose provenance or usage is uncertain. Review access logs for any unexpected cross-organization member queries prior to patching.

Patch guidance

Verify that your Cap-go instance is running version 12.128.2 or later by checking the deployment manifest or application version endpoint. The patch should be applied as part of a regular maintenance window, as it does not require runtime configuration changes or service restart beyond a standard upgrade process. Confirm the patch is in place before revoking or rotating API keys, to avoid operational disruption.

Detection guidance

Monitor API audit logs for GET /organization/members requests originating from org-limited API keys that target organization identifiers outside the key's assigned scope. Detection rules should flag any single key making queries to multiple distinct organization IDs within a short time window. Additionally, review for unusual or repetitive member enumeration patterns, which may indicate reconnaissance. Organizations without detailed API logging should prioritize enabling request-level audit trails before relying on API key segmentation for security.

Why prioritize this

While the CVSS score is MEDIUM (4.3), prioritization should account for the access control context. If your organization uses Cap-go API keys as a trust boundary for service-to-service communication or multi-tenant deployments, this vulnerability directly undermines that model and should be treated as higher priority. For organizations that treat API keys as fully privileged credentials or use them only for non-sensitive operations, the risk is lower. Assess based on your actual API key distribution and reliance on org-limited scope enforcement.

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) reflects a network-accessible vulnerability requiring prior authentication (PR:L), with low attack complexity, no user interaction, and confidentiality impact limited to member metadata (not passwords or cryptographic material). The score does not account for compensating controls—such as environment-based isolation, key rotation discipline, or lack of trusted API key holders—which may reduce real-world risk. The score also does not elevate for business context; if API key segmentation is mission-critical to your access model, consider this a higher-priority patch than the CVSS alone suggests.

Frequently asked questions