CVE-2026-88861: Capgo AAL1 Session MFA Bypass via Direct RBAC Authorization
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/honomiddleware.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.rbaccheckpermissiondirect()) authorizes by user ID without passing or checking the session aal, unlike the public.verifymfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped appadmin 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update/adjust the Edge JWT middleware so that foundJWT() validates the JWT’s assurance level (AAL) and rejects/blocks privileged authorization when the session is aal1 and MFA assurance is not satisfied.
Supabase Edge JWT middleware (supabase/functions/_backend/utils/hono_middleware.ts; foundJWT()) JWT assurance level validation = enabled - Configuration
Change the direct RBAC authorization flow so it does not authorize solely by user ID; require passing and checking the session’s aal/assurance level for privileged operations (align behavior with public.verify_mfa() which requires aal2).
Supabase RBAC direct authorization (supabase/functions/_backend/utils/rbac.ts calling public.rbac_check_permission_direct()) Authorization input parameters (session AAL assurance) = validated - Compensating control
Mitigate the MFA bypass by ensuring that Edge authorization (RBAC) does not grant privileged permissions to password-only Supabase aal1 sessions; require assurance/AAL validation before authorizing any RBAC operations (i.e., do not allow the direct RBAC path to authorize by user ID without validating the session’s aal level, unlike public.verify_mfa()).
Event History
Frequently Asked Questions
Who is exposed to this issue?
Capgo deployments are affected in all versions, and no patched version was available at publication. Accounts with verified MFA factors are still exposed if privileged RBAC permissions can be reached through the affected Edge authorization and direct RBAC paths.
What does an attacker need to exploit it?
The attacker needs only the victim's password to create a password-only Supabase aal1 session. They do not need to complete the victim's verified MFA factor or obtain user interaction.
What access can an attacker obtain after bypassing MFA?
An attacker can exercise privileged RBAC permissions and mint a persistent app-scoped app_admin API key. That key remains valid after the aal1 session is logged out, enabling privileged actions such as changing production OTA channel configurations.
How can defenders determine whether the affected authorization logic is present?
Review the Edge JWT middleware foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts and the direct RBAC flow in checkPermission()/checkPermissionPg() in supabase/functions/_backend/utils/rbac.ts. The affected behavior accepts a JWT without validating its assurance level and authorizes by user ID without passing or checking the session aal.