OAuth's rough month: What five recent vulnerabilities say about token trust

OAuth turned twenty last year, and the protocol is showing it in a different way than SAML does. SAML's problems tend to live in XML parsing and signature validation. OAuth's problems tend to live in trust boundaries: which issuer is allowed to vouch for which user, what happens when a flow is only half configured, and what an attacker can do with an endpoint nobody remembered was reachable.

The last few weeks have produced a good cross section of all three. Here's what happened, and what it means if you're running OAuth anywhere in your stack.

miniOrange OAuth SSO plugin, unauthenticated admin takeover (CVE-2026-57807)

This is the most severe item on the list. Patchstack disclosed a critical flaw (CVSS 9.8) in miniOrange's OAuth Single Sign-On plugin for WordPress on July 9, affecting all versions up to 38.5.8. As of this writing there's no official patch.

The bug sits in the plugin's password recovery flow. Security researcher Kim Dvash found an alternate path through the OAuth client's authentication logic that lets an attacker trigger password recovery for any account, including the administrator, without ever authenticating. No credentials, no social engineering, no user interaction. An attacker just needs to find a site running the plugin and send the right request.

What makes this one sting is the plugin's job description. It exists specifically to add SSO and harden login. miniOrange's OAuth client also shipped a different authentication bypass in December 2024, so this isn't the first time the login-hardening plugin has been the weakest link in the chain. Patchstack expects the usual pattern: automated scanning and mass exploitation attempts against any WordPress site still running the plugin, regardless of how much traffic it gets.

If you or a customer runs this plugin, the advice is blunt: remove it until a patch ships, and rotate anything downstream that trusted sessions it created.

n8n token exchange cross-issuer confusion (CVE-2026-59208)

This one is a more interesting engineering story than a mass-exploitation story, and it's worth understanding even if you never touch n8n.

n8n offers a token exchange feature for enterprise OEM partners, an implementation of RFC 8693 that lets a partner's own signed JWT log a user into n8n directly, skipping a second login screen. The partner signs a short-lived token with its own key, n8n verifies it against a configured public key, matches the claims to a local account, and issues a session.

The flaw: n8n validated that the token was signed by a trusted key, but didn't correctly bind that verification to which issuer the key belonged to. A valid token from Issuer A, carrying a sub claim that happened to match a user under Issuer B, could log an attacker in as that user under Issuer B. No password required, because the flow doesn't use one.

n8n shipped a fix on June 24; the CVE went public on July 9. Notably, the report came from an AI penetration testing agent (Strix), which flagged the token exchange endpoint as worth a closer look and traced the identity binding gap there.

This is a confused deputy problem wearing OAuth clothing: the system correctly checked "is this signature valid" and incorrectly treated that as equivalent to "is this the right issuer for this claim." It's the kind of bug that only shows up in multi-tenant, multi-issuer setups, which describes a lot of B2B SaaS token exchange and delegation flows, not just n8n's.

Better Auth's June 2026 security update

Better Auth, the open source auth library that Vercel recently acquired, shipped a security update in June covering multiple scoped packages, including @better-auth/sso, @better-auth/scim, and @better-auth/oauth-provider. The update also confirmed that the oidcProvider and mcp plugins, deprecated for roughly six months, are being removed in the next major version, with migration steered toward @better-auth/oauth-provider.

The details vary by advisory, but the pattern is familiar: the SSO, SCIM, and OAuth provider plugins are exactly the surface area that gets exercised least in testing and hit hardest by attackers, because they're the parts of an auth library that talk to other systems' trust decisions rather than just your own.

Worth flagging for two reasons. First, if you're running Better Auth's SSO or SCIM plugins in production, the update is not optional reading, check which packages you have pinned and whether you're past the fixed versions. Second, this lands right as Better Auth is mid-acquisition and pushing users toward its own OAuth provider plugin, which is a reasonable technical direction but also means teams evaluating whether to stay are doing so against a backdrop of active security churn in the exact plugins they'd be relying on. We covered the broader migration question in more detail when Vercel acquired Better Auth.

RabbitMQ management endpoint exposes OAuth client secrets (CVE-2026-5721)

RabbitMQ, widely used for message routing between services, has an obsolete management endpoint that returns a configured OAuth client secret without requiring authentication, when RabbitMQ is set up with a confidential client for an OIDC or OAuth identity provider. CVSS 8.7.

The identity providers named as commonly affected read like a standard enterprise IAM stack: Auth0, Entra ID, Keycloak, and Cloud Foundry UAA. If your RabbitMQ deployment authenticates against one of these with a confidential client, an attacker who can reach the management interface can pull the client secret and potentially mint tokens or access administrator-level broker functionality.

The bug had reportedly been sitting in the codebase for over two years before being flagged. Nothing exotic about it, just an endpoint nobody thought to lock down because it predated the current auth configuration.

OAuth bypass in default installations (CVE-2026-48611)

The last one is a reminder that "we don't use that feature" isn't the same as "that feature isn't reachable." A vulnerability disclosed in a forum-software OAuth implementation allows account hijacking, including administrator accounts, on installations where OAuth was never configured by an admin at all.

The authentication handler accepts identity claims from OAuth-shaped requests without first confirming that an OAuth provider is actually configured, and without cryptographically validating the assertion. An attacker sends a crafted request to the OAuth login route naming a target account, and the application happily establishes a session for it. The vulnerable code path is live by default, whether or not anyone ever turned OAuth on.

The pattern

Four different codebases, four different failure modes, one shared root cause: OAuth's security model depends on correctly identifying who is allowed to vouch for whom, and that check keeps getting implemented as "is this token well formed" instead of "is this token from the party I think it's from, for the identity it claims."

A few things worth internalizing:

• Issuer binding is the hard part, and it's invisible until it isn't. The n8n bug passed signature verification. The miniOrange bug passed as a legitimate password-recovery request. The forum-software bug passed because nobody checked whether OAuth was even supposed to be active. In every case, the code was checking a real thing, just not the thing that actually establishes trust.
• Login-hardening tools are not exempt. SSO plugins, MFA add-ons, and identity brokers exist specifically to reduce authentication risk, and they keep turning out to be the highest value target precisely because compromising them compromises everything behind them.
• Dormant code paths are still attack surface. The forum-software bug and the RabbitMQ endpoint were both reachable regardless of whether anyone had configured or was actively using the feature. Unused doesn't mean unlocked.
• Multi-tenant, multi-issuer flows need their own review pass. Token exchange, delegation, and any flow where more than one issuer's tokens land in the same verification path deserve scrutiny beyond "does the signature check pass." That's a different question than the one most auth code answers.

What to do about it

If you're running OAuth anywhere in your stack, a few concrete steps:

• Inventory your OAuth-adjacent plugins and libraries, not just your primary auth provider. SSO plugins, message brokers with OIDC configuration, and OAuth client libraries all count. The RabbitMQ and miniOrange bugs both lived in software that wasn't the application's core identity system.
• If you accept tokens from more than one issuer, audit whether your verification logic actually binds a validated signature to the specific issuer it claims to be from, not just to any key in a trusted set. This is exactly the gap the n8n bug exploited.
• Check whether unused auth features are still reachable. If OAuth is configured but unused, or present in your codebase but disabled, verify that the code path is actually gated, not just unlinked from your UI.
• Patch on the vendor's timeline, not yours. miniOrange has no fix as of this writing; if you're running it, removal is the only current mitigation. Better Auth users on the SSO, SCIM, or OAuth provider plugins should check the June advisories against their pinned versions now.
• Don't assume "OAuth" means "simpler than SAML." OAuth avoids XML parsing complexity, but it trades that for trust boundary complexity across issuers, scopes, and delegation chains. Both categories produce critical bugs; they just look different.

OAuth's failures this cycle aren't about a fragile parser the way SAML's are. They're about trust boundaries that are easy to state and surprisingly easy to get subtly wrong in code, especially the moment more than one issuer, more than one tenant, or more than one plugin enters the picture. That's the harder problem to catch in review, and it's exactly the kind of problem that shows up first in production rather than in a test suite.

If you're maintaining your own OAuth integration across multiple identity providers and want someone else carrying the pager for the next one of these, WorkOS handles SSO and OAuth so you don't have to.