CVE-2026-88861
nicheAuthentication Bypass in Capgo Cloud Lets Password-Only Sessions Evade MFA
Capgo (Cap-go/capgo.app), an open-source over-the-air update service built on Supabase, fails to enforce multi-factor authentication on its privileged API paths: the Edge JWT middleware (foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts) accepts a password-only aal1 session without validating its assurance level, and the RBAC checks (checkPermission()/checkPermissionPg() calling public.rbac_check_permission_direct()) authorize by user ID without checking the session aal, unlike the public.verify_mfa() control which correctly requires aal2. An attacker who knows only a victim's password, for example through credential reuse or theft, can therefore authenticate without satisfying the victim's enrolled MFA factor and mint a persistent app-scoped app_admin API key that remains valid even after the password-only session is logged out. With that key the attacker can perform privileged operations such as modifying production OTA channel configurations, demonstrated by switching a public production channel from bundle 1.0.0 to 1.0.1, which alters what updates production app users receive and defeats the protection MFA is supposed to provide. All versions of the Capgo backend are affected and no patched version was available at the time of publication. No public proof of concept, CISA KEV listing, or known in-the-wild exploitation has been reported; the flaw carries a CVSS 4.0 score of 8.7 (High), driven by high confidentiality impact through minting privileged API keys.
What to do: Until an upstream fix is released, treat your Capgo password as single-factor: use a long, unique password, and revoke or rotate any app-scoped app_admin API keys you did not intentionally create. Review production OTA channel configurations for unauthorized changes (e.g., unexpected bundle or version switches) and check account history for unfamiliar password-only logins. Monitor the Cap-go/capgo.app repository for a patch to foundJWT() in supabase/functions/_backend/utils/hono_middleware.ts and checkPermission()/checkPermissionPg() in supabase/functions/_backend/utils/rbac.ts, and self-hosted operators should apply the fixed edge functions as soon as they are published.
| Cap-go Capgo (capgo.app) backend / Supabase edge functions | all versions; no fixed version available at time of publication |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.
- Weakness
- CWE-288
- Vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
In the news0 stories
No ingested article mentions this CVE yet.