MEDIUM 6.5

CVE-2026-56251: Capgo Privilege Escalation via Broken Row-Level Security

Capgo versions prior to 12.128.2 contain a flaw in their access control system that lets already-authenticated administrators escalate themselves to a super_admin role without proper authorization. The vulnerability stems from broken row-level security (RLS) policies on the org_users table, meaning the database isn't correctly restricting which rows a user can modify. An attacker with admin credentials can exploit this to gain super_admin privileges, effectively taking full control of the system.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H
Weaknesses (CWE)
CWE-266
Affected products
0 configuration(s)
Published / Modified
2026-06-21 / 2026-06-22

NVD description (verbatim)

Capgo before 12.128.2 contains a broken row level security policy in the org_users table that allows authenticated users to elevate privileges from admin to super_admin. Attackers can exploit the insufficient RLS enforcement to gain unauthorized super_admin access and compromise system security.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-56251 is a privilege escalation vulnerability in Capgo affecting versions before 12.128.2. The org_users table implements insufficient row-level security policies, failing to enforce proper row-level access controls that should prevent authenticated users from modifying rows outside their authorization scope. An authenticated admin user can bypass these broken RLS checks to update their own role from admin to super_admin, achieving unauthorized privilege escalation. The vulnerability is classified under CWE-266 (Incorrect Privilege Assignment) and carries a CVSS 3.1 score of 6.5 (Medium), indicating high integrity and availability impact but requiring high privileges and network access to exploit.

Business impact

A compromised admin account can be leveraged to escalate to super_admin status, granting an attacker full administrative control over the Capgo deployment. This enables unauthorized access to sensitive data, modification of system configurations, creation or deletion of accounts, and potential lateral movement within connected systems. Organizations relying on role-based access controls to segregate duties and enforce least-privilege principles will find those controls circumvented, increasing the risk of insider threats, data exfiltration, and system tampering.

Affected systems

Capgo versions before 12.128.2 are affected. The vulnerability is specific to the org_users table's RLS implementation and impacts any Capgo deployment where admin users require isolation from super_admin roles. No information on patch availability for versions prior to 12.128.2 is provided in the advisory; verify your version against the Capgo release notes.

Exploitability

Exploitation requires an authenticated admin account—the attacker does not need physical access or user interaction. The attack is straightforward: modify the role field in the org_users table to escalate privileges. The CVSS vector (AC:L, PR:H, UI:N) indicates low attack complexity once admin access is obtained. However, the requirement for high privileges (existing admin credentials) means this is primarily a post-compromise privilege escalation path rather than a unauthenticated attack. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Remediation

Upgrade Capgo to version 12.128.2 or later, which includes corrected row-level security policies for the org_users table. If immediate patching is not possible, restrict admin account usage to trusted personnel, enforce strong credential hygiene, and monitor org_users table modifications for unauthorized role changes. Review audit logs for any suspicious privilege escalation activity in affected environments.

Patch guidance

Apply Capgo update 12.128.2 or later as soon as feasible. This patch restores proper RLS enforcement on the org_users table. Coordinate the upgrade during a maintenance window to minimize service disruption. After patching, validate that role assignments in the org_users table are correct and that admin users cannot unilaterally escalate themselves to super_admin status. Test the RLS policy in a non-production environment first to confirm the fix does not introduce regressions.

Detection guidance

Monitor the org_users table for unexpected changes to the role column, particularly admin-to-super_admin transitions initiated by admin accounts. Review database audit logs and access logs for modification patterns that deviate from normal administrative workflows. Track failed and successful authentication attempts by admin accounts, and correlate them with privilege escalation events. Use database activity monitoring (DAM) tools to flag unauthorized row modifications or policy bypasses. If available, test your RLS policies directly in a lab environment to confirm they prevent unauthorized escalation.

Why prioritize this

While this vulnerability requires pre-existing admin access and is not actively exploited in the wild (no KEV listing), it represents a critical post-compromise escalation risk. In multi-tenant or multi-user Capgo deployments where admin and super_admin roles are supposed to be segregated, a compromised or malicious admin account becomes a complete system takeover vector. Medium CVSS score reflects the privilege requirement, but the ease of exploitation once that threshold is crossed, combined with the severity of the impact (full system compromise), justifies urgent patching. Organizations with admin accounts held by third-party contractors or service providers should treat this as higher priority.

Risk score, explained

The CVSS 3.1 score of 6.5 (Medium) factors in high-privilege requirement (PR:H) and no user interaction (UI:N), but registers high integrity and availability impact (I:H, A:H). The score appropriately reflects that while admin credentials are needed, the jump to super_admin is trivial once that bar is cleared. The Medium rating should not be misinterpreted as low urgency; in privileged environments, this is a critical gap in access control. Organizations should weight this against their own risk tolerance, the sensitivity of data managed by Capgo, and the trust model of their admin user base.

Frequently asked questions

Do I need super_admin privileges to be exploited by this vulnerability?

No. You need admin privileges to exploit it. An attacker with admin credentials can escalate themselves to super_admin without requiring super_admin access initially. This is the core of the privilege escalation.

Is this vulnerability being actively exploited?

No, it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog as of the advisory publication date. However, the simplicity of exploitation means defenders should not rely on low exploitation activity as justification for delaying the patch.

What is row-level security and why does it matter here?

Row-level security (RLS) is a database feature that restricts which rows a user can query or modify based on security policies. In Capgo's org_users table, RLS should prevent an admin from modifying their own role field or escalating to super_admin. When RLS is broken, these restrictions are bypassed, and privilege escalation becomes possible.

Can I work around this vulnerability without patching?

Temporary mitigations include strictly limiting who holds admin credentials, enforcing strong access controls and monitoring, and auditing org_users table modifications. However, these do not fix the underlying RLS policy flaw and should be considered temporary. Patching to 12.128.2 or later is the only permanent fix.

This analysis is provided for informational purposes to help security professionals understand and remediate CVE-2026-56251. SEC.co makes no warranty as to the accuracy, completeness, or timeliness of this information. Patch version numbers, affected product versions, and remediation details are based on the vendor advisory and should be verified against official Capgo documentation before deployment. Organizations are responsible for assessing their own risk and implementing appropriate security controls. Always test patches in a non-production environment before production rollout. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).