Loading story…
Better Auth released v1.6.11 to fix a device authorization vulnerability that could let an authenticated attacker hijack or deny a sign-in if they obtained a valid pending user_code before the legitimate user finished verification. The flaw affected the deviceAuthorization plugin in versions 1.6.0 through 1.6.10 because pending device-code records were not bound to a user during GET /device, and POST /device/approve and POST /device/deny accepted any authenticated session when userId was unset. According to the advisory, exposure could occur through shoulder-surfing, screen sharing, support transcripts, referrer leakage, or shared logs, potentially resulting in account takeover on the polling device or denial of the intended login flow.
The same release also bundled broader security hardening across Better Auth’s authentication stack. Maintainers said they resolved race conditions in magic-link, OAuth authorization-code, and refresh-token flows that could mint multiple sessions or token sets from single-use credentials, and fixed authorization weaknesses involving invitation takeover, improper SSO provider registration permissions, and missing verified-email checks before linking OAuth identities. Additional changes added SSRF protections for user-supplied OIDC endpoints, stricter OAuth 2.1 and confidential-client enforcement, constant-time secret comparison, and safer SCIM token validation, aiming to reduce privilege abuse, token replay, cross-user authorization errors, and insecure federation setups.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
A GitHub security advisory disclosed that an authenticated attacker who learns a valid pending user_code could hijack or deny a device authorization flow in Better Auth versions 1.6.0 through 1.6.10. The advisory credits the Quikturn Security Team for reporting the issue and describes exposure paths such as screen sharing, support transcripts, and shared logs.
Better Auth fixed a deviceAuthorization plugin flaw affecting versions 1.6.0 through 1.6.10 in release 1.6.11. The fix claims the pending device-code row during GET /device and enforces strict session-to-owner matching on approve and deny actions.
Better Auth merged a fix for an OAuth account-linking flaw that could let an attacker hijack a victim's first OAuth sign-in by pre-registering the victim's email as an unverified local account. The change requires the local account email to already be verified before implicit linking, applies the same protection to the one-tap plugin, and normalizes Google ID-token email_verified values.
Better Auth merged a pull request fixing security issues in the legacy oidc-provider and mcp plugins by requiring confidential clients to authenticate with their client_secret during refresh-token grants. The change also introduced constant-time secret comparisons and removed the wildcard Access-Control-Allow-Origin header from the /mcp/token endpoint.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A critical vulnerability tracked as **`CVE-2026-73421`** and **`GHSA-8fpg-xm3f-6cx3`** affects **NextAuth.js / `next-auth`** in the v5 beta series before **`5.0.0-beta.32`**, allowing authentication checks to fail open under server misconfiguration. When provider settings were invalid—such as missing issuer or authorization endpoints, or an unset **`AUTH_SECRET`**—`@auth/core` could return an HTTP 500 response containing a JSON error object, and NextAuth wrappers incorrectly treated that body as session data instead of rejecting it. Because the returned error object was truthy, common authorization patterns such as checking whether `auth` or `req.auth` existed could mistakenly grant access to unauthenticated requests and expose protected routes. The maintainers fixed the issue in **`next-auth@5.0.0-beta.32`** by making non-OK session responses return `null` so `auth()` fails closed, and the release also pulled in related security hardening from **`@auth/core@0.41.3`**, including fixes for malformed Bearer token handling, provider-bound OAuth check cookies, and NFKC email normalization.
Aug 15, 2026
BerriAI disclosed and fixed **CVE-2026-59822**, an authentication bypass in LiteLLM versions prior to `1.84.0` that exposed the MCP Streamable HTTP endpoint to unauthenticated access. The flaw allowed a remote attacker to send a fabricated `Authorization` header that triggered an OAuth2 passthrough fallback path; when LiteLLM key validation failed, the application substituted an empty `UserAPIKeyAuth()` object and still allowed requests to reach MCP tooling. The vulnerability is classified under **CWE-287** and **CWE-306** and is described as network-exploitable without privileges or user interaction. The fix shipped in **LiteLLM v1.84.0**, alongside broader security hardening across authentication, authorization, and MCP-related features. Release notes for `v1.84.0` also highlight encrypted MCP credentials at rest, SSRF protections for OAuth metadata discovery follow-up fetches, hardened invite-link onboarding token handling, redaction of sensitive data, and signed Docker images that can be verified with `cosign` using a pinned public key and commit reference. Organizations running LiteLLM should upgrade to `1.84.0` or later and validate deployment artifacts as part of remediation.
Jul 9, 2026
SuiteCRM disclosed **CVE-2026-29189**, a high-severity insecure direct object reference (`IDOR`) flaw in its REST API V8 caused by missing ACL checks on user preferences and relationship endpoints. In versions before **7.15.1** and **8.9.3**, authenticated users could access or modify data beyond their assigned permissions, creating high confidentiality and integrity risk in deployments of the open-source CRM platform. The issue is tracked as **CWE-639** and carries a CVSS v3.1 rating reflecting low attack complexity and no user interaction requirement. Auth0 also patched **CVE-2026-34236** in the **Auth0-PHP SDK**, where insufficient entropy in cookie encryption allowed attackers to potentially brute-force encryption keys and forge session cookies. The flaw affects versions **8.0.0 through before 8.19.0** and is classified as **CWE-331**, with significant confidentiality and integrity impact for applications relying on the SDK for authentication. Auth0 fixed the issue in **8.19.0**, while SuiteCRM remediated its API authorization weakness in **7.15.1** and **8.9.3**.
Jun 29, 2026