Locked out: account requires TOTP MFA that was never enabled (ticket SU-431238)

[lourencomantovani-cloud]

I'm locked out of my dashboard and I believe this is an anomaly, not a
standard lost-device case.

I sign in with GitHub. After the GitHub step I land on
supabase.com/dashboard/sign-in-mfa (method=github), asking for a 6-digit
TOTP code. I never enabled MFA on this account — I never went through the
enrollment flow, was never shown recovery codes, and there is no
authenticator app holding this factor. There is no device to recover from.

What I already tried:
· "Force sign out and clear cookies" on that screen — same screen returns
· Incognito window and a second browser — same screen returns
· The in-dashboard support form is unusable: it returns
"Insufficient AAL: MFA required", so the MFA block itself prevents
filing a ticket there
· Ticket already opened by email: SU-431238

The screen offers no backup-code option and no alternative factor, which
is consistent with never having completed an enrollment flow.

Since I did not enable this factor myself, I'd also like it checked
whether it was enrolled by someone else, and what the enrollment date is.

I'm posting from the GitHub account that owns the Supabase account, which
should help with ownership verification. I can provide the account email,
project ref, key prefixes, edge function names or a DNS/file challenge
privately.

Is there anyone from the team who can route this to the security team?
Screenshot of the MFA screen attached.

[GaryAustin1]

Supabase support will have to look at this.
Their account group though is very backed up, so it will take awhile.

[lourencomantovani-cloud]

Follow-up. I'd like to reframe this, because I think it has been queued as a support request when it may be a security one.

A TOTP factor exists on my account that I did not enroll. I never went through an enrollment flow, was never shown recovery codes, and no authenticator app holds this factor. There is no device to recover from, because there was never a device. That is not a lost-device scenario — it is an unexplained authentication factor on an account, and the enrollment record on your side will show which one it is.

What I'm asking for, before and independent of any access restoration:

1. The enrollment timestamp of this TOTP factor.
2. The origin of that enrollment request.
3. Whether any other change was made to the account around the same time.

If the enrollment traces back to something I can account for, I'll drop this and wait in the normal queue. If it does not, then an account was accessed by someone who is not its owner, and the queue is the wrong place for it.

Additional evidence that both reporting paths are blocked: the public form at supabase.com/support/new cannot enumerate my account while the session is held at the MFA step — the organization selector shows "No specific organization" and the project selector returns "No projects found" (screenshot attached). The in-dashboard form returns "Insufficient AAL: MFA required". Email ticket SU-431238 is the only channel that accepted the report.

I'm commenting from the GitHub account that owns the Supabase account and can complete any ownership challenge you prefer, privately.

[GaryAustin1]

You should add that to your support ticket. Supabase staff is unlikely to see your project/account specific issue here. Official support is only thru support@supabase.com and the dashboard.

[lourencomantovani-cloud]

Follow-up: 4 days since SU-431238, no response.
The lockout affects two production projects.
Is there any way to get this routed to the accounts team?

[lourencomantovani-cloud]

Thanks Gary, appreciate you flagging it

[lourencomantovani-cloud]

Following up again — @GaryAustin1 thanks again for adding it to the informal queue.
Still no reply from the account team since then.

Update — day 7, still locked out.

The in-dashboard support form remains unusable (it returns "Insufficient AAL: MFA
required", so the MFA block itself prevents filing a ticket). Ticket SU-431238 has had
no reply from the support team, and I have also followed up by email with no response.

Current impact on a production project:

• I cannot configure custom SMTP, which blocks all transactional email — signup
  confirmation, password reset and partner invitations
• I cannot manage API secrets or auth settings
• I cannot delete auth users, so test accounts cannot be removed
• I cannot upgrade to a paid plan — the billing page is behind the same MFA wall.
  I am willing to pay for this project and the lockout is what prevents it
• Anything outside the SQL and Edge Functions surface is unreachable

To be clear about what this is not: this is not a lost-device case. I never enrolled
MFA — no enrollment flow, no recovery codes, no authenticator app holding the factor.
That is why no backup code exists to try, and why the screen offers no alternative factor.

I'm still happy to verify ownership any way that helps: account email, project ref, key
prefixes, edge function names, a DNS TXT record on my domain, or a file challenge on the
deployed app. I'm posting from the GitHub account that owns the Supabase account.

Two questions I'd appreciate an answer to, even if the fix itself takes longer:

1. Is there an expected timeframe for account-team tickets right now?
2. Can the enrollment date and source of this MFA factor be checked? If I did not enroll
   it, I'd like to know who or what did.

There is an irony here I'd like to flag: I want to upgrade this project to a paid plan,
partly to have proper support. The lockout prevents me from doing that too — so a free
account stays stuck in the free-tier queue, with no way to leave it.

I'd rather not migrate a working project to another provider over a support queue, but
seven days without a reply on a total dashboard lockout — with no path to upgrade —
makes that hard to justify.

[GaryAustin1]

We heard yesterday well over a week and we have seen some clearly that in Discord.

This https://supabase.com/blog/sign-in-with-chatgpt-beta is solving some issues for Github users locked out for banned Github accounts.
It might be worth trying with same email you are using for Github. Of course if 2fa is turned on at the Supabase level probably won't help. But if just some glitch... maybe.

[lourencomantovani-cloud]

@GaryAustin1 tried it — thanks for the suggestion. Same email on GitHub, Supabase and ChatGPT (primary and verified on GitHub). Signing in with ChatGPT did link to my existing account, but it lands on the same TOTP screen.

So this confirms the factor is bound to the account itself, not to the GitHub sign-in path — no alternative provider gets around it. Worth knowing for anyone else in this thread.

Which brings the three questions from my earlier comment back to the front, and none of them need access to be restored to be answered:

1. The enrollment timestamp of this TOTP factor.
2. The origin of that enrollment request.
3. Whether any other change was made to the account around the same time.

Still no reply on SU-431238.

[GaryAustin1]

Only support/account team can answer those questions. Github and Discord are not monitored regularly by staff and even regular employees can't touch account issues.

Right we are seeing well over 7 days and that includes Pro accounts. Free is more than those.

[lourencomantovani-cloud]

Update — 6 days later, still locked out.

Two things have changed since I posted:

1. The support form now fails differently. It shows
   "Failed to fetch permissions: Insufficient AAL: MFA required" and cannot
   list my organizations or projects ("No specific organization" /
   "No project has been selected"). So the MFA block prevents me from filing
   a ticket against the affected project — the escalation path is blocked by
   the very problem I need escalated.

2. This is production data. The project holds legal case files for 84 client
   families: 691 individuals and 1,162 civil registry certificates used in
   Italian citizenship proceedings.

I have been unable to configure SMTP, manage auth settings or upgrade the
plan for a week. I am now preparing to migrate everything to a new account,
which is not what I want to do, but I cannot leave production data on an
account I cannot administer.

Ticket SU-431238 remains without resolution. Is there any way to route this
to the security or accounts team directly?

[GaryAustin1]

Nothing can happen from Github. Your ticket is in the informal queue but all that does is make sure it is in the account team queue. Only the account team can deal with these.

[GaryAustin1]

If locked out of the account the only way to support is thru the email.
But you are very likely in the correct queue and not a lost ticket so sending more requests would not move you up the queue ahead of others waiting even longer.