URGENT: Suspected account takeover, unauthorized account-level MFA lockout and abuse project hosting stolen credentials — Org "FairFuehrer" (Pro)

[dersaei]

Our Pro Account has been hacked. I can't submit support requests via supabase.help, thus, I will do it here as well. I have already sent a direct email submission, but Supabase treats this as a free-plan ticket. So, perhaps submitting this message here will help.

The ticket ID is SU-387338.

---

Hello Supabase Support / Security Team,

I am writing as the legitimate owner of the organization " on a Pro plan.
We suspect that our Supabase account has been compromised and that account-level MFA/2FA was enabled on the Supabase login without our consent, locking us out of the dashboard.

We are currently unable to access the Supabase dashboard via the normal login flow.
We performed a password reset on the account email ****, but after resetting the password we are now blocked by an MFA/2FA prompt that we never configured.

This indicates a likely account‑level takeover at the Supabase control‑plane level (dashboard / account MFA), not inside our project database.

On our side, we are rotating credentials and reviewing any systems that had access to this Supabase organization.

Below is a detailed technical report we prepared using read‑only Supabase MCP tooling, which still has API access. We did not perform any destructive or configuration changes during this analysis.

---

Subject: Suspected account takeover / unauthorized account-level MFA lockout —

1. CONTEXT
   We suspect our Supabase account (Pro plan, organization "", id gtjmtrxqbfutfquazbqm) has been compromised.
   Account-level MFA/2FA appears to have been enabled on the Supabase login without our consent, and we are currently locked out of the dashboard. We performed a read-only technical analysis via the Supabase MCP tooling (which still has API access) to assess impact. No destructive or configuration changes were made during this analysis.
   We are the legitimate owners of the organization on a Pro plan.

2. PROJECTS INSPECTED

• | ref | eu-central-1 | created 2025-05-17 | our main production app
• site | ref nbqwdwflfkdkbyguoxrq | us-east-1 | created 2026-05-29 | see point 6 below — we are NOT sure we created this

3. SUSPICIOUS / NOTEWORTHY FINDINGS

• Project "site" (ref nbqwdwflfkdkbyguoxrq) was created 2026-05-29, inside the suspected-compromise window, and does not correspond to any application we knowingly run.
• That project contains a single table public.credentials with 23,512 rows holding columns (email, password, url, source). RLS is DISABLED on it, and the anon and authenticated roles hold full SELECT/INSERT/UPDATE/DELETE/TRUNCATE grants — i.e. the data is reachable via the public REST API with the anon/publishable key. This looks like it may have been created by an unauthorized party. Hosting this kind of stolen credential combolist data appears to be a violation of your Acceptable Use Policy; we are reporting it so you can investigate and take appropriate action.
• In the main project (oockmooumzncrvkrjkcc): project-level Auth MFA table (auth.mfa_factors) is EMPTY, so the MFA blocking us is account/dashboard-level, not project-level.
• Database login roles in the main project are only the standard Supabase set (postgres, supabase_admin, supabase_auth_admin, authenticator, pgbouncer, etc.). No rogue superuser or rogue login role was found.
• Directus admin/staff accounts (9 total) are all known to us. No unknown privileged accounts.
• Admin activity log IPs are consistent residential German-ISP addresses (91.94.x.x) with a consistent Edge/Windows browser — consistent with our own staff, not an unknown attacker, for the main project.

4. DATABASE & RLS STATE (main project)

• RLS is enabled on all 56 public tables.
• Tables with personal/payment data (paypal_donations, partner_applications, contact_messages, account_contact_messages) have RLS enabled with NO policies, so they are closed to anon/authenticated and only reachable via service_role — acceptable.
• profiles / partner_profiles have correct owner-based policies (auth.uid() = id); partner_profiles additionally has a public-read SELECT policy (true) for the partner directory.
• No critical RLS advisor findings on the main project (only INFO/WARN level).

5. DATA INTEGRITY SIGNALS (main project)

• No evidence of mass deletion, TRUNCATE, or DROP. Row counts are healthy and consistent with a live app (Orte=596, auth.users=66, directus_users=9, directus_files=456, profiles=7).
• The only DELETE entries in the activity log (2026-05-16) were 2 records removed by a known admin, paired with normal application-generated inserts — routine cleanup, not malicious.
• No soft-delete columns / no spike in deleted rows.

6. POINTS WE'D LIKE SUPABASE SUPPORT TO ACTION

1. Remove / reset the account-level MFA on our Supabase login and restore our dashboard access via your account-recovery process (this MFA is in your control-plane, not in our project DB).
2. Investigate project "site" (ref nbqwdwflfkdkbyguoxrq, created 2026-05-29): confirm who created it, from which IP, and whether it was provisioned by an unauthorized party. We may want it paused/deleted after preservation.
3. Provide control-plane audit logs for org gtjmtrxqbfutfquazbqm: dashboard logins, MFA enrollment event, API key/access-token creation, project creation, and member/role changes over the last 30 days, with source IPs.
4. Confirm whether any management API tokens / personal access tokens were created recently, and rotate/revoke any we don't recognize.
5. Advise us to rotate the anon and service_role keys (JWT secret) on BOTH projects once access is restored, given the exposed public.credentials table.
6. Confirm no billing/payment-method or org-ownership changes were made on the account.

ADDITIONAL FINDING — project "site" (ref nbqwdwflfkdkbyguoxrq, created 2026-05-29 03:15 UTC):

This project was NOT created by us. It is in us-east-1 (our own projects are in eu-central-1) and was provisioned during the suspected account-takeover window. It contains a single owner user "matosg789@gmail.com" (created 2026-05-29 04:35 UTC, email unverified) that is not ours, and a single public table public.credentials with 23,512 rows.

The table is a stolen-credential "combolist" dump: columns (url, email, password, source) with a dedupe_hash = sha256(url||email||password). The source values are dump filenames such as "xferrecords.com.txt", "@HeroCloud1 (239).txt", "www.rockstargames.com.txt", "www.caixa.gov.br.txt". Target services in the data include Google, Discord, Epic Games, Amazon, Dropbox, Spotify, Sony PSN, EA, Mojang, iCloud. ~99.5% of the password values are plaintext (18,504 distinct, avg length 12.9). All 23,512 rows were bulk-inserted within a ~7 minute window on 2026-05-29 04:40–04:47 UTC.

CRITICAL: RLS is disabled on public.credentials and the anon and authenticated roles hold full SELECT/INSERT/UPDATE/DELETE/TRUNCATE grants, so the data is reachable via the public REST API with the project's anon key.

We did not create this project and want it preserved for investigation, then removed. Please:

• Identify who created project nbqwdwflfkdkbyguoxrq and from which IP / access token.
• Preserve and then take down this project; we do not want to host this data.
• Confirm whether the upload originated from a management API token we don't recognize.

We are flagging this as both a security incident (suspected account takeover) and a potential abuse case (hosting stolen credentials), and we are reporting this proactively as the legitimate org owner (Seenergien GmbH).

---

Thank you in advance for your urgent help on this matter.
Please let us know if you need any further verification details (company documents, billing details, additional logs) from our side.

Best regards,

---

[GaryAustin1]

I have an informal path to bump your ticket as a mod for Supabase on Discord. When did you submit the ticket to Supabase? Putting your details here other than the ticket number and a description of the general issue is not useful as these posts are unlikely to be seen by Supabase support and any private info you might delete.

[dersaei]

Thank you, Gary, for offering to bump the ticket. I submitted it by email today at around 8:20 PM CEST, ticket ID SU-387338. Really appreciate your help.