CVE-2026-56230
Deferred Deferred - Pending Action

Capgo Broken Object Level Authorization via x-limited-key-id Header

Vulnerability report for CVE-2026-56230, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.

Publication date: 2026-06-30

Last updated on: 2026-07-01

Assigner: VulnCheck

Description

Capgo before 12.128.2 contains a broken object level authorization vulnerability in middlewareKey() that accepts the client-controlled x-limited-key-id header without validating ownership, allowing authenticated users to adopt cross-tenant limited keys. Attackers can supply another tenant's limited key ID to bypass authorization checks and access unauthorized cross-tenant resources across multiple API endpoints.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-06-30
Last Modified
2026-07-01
Generated
2026-07-21
AI Q&A
2026-07-01
EPSS Evaluated
2026-07-19
NVD
EUVD

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
capgo capgo to 12.128.2 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-639 The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability exists in Capgo versions before 12.128.2 and involves broken object level authorization in the middlewareKey() function. The function accepts a client-controlled header called x-limited-key-id without verifying if the user owns that key. This flaw allows authenticated users to use limited keys belonging to other tenants, effectively bypassing authorization checks and gaining access to unauthorized resources across multiple API endpoints.

Detection Guidance

This vulnerability involves the misuse of the x-limited-key-id header to bypass authorization and access cross-tenant resources. Detection can focus on monitoring API requests that include the x-limited-key-id header with values that do not belong to the authenticated user.

You can detect potential exploitation by inspecting logs or capturing network traffic for API requests containing the x-limited-key-id header and verifying if the key ID corresponds to the authenticated tenant.

Example commands to detect suspicious usage might include:

  • Using grep on server logs to find requests with the x-limited-key-id header: grep -i 'x-limited-key-id' /path/to/api/logs
  • Using tcpdump or Wireshark to capture and filter HTTP headers containing x-limited-key-id: tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i 'x-limited-key-id'
  • Querying your backend or database logs for API calls where the limited key ID does not match the authenticated user's tenant ID.
Impact Analysis

The vulnerability can lead to unauthorized access to resources belonging to other tenants. Attackers who are authenticated can supply another tenant's limited key ID to bypass authorization controls, potentially exposing sensitive data or functionality that should be restricted. This can result in data breaches, loss of confidentiality, and unauthorized actions within the affected system.

Compliance Impact

The vulnerability allows authenticated users to bypass authorization checks and access unauthorized cross-tenant resources, potentially exposing sensitive data belonging to other tenants.

Such unauthorized access to sensitive data can lead to violations of data protection regulations and standards like GDPR and HIPAA, which require strict access controls and protection of personal and sensitive information.

Therefore, this broken object level authorization vulnerability could negatively impact compliance with these regulations by enabling unauthorized data disclosure.

Mitigation Strategies

The primary mitigation is to update Capgo to version 12.128.2 or later, where the vulnerability in middlewareKey() has been fixed by adding ownership validation for the x-limited-key-id header.

If immediate upgrade is not possible, implement additional access control checks to ensure that the limited key ID provided in the x-limited-key-id header belongs to the authenticated API key owner.

Additionally, scope subkey lookups at the query level to include user ID or tenant ID to prevent cross-tenant key resolution.

Monitor and audit API requests for suspicious use of the x-limited-key-id header to detect potential exploitation attempts.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-56230. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart