CVE-2026-88861 in capgo.app
Summary
by MITRE • 09/10/2026
Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions (no patched version available at time of publication). The Edge authorization path allows a password-only Supabase aal1 session to exercise privileged RBAC permissions even when the account has a verified MFA factor that has not been used for the session: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts the JWT without validating its assurance level, and the direct RBAC path (checkPermission()/checkPermissionPg() in supabase/functions/_backend/utils/rbac.ts calling public.rbac_check_permission_direct()) authorizes by user ID without passing or checking the session aal, unlike the public.verify_mfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped app_admin API key that remains valid after the aal1 session is logged out, and perform privileged operations such as modifying production OTA channel configurations (validated by changing a public production channel from bundle 1.0.0 to 1.0.1), defeating the protection provided by MFA.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Capgo represents a critical authentication bypass within its Edge authorization infrastructure, specifically targeting the interaction between session assurance levels and role-based access control mechanisms. This flaw affects all versions of the software with no patched release available at the time of publication, leaving users exposed to unauthorized privilege escalation. The core technical deficiency lies in how the system validates JSON Web Tokens (JWTs) during request processing. Specifically, the Edge JWT middleware function foundJwt() fails to validate the assurance level associated with a Supabase session. In standard security architectures utilizing multi-factor authentication, sessions are categorized by their Assurance Level, typically designated as AAL1 for password-only authentication and AAL2 for verified multi-factor authentication. The vulnerability arises because the middleware accepts an AAL1 JWT without verifying that it meets the higher assurance requirements necessary for privileged operations, effectively treating a less secure session with the same trust level as a fully secured one.
This architectural oversight directly impacts the Role-Based Access Control (RBAC) evaluation process. When checking permissions via functions such as checkPermission() or checkPermissionPg(), which invoke public.rbac_check_permission_direct(), the authorization logic relies exclusively on the user ID to grant access. It does not pass or verify the session's assurance level, unlike other parts of the system like public.verify_mfa(), which correctly enforces AAL2 requirements for sensitive actions. Consequently, an attacker who possesses only a victim’s password can authenticate as that user and exercise privileged RBAC permissions despite having bypassed multi-factor authentication controls. This discrepancy creates a significant gap where security policies intended to protect high-privilege functions are circumvented by exploiting the lack of session context validation in specific code paths.
The operational impact of this vulnerability is severe, allowing an attacker with basic credentials to perform actions that should require verified identity confirmation. A primary example of exploitation involves minting persistent app-scoped API keys with admin privileges. These keys remain valid even after the initial low-assurance session is logged out, providing long-term access to compromised systems. Furthermore, attackers can modify production Over-The-Air (OTA) channel configurations, such as changing a public production channel from bundle version 1.0.0 to 1.0.1. This capability enables potential code injection or service disruption in live environments, undermining the integrity and availability of applications relying on Capgo for updates. The defeat of MFA protections means that organizations cannot rely on multi-factor authentication as an effective control against credential-based attacks targeting this specific functionality.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, specifically regarding the failure to properly verify assurance levels during authorization decisions. It also relates to CWE-862 Missing Authorization Check, as the system fails to enforce required security policies for privileged actions based on session context. In terms of offensive tactics, this exploit maps to MITRE ATT&CK technique T1078 Valid Accounts, where attackers use legitimate credentials to gain access, and potentially T1556 Multi-Factor Authentication Bypass if viewed as a failure in enforcing MFA requirements for specific high-value actions. Mitigation strategies are currently limited due to the absence of a vendor patch. Organizations should implement compensating controls such as strict network segmentation to limit exposure of Capgo endpoints, enforce additional application-layer security checks where possible, and monitor for anomalous API key generation or configuration changes indicative of exploitation. Regular audits of authentication flows and ensuring that all privilege-checking functions validate session assurance levels are critical steps toward reducing risk until an official fix is released.