Your Self-Hosted Supabase Auth Can Be Tricked Into Logging an Attacker In as Anyone (CVE-2026-31813). If You Run GoTrue With Apple or Azure Login, Patch to 2.185.0 This Weekend.
If you self-host Supabase and you turned on "Sign in with Apple" or Microsoft/Azure login, an attacker can hand your auth server a token they signed themselves and walk out with a logged-in session for any email address they choose. That's CVE-2026-31813, and the fix is a version bump you can do before lunch.
The detail that makes this nasty: the attack doesn't need a stolen password, a phishing page, or a leaked secret. It needs your email address and a provider you probably enabled because a user asked for it.
What the bug actually is
Supabase Auth (the service still widely called GoTrue) accepts OIDC ID tokens from federated providers like Apple and Azure. The whole point of an ID token is that your server trusts it because it was signed by the real provider. Validation of the token's issuer is what enforces that trust.
Per the GitHub security advisory (GHSA-v36f-qvww-8w8m) and the NVD entry, versions before 2.185.0 didn't validate the issuer properly on the ID-token sign-in flow. An attacker could craft a valid, asymmetrically signed ID token from their own issuer, set the email claim to a victim's address, and send it to the Supabase Auth token endpoint. The server validated the token against the attacker-controlled issuer instead of Apple's or Microsoft's, decided it looked fine, and issued a session for the victim. NVD and Red Hat both classify it as CWE-290, authentication bypass by spoofing.
In plain terms: the lock checked that the key was cut correctly, but never checked who made the key.
Who is exposed and who isn't
This is the part worth being precise about, because the answer determines whether you do anything this weekend.
If you use hosted Supabase (the managed platform on supabase.com), the auth servers are Supabase's to patch, and they roll fixes into the managed plane. You don't operate the vulnerable binary.
If you self-host (your own Docker Compose stack, your own supabase/gotrue (now supabase/auth) container, your own Kubernetes deployment) you are running the version you last pulled, and nothing upgrades it but you. That's the whole trade of self-hosting: you took the cost savings and the control, and the patching is now your job.
The trigger condition narrows it further. The exploit path runs through the Apple and Azure ID-token providers specifically. If you self-host and you never enabled either, you're not in the blast radius today. But "I think we turned Apple login off" is not the same as knowing, and providers get enabled during a feature push and forgotten. Check, don't assume.
The fix
Update to Supabase Auth 2.185.0 or later, which adds proper issuer validation for OIDC ID tokens.
If you run the container directly, that's a pull and a restart:
docker pull supabase/auth:v2.185.0 # or, if you're still on the old image name: docker pull supabase/gotrue:v2.185.0 docker compose up -d
If you pin the version in a Compose file or a Helm chart, bump it there and redeploy so a future docker compose pull doesn't silently drag you backward. After it's up, confirm the running version against the container's health or version endpoint rather than trusting that the tag did what you meant.
Then do the unglamorous part: assume the window between disclosure and your patch was exploitable, and look. Check your auth logs for ID-token sign-ins you can't explain, sessions created without a matching login event, and any account whose recent activity doesn't fit the user. If you find something, the response isn't just "patch." It's revoke sessions and rotate anything those sessions could reach.
Why I keep writing the same Saturday post
This is the fourth or fifth time I've written some version of "self-hosted thing X has a hole, patch it before the weekend," and the repetition is the point.
Self-hosting your auth saves you money and gives you control. It also quietly moves a job onto your plate that a managed provider was doing for you: watching the security advisories and shipping the patch the same day. When you're a one-person team, that job competes with shipping features, answering support, and sleeping. It's the first thing to slip, and auth is the worst place to let it slip, because a bug here isn't a degraded experience. It's someone else inside your users' accounts.
I'm not telling you to abandon self-hosting. I self-host plenty. I'm telling you that the honest cost of self-hosted auth includes a standing subscription to the project's security advisories and a rule that auth CVEs jump the queue. If you can't commit to patching auth within a day or two of disclosure, that's a real argument for paying for the managed plane and letting someone else carry the pager, not a moral failing, just a clear-eyed read of what your time is worth.
What I'd actually do this weekend
Three things, in order. Confirm whether your self-hosted stack has the Apple or Azure provider enabled: if it does, you're patching today, not Monday. Bump Supabase Auth to 2.185.0 or later and verify the running version, not just the tag. Then grep your auth logs for unexplained ID-token sign-ins during the exposure window, and revoke and rotate if anything looks off.
And while you're in there: subscribe to the supabase/auth security advisories on GitHub so the next one reaches you before a stranger's session does.
Author
Lukas
@lukcombinator