CVE-2026-56303 in Capgoinfo

Summary

by MITRE • 07/11/2026

Capgo before 12.128.2 contains an information disclosure vulnerability in the find_apikey_by_value PostgreSQL function marked SECURITY DEFINER and executable by the anon role. Unauthenticated attackers can call this function via the /rest/v1/rpc/find_apikey_by_value endpoint to retrieve sensitive API key metadata including user_id, mode, org scoping, and expiration details when supplied a valid key value.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 07/11/2026

This vulnerability represents a critical information disclosure flaw in the Capgo application affecting versions prior to 12.128.2. The issue stems from improper database privilege management within the PostgreSQL function find_apikey_by_value which operates with SECURITY DEFINER characteristics and is accessible through the anon role. The function exposes sensitive metadata about API keys including user identifiers, operational modes, organizational scoping parameters, and expiration timestamps when provided with a valid key value. This represents a fundamental breakdown in the principle of least privilege and database access control mechanisms.

The technical implementation of this vulnerability allows unauthenticated attackers to exploit the /rest/v1/rpc/find_apikey_by_value endpoint without requiring any authentication credentials. The SECURITY DEFINER attribute in PostgreSQL creates a security risk when combined with roles that have broad access permissions, as it executes the function with the privileges of the owner rather than the caller. This design flaw enables attackers to bypass normal authentication mechanisms and directly query sensitive database information through exposed REST endpoints. The vulnerability specifically leverages the anon role's permissions which typically should represent anonymous users with minimal privileges but in this case has been granted access to privileged database functions.

From an operational perspective, this vulnerability presents a severe risk to system security as it allows attackers to gather comprehensive metadata about API keys without authentication. The exposed information includes user_id identifiers that can be used for further targeted attacks, mode information that reveals system configuration details, organizational scoping data that indicates access control boundaries, and expiration timestamps that help attackers plan timing for exploitation attempts. This metadata exposure can facilitate advanced persistent threats where attackers use the gathered intelligence to conduct more sophisticated attacks against specific users or organizations within the system.

The vulnerability aligns with CWE-284 (Improper Access Control) and CWE-312 (Sensitive Data Exposure) classifications, representing a clear violation of access control principles and sensitive data protection requirements. From an ATT&CK framework perspective, this vulnerability maps to T1566 (Phishing) and T1071.004 (Application Layer Protocol: DNS) through the exploitation of exposed API endpoints, and potentially T1580 (Taint Data) if the metadata can be used to further compromise the system. The risk assessment indicates this vulnerability should be treated as critical due to the lack of authentication requirements and the sensitive nature of the exposed data.

Mitigation strategies should focus on immediate privilege revocation for the anon role's access to the find_apikey_by_value function, implementation of proper authentication checks before allowing database queries, and restriction of SECURITY DEFINER functions to only privileged roles. Organizations should upgrade to Capgo version 12.128.2 or later where this vulnerability has been addressed through proper access control enforcement. Additional controls include implementing rate limiting on API endpoints, logging all function calls for monitoring purposes, and conducting comprehensive privilege audits to ensure no other similar vulnerabilities exist in the database schema. The fix should enforce that only authenticated users with appropriate permissions can invoke functions that return sensitive metadata, and all exposed REST endpoints should validate authentication status before processing requests.

Responsible

VulnCheck

Reservation

06/20/2026

Disclosure

07/11/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!