Six days ago this site covered Keycloak 26.7.3 and told community operators to patch identity on a schedule, not on a headline. This post is the companion piece, and it is aimed at anyone who read that one, patched Keycloak, and checked the box.

The apps in front of the identity layer ship their own trust boundaries.

The Bug

Mastodon 4.7.1 shipped September 1 with three security advisories, backported to every maintained branch — 4.7.1, 4.6.7, 4.5.17, and 4.4.24. Patched versions are all four; anything older on any branch is vulnerable.

The one to understand is GHSA-vx32-x96w-qq65: an incorrect check in the authentication flow allows moving on to the second authentication factor without providing a valid password when the account has no database-stored password — that is, accounts authenticated via LDAP, PAM, or OmniAuth (SSO).

Concretely: an attacker who has your TOTP code, backup code, or security key — phish, SIM swap, stolen device, bought credentials — can log in as you without ever touching your password or your IdP. Password check: skipped. SSO redirect: skipped. Second factor: accepted. CVSS 7.4 (High), network vector, no privileges, no user interaction.

The honest framing of the math: it is one factor instead of two, not zero for two. The attacker still needs a live possession factor. But the design intent of 2FA is that a stolen second factor alone should not be enough — the thing that made it bypassable was the combination this site's own recommended architecture creates: an external identity source plus 2FA enabled. That is why it deserves the post.

Two more in the same release:

  • GHSA-62j4-hvj7-px3f (CVSS 7.2) — the moderation "Freeze" (disable) action did not revoke the admin API. A frozen moderator could keep using the admin API — including the ability to un-freeze themselves. Suspension and role demotion were checked correctly; freeze was not.
  • GHSA-vgm8-frgh-rh2v — DoS via pathological JSON-LD activities, reachable through the federation protocol. Any reachable fediverse server is exposed; no interaction required.

Why This One Lands Here

Keycloak is identity. Mastodon is an app with its own login path — and its own bypass, one layer down.

The chain the site has been recommending for community deployments runs: fire hall members → Keycloak (one account store, real provisioning, shared signals) → Nextcloud, Matrix, Gitea, and yes, Mastodon via SSO. The 2FA bypass is a bug in the glue: the second-factor gate in the app's own flow trusts the password check happened, and when the password is checked elsewhere — LDAP, PAM, SSO — it never did.

Three things worth sitting with:

  1. Apps behind an IdP are still attack surface. The app's local auth code path runs for edge cases your IdP never sees — LDAP/PAM users, SSO-provisioned accounts, second-factor prompts. "It's all behind Keycloak" is a true statement about design and a false one about code.
  2. The bypass is in the integration combination, not just the code. LDAP/SSO accounts with 2FA enabled is the precise trigger condition. Every community server that followed the "centralize identity, turn on MFA everywhere" playbook sits exactly there. That is worth saying plainly because this site recommended the pattern.
  3. Freeze is an emergency stop, not a revocation. Before this patch, disabling a staff account left their admin API access intact — and the admin API could un-disable them. If your offboarding story for a rogue moderator is "freeze the account," it was not an offboarding story.

What To Do

  1. Upgrade to the patched branch release: 4.7.1, 4.6.7, 4.5.17, or 4.4.24. External dependencies did not change from 4.6.0 — this is a restart, not a migration. Docker deployments restart all Mastodon processes; source deployments bundle install and restart. Back up the database first; some 4.7 migrations did not re-run cleanly when interrupted, and this release fixes that too.
  2. After upgrading, sweep staff accounts. If you relied on Freeze for anyone you meant to permanently remove, treat them as removed now and demote or suspend properly. The API access from the Freeze bug is gone after the patch, but the audit question — who used it — predates it.
  3. Audit 2FA status for SSO/LDAP accounts. The trigger condition was "external auth + 2FA enabled." That was the vulnerable state, but the bypass needed a stolen second factor. Do not disable 2FA over this — patch and stay. If you want belt-and-braces on a community server, an authenticator app or security key you control still beats password reuse, which is the actual epidemic.
  4. If you run Keycloak in front, your 26.7.3 patch still stands. Two layers, two patch cycles, one habit.

The Habit, Again

This is the same lesson as the Keycloak post, now from the other side of the stack. Identity software gets patched in batches; the apps in front of it ship their own advisories on their own calendars. Both layers are load-bearing.

The pattern — centralize identity in Keycloak, federate the apps to it — remains the right architecture for community infrastructure. It collapses five password databases into one and makes departure a single action. But it needs an amendment, and the amendment is operational, not architectural: every SSO'd app is still a standalone security patch surface with its own advisory feed, and the second-factor gate in that app's own flow can fail independently of the IdP.

Federation distributes authority. It does not distribute patch work. Plan for both.