🚨 [security] Update next-auth 4.10.3 → 4.24.15 (minor) by depfu[bot] · Pull Request #32 · namdao2000/nextjs-worker-queue-starter

depfu · 2026-07-23T16:12:02Z

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ next-auth (4.10.3 → 4.24.15) · Repo · Changelog

Security Advisories 🚨

🚨 Auth.js: OAuth state, nonce, and PKCE check cookies are not bound to the provider that created them

Summary

Auth.js stores the OAuth/OIDC anti-CSRF checks (state, nonce, and the PKCE verifier) in global cookies that are not bound to the provider that created them. On callback, a check value minted during a sign-in started with one provider can satisfy the callback for a different provider, because the stored cookie is not verified against the callback provider's identity (provider id, issuer, client id, or redirect URI). In a multi-provider app that allows account linking while logged in, this provider-confusion / mix-up condition can let an attacker link their account at a second provider to a victim's user.

Am I affected?

You may be affected if all of the following hold:

You use next-auth <= 4.24.14 or >= 5.0.0-beta.1, <= 5.0.0-beta.31, or @auth/core <= 0.41.2.

You configure multiple OAuth/OIDC providers.

You allow users to link additional providers while logged in.

At least one configured provider's authorization request is observable by an attacker, and at least one target provider's callback can be satisfied without a PKCE verifier (i.e. it relies only on state or only on nonce).

You are not affected if you use a single OAuth provider, do not allow logged-in account linking, or all providers enforce PKCE.

Impact

Account-linking confusion: an attacker can get their account at a target provider linked to the victim's Auth.js user, granting the attacker persistent sign-in to the victim's account through that linked provider.

Exploitation requires luring the victim into starting a legitimate same-origin flow; it cannot be performed by cross-site request forgery alone, which reduces practical likelihood.

Patched version

The fix binds the OAuth check cookies to the provider/authorization flow that created them, so a callback cannot consume a check value minted for a different provider. Upgrade to the first releases containing this fix (pending; this advisory will be updated with exact patched versions before publication).

Workarounds

If you cannot upgrade immediately:

Enable PKCE (checks: ["pkce"], in addition to state/nonce) on every provider that supports it; PKCE blocks the practical code-swap variant because the attacker cannot observe the relying party's verifier.

Avoid offering logged-in account linking across multiple providers where one provider is lower-trust or attacker-observable.

Treat events.linkAccount as sensitive: add audit logging, user notification, or out-of-band confirmation so that any unexpected link is visible (defense-in-depth, not a root-cause fix).

Credit

Reported by @Nadav0077. Thank you for the responsible disclosure.

🚨 Auth.js: Email normalizer validates the address before Unicode normalization, allowing a homoglyph @ bypass

Summary

The default email-address normalizer used by the email/magic-link sign-in flow validates the address before applying Unicode normalization. An address can contain a Unicode character that is not an ASCII @ (U+0040) but canonicalizes to one under NFKC/NFKD normalization (the normalization commonly applied by mail libraries and services for internationalized email). Such an address passes the normalizer's single-@ check, but a downstream mail library that normalizes the string then sees two @ separators and may deliver the passwordless sign-in link to a different recipient than intended. This is an instance of validating before canonicalizing.

Am I affected?

You may be affected if all of the following hold:

You use next-auth >= 4.0.0, < 4.24.14, or @auth/core >= 0.1.0, < 0.41.3.

You have the email / magic-link (passwordless) provider enabled.

You rely on the built-in default identifier normalizer (you have not supplied your own normalizeIdentifier).

Your sendVerificationRequest implementation uses a mail library or delivery service that applies Unicode normalization to recipient addresses (most internationalized-email/SMTPUTF8-capable senders do).

You are not affected if you do not use the email provider, or if your normalizer/mailer rejects or canonicalizes non-ASCII addresses before they are validated.

Impact

Account takeover: an attacker who knows a victim's email address can request a magic link that is delivered to an attacker-controlled mailbox, then use it to sign in as the victim.

No victim interaction is required to misroute the link; the attacker initiates the flow.

Patched version

The fix applies Unicode (NFKC) normalization before the address is validated, so homoglyph separators are collapsed and rejected up front. Upgrade to the first release containing this fix (pending; this advisory will be updated with the exact patched version before publication). No application code changes are required after upgrading.

Workarounds

If you cannot upgrade immediately:

Supply a custom normalizeIdentifier on the email provider that calls identifier.normalize("NFKC") (and lower-cases/trims) before any validation, and rejects addresses that do not contain exactly one @ after normalization.

Or reject any address whose local part or domain contains non-ASCII characters, if your user base does not require internationalized email addresses.

Credit

Reported by @kakashi-kx. Thank you for the responsible disclosure.

🚨 Auth.js: getToken() throws an uncaught exception on malformed Bearer authorization headers

Summary

The exported getToken() helper (next-auth/jwt and @auth/core/jwt) can throw an uncaught exception when it reads a malformed Authorization: Bearer … header. When no session cookie is present, getToken() URL-decodes the bearer value before validating it, and malformed percent-encoding causes the decode step to throw rather than being treated as an invalid token. Because getToken() is commonly called in API routes, middleware, and other request handlers, a single unauthenticated request can trigger an unhandled exception in code paths that authenticate requests.

Am I affected?

You are affected if all of the following hold:

You use next-auth <= 5.0.0-beta.25 (or @auth/core exposing the same getToken() implementation).

Your application calls getToken() directly — for example in a Route Handler, middleware, or server-side request handler.

You do not wrap that getToken() call in your own try/catch.

You are not affected if you only use the framework's auth() helper and never call getToken() yourself, or if every getToken() call site already has its own exception handling.

Impact

Denial of service: an unauthenticated request carrying a malformed Bearer authorization header can raise an unhandled exception in any handler that calls getToken().

The impact is per-request and limited to availability; it does not expose tokens, sessions, or other data, and does not bypass authentication.

CWE-20: Improper Input Validation.

Patched version

The fix makes getToken() treat a malformed Bearer value as an invalid token and return null, matching how other undecodable tokens are already handled. Upgrade to the first release containing this fix (to be published; this advisory will be updated with the exact patched version before publication) and no code changes are required.

Workarounds

If you cannot upgrade immediately, either:
Config/code-level: wrap your getToken() calls so a thrown error is treated as "no token", e.g.
let token = null
try {
  token = await getToken({ req, secret })
} catch {
  token = null
}
Or strip/normalize the incoming Authorization header at the edge (proxy, middleware) before it reaches getToken(), rejecting values whose Bearer portion is not valid percent-encoding.
Credit

Reported by @deprrous. Thank you for the responsible disclosure.

🚨 Possible user mocking that bypasses basic authentication

Impact

next-auth applications prior to version 4.24.5 that rely on the default Middleware authorization are affected.

A bad actor could create an empty/mock user, by getting hold of a NextAuth.js-issued JWT from an interrupted OAuth sign-in flow (state, PKCE or nonce).

Manually overriding the next-auth.session-token cookie value with this non-related JWT would let the user simulate a logged in user, albeit having no user information associated with it. (The only property on this user is an opaque randomly generated string).

This vulnerability does not give access to other users' data, neither to resources that require proper authorization via scopes or other means. The created mock user has no information associated with it (ie. no name, email, access_token, etc.)

This vulnerability can be exploited by bad actors to peek at logged in user states (e.g. dashboard layout).

Note: Regardless of the vulnerability, the existence of a NextAuth.js session state can provide simple authentication, but not authorization in your applications. For role-based access control, you can check out our guide.

Patches

We patched the vulnerability in next-auth v4.24.5. To upgrade, run one of the following:
npm i next-auth@latest
yarn add next-auth@latest
pnpm add next-auth@latest
Workarounds

Upgrading to latest is the recommended way to fix this issue. However, using a custom authorization callback for Middleware, developers can manually do a basic authentication:
// middleware.ts
import { withAuth } from "next-auth/middleware"
export default withAuth(/your middleware function/, {

// checking the existence of any property - besides value which might be a random string - on the token object is sufficient to prevent this vulnerability

callbacks: { authorized: ({ token }) => !!token?.email }

})
References

NextAuth.js Middleware

Role-based access contorl (RBAC) guide

🚨 Missing proper state, nonce and PKCE checks for OAuth authentication

Impact

next-auth applications using OAuth provider versions before v4.20.1 are affected.

A bad actor who can spy on the victim's network or able to social engineer the victim to click a manipulated login link could intercept and tamper with the authorization URL to log in as the victim, bypassing the CSRF protection.

As an example, an attack can happen in the following scenario.

TL;DR: The attacker steals the victim's authenticated callback by intercepting and tampering with the authorization URL created by next-auth.

The victim attempts to log in to the next-auth site. For example https://next-auth-example.vercel.app/

next-auth sets the checks cookies according to how the OAuth provider is configured. In this case, state and pkce are set by default for the Google Provider.

The attacker intercepts the returned authorization URL, strips away the OAuth check (nonce, state, pkce), and returns the URL without the check to the victim's browser. For example:
From
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?client_id=client_id&scope=openid%20email%20profile&response_type=code&redirect_uri=https%3A%2F%2Fnext-auth-example.vercel.app%2Fapi%2Fauth%2Fcallback%2Fgoogle&state=state&code_challenge=code_challenge&code_challenge_method=S256&service=lso&o2v=2&flowName=GeneralOAuthFlow
to
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?client_id=client_id&scope=openid%20email%20profile&response_type=code&redirect_uri=https%3A%2F%2Fnext-auth-example.vercel.app%2Fapi%2Fauth%2Fcallback%2Fgoogle&service=lso&o2v=2&flowName=GeneralOAuthFlow.
Notice the parameters state, code_challenge and code_verifier are removed from the victim's address bar.

The victim attempts to log in using their OAuth account.

The Authorization Server logs the victim in and calls back to the next-auth api/auth/callback/:providerIdendpoint.
5.1. The attacker intercepts and logs this callback URL for later use.
5.2. next-auth checks the callback call from OAuth Authorization Server (doesn't have checks) and compares the checks with the cookies set (has checks) at step 2. This check will fail, resulting in the victim isn't logged in. However, at this step, the Authorization Server has already accepted the victim's request to log in and generated/sent a code in the URL.

The attacker now has an authorization URL with the code that the AS will exchange for valid access_token/id_token and can log in as the victim automatically. They can open a new browser window and paste in the URL logged at step 5.1 and log in as the victim.

Patches

We patched the vulnerability in next-auth v4.20.1
To upgrade, run one of the following:
npm i next-auth@latest
yarn add next-auth@latest
pnpm add next-auth@latest
Workarounds

Upgrading to latest is the recommended way to fix this issue. However, using Advanced Initialization, developers can manually check the callback request for state, pkce, and nonce against the provider configuration, and abort the sign-in process if there is a mismatch. Check out the source code for help.

References

CSRF

PKCE vs nonce

OAuth provider options

checks provider config

↗️ @babel/runtime (indirect, 7.18.9 → 7.29.7) · Repo · Changelog

Security Advisories 🚨

🚨 Babel has inefficient RegExp complexity in generated code with .replace when transpiling named capturing groups

Impact

When using Babel to compile regular expression named capturing groups, Babel will generate a polyfill for the .replace method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to .replace).

Your generated code is vulnerable if all the following conditions are true:

You use Babel to compile regular expression named capturing groups

You use the .replace method on a regular expression that contains named capturing groups

Your code uses untrusted strings as the second argument of .replace

If you are using @babel/preset-env with the targets option, the transform that injects the vulnerable code is automatically enabled if:

you use duplicated named capturing groups, and target any browser older than Chrome/Edge 126, Opera 112, Firefox 129, Safari 17.4, or Node.js 23

you use any named capturing groups, and target any browser older than Chrome 64, Opera 71, Edge 79, Firefox 78, Safari 11.1, or Node.js 10

You can verify what transforms @babel/preset-env is using by enabling the debug option.

Patches

This problem has been fixed in @babel/helpers and @babel/runtime 7.26.10 and 8.0.0-alpha.17, please upgrade. It's likely that you do not directly depend on @babel/helpers, and instead you depend on @babel/core (which itself depends on @babel/helpers). Upgrading to @babel/core 7.26.10 is not required, but it guarantees that you are on a new enough @babel/helpers version.

Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code.

Workarounds

If you are passing user-provided strings as the second argument of .replace on regular expressions that contain named capturing groups, validate the input and make sure it does not contain the substring $< if it's then not followed by > (possibly with other characters in between).

References

This vulnerability was reported and fixed in #17173.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by 2 commits:

↗️ cookie (indirect, 0.4.2 → 0.7.2) · Repo · Changelog

Security Advisories 🚨

🚨 cookie accepts cookie name, path, and domain with out of bounds characters

Impact

The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value) would result in "userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test", setting userName cookie to <script> and ignoring value.

A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie.

Patches

Upgrade to 0.7.0, which updates the validation for name, path, and domain.

Workarounds

Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.

References

#167

Release Notes

0.7.2

Fixed

Fix object assignment of hasOwnProperty (#177) bc38ffd

v0.7.1...v0.7.2

0.7.1

Fixed

Allow leading dot for domain (#174)

Although not permitted in the spec, some users expect this to work and user agents ignore the leading dot according to spec

Add fast path for serialize without options, use obj.hasOwnProperty when parsing (#172)

v0.7.0...v0.7.1

0.7.0

perf: parse cookies ~10% faster (#144 by @kurtextrem and #170)

fix: narrow the validation of cookies to match RFC6265 (#167 by @bewinsnw)

fix: add main to package.json for rspack (#166 by @proudparrot2)

v0.6.0...v0.7.0

0.6.0 (from changelog)

Add partitioned option

0.5.0

Add priority option

Fix expires option to reject invalid dates

pref: improve default decode speed

pref: remove slow string split in parse

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 72 commits:

↗️ jose (indirect, 4.8.3 → 4.15.9) · Repo · Changelog

Security Advisories 🚨

🚨 jose vulnerable to resource exhaustion via specifically crafted JWE with compressed plaintext

A vulnerability has been identified in the JSON Web Encryption (JWE) decryption interfaces, specifically related to the support for decompressing plaintext after its decryption. This allows an adversary to exploit specific scenarios where the compression ratio becomes exceptionally high. As a result, the length of the JWE token, which is determined by the compressed content's size, can land below application-defined limits. In such cases, other existing application level mechanisms for preventing resource exhaustion may be rendered ineffective.

Note that as per RFC 8725 compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. For this reason the v5.x major version of jose removed support for compressed payloads entirely and is therefore NOT affected by this advisory.

Impact

Under certain conditions it is possible to have the user's environment consume unreasonable amount of CPU time or memory during JWE Decryption operations.

Affected users

The impact is limited only to Node.js users utilizing the JWE decryption APIs to decrypt JWEs from untrusted sources.

You are NOT affected if any of the following applies to you

Your code uses jose version v5.x where JWE Compression is not supported anymore

Your code runs in an environment other than Node.js (e.g. Deno, CF Workers), which is the only runtime where JWE Compression is implemented out of the box

Your code does not use the JWE decryption APIs

Your code only accepts JWEs produced by trusted sources

Patches

v2.0.7 and v4.15.5 releases limit the decompression routine to only allow decompressing up to 250 kB of plaintext. In v4.x it is possible to further adjust this limit via the inflateRaw decryption option implementation. In v2.x it is possible to further adjust this limit via the inflateRawSyncLimit decryption option.

Workarounds

If you cannot upgrade and do not want to support compressed JWEs you may detect and reject these tokens early by checking the token's protected header
const { zip } = jose.decodeProtectedHeader(token)
if (zip !== undefined) {
  throw new Error('JWE Compression is not supported')
}
If you wish to continue supporting JWEs with compressed payloads in these legacy release lines you must upgrade (v1.x and v2.x to version v2.0.7, v3.x and v4.x to version v4.15.5) and review the limits put forth by the patched releases.

For more information

If you have any questions or comments about this advisory please open a discussion in the project's repository

🚨 JOSE vulnerable to resource exhaustion via specifically crafted JWE

The PBKDF2-based JWE key management algorithms expect a JOSE Header Parameter named p2c (PBES2 Count), which determines how many PBKDF2 iterations must be executed in order to derive a CEK wrapping key. The purpose of this parameter is to intentionally slow down the key derivation function in order to make password brute-force and dictionary attacks more expensive.

This makes the PBES2 algorithms unsuitable for situations where the JWE is coming from an untrusted source: an adversary can intentionally pick an extremely high PBES2 Count value, that will initiate a CPU-bound computation that may take an unreasonable amount of time to finish.

Impact

Under certain conditions (see below) it is possible to have the user's environment consume unreasonable amount of CPU time.

Affected users

The impact is limited only to users utilizing the JWE decryption APIs with symmetric secrets to decrypt JWEs from untrusted parties who do not limit the accepted JWE Key Management Algorithms (alg Header Parameter) using the keyManagementAlgorithms (or algorithms in v1.x) decryption option or through other means.

The PBKDF2-based JWE Key Management Algorithm Identifiers are

PBES2-HS256+A128KW

PBES2-HS384+A192KW

PBES2-HS512+A256KW

e.g.
const secret = new Uint8Array(16)
const jwe = '...' // JWE from an untrusted party
await jose.compactDecrypt(jwe, secret)
You are NOT affected if any of the following applies to you

Your code does not use the JWE APIs

Your code only produces JWE tokens

Your code only decrypts JWEs using an asymmetric JWE Key Management Algorithm (this means you're providing an asymmetric key object to the JWE decryption API)

Your code only accepts JWEs produced by trusted sources

Your code limits the accepted JWE Key Management Algorithms using the keyManagementAlgorithms decryption option not including any of the PBKDF2-based JWE key management algorithms

Patches

v1.28.2, v2.0.6, v3.20.4, and v4.9.2 releases limit the maximum PBKDF2 iteration count to 10000 by default. It is possible to adjust this limit with a newly introduced maxPBES2Count decryption option.

Workarounds

All users should be able to upgrade given all stable semver major release lines have had new a patch release introduced which limits the PBKDF2 iteration count to 10000 by default. This removes the ability to craft JWEs that would consume unreasonable amount of CPU time.

If users are unable to upgrade their required library version they have two options depending on whether they expect to receive JWEs using any of the three PBKDF2-based JWE key management algorithms.

they can use the keyManagementAlgorithms decryption option to disable accepting PBKDF2 altogether

they can inspect the JOSE Header prior to using the decryption API and limit the PBKDF2 iteration count (p2c Header Parameter)

For more information

If you have any questions or comments about this advisory:

Open an discussion in the project's repository

Email me at panva.ip@gmail.com

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ openid-client (indirect, 5.1.8 → 5.7.1) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@depfu rebase
Rebases against your default branch and redoes this update

@depfu recreate
Recreates this PR, overwriting any edits that you've made to it

@depfu merge
Merges this PR once your tests are passing and conflicts are resolved

@depfu cancel merge
Cancels automatic merging of this PR

@depfu close
Closes this PR and deletes the branch

@depfu reopen
Restores the branch and reopens this PR (if it's closed)

@depfu pause
Ignores all future updates for this dependency and closes this PR

@depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR

@depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

Update next-auth to version 4.24.15

3d9fa58

depfu Bot added the depfu label Jul 23, 2026

depfu Bot mentioned this pull request Jul 23, 2026

🚨 [security] Update next-auth 4.10.3 → 4.24.5 (minor) #7

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

🚨 [security] Update next-auth 4.10.3 → 4.24.15 (minor) - #32

🚨 [security] Update next-auth 4.10.3 → 4.24.15 (minor)#32
depfu[bot] wants to merge 1 commit into
mainfrom
depfu/update/npm/next-auth-4.24.15

depfu Bot commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

depfu Bot commented Jul 23, 2026

What changed?

✳️ next-auth (4.10.3 → 4.24.15) · Repo · Changelog

Summary

Am I affected?

Impact

Patched version

Workarounds

Credit

Summary

Am I affected?

Impact

Patched version

Workarounds

Credit

Summary

Am I affected?

Impact

Patched version

Workarounds

Credit

Impact

Patches

Workarounds

References

Impact

Patches

Workarounds

References

↗️ @​babel/runtime (indirect, 7.18.9 → 7.29.7) · Repo · Changelog

Impact

Patches

Workarounds

References

↗️ cookie (indirect, 0.4.2 → 0.7.2) · Repo · Changelog

Impact

Patches

Workarounds

References

0.6.0 (from changelog)

↗️ jose (indirect, 4.8.3 → 4.15.9) · Repo · Changelog

Impact

Affected users

Patches

Workarounds

For more information

Impact

Affected users

Patches

Workarounds

For more information

↗️ openid-client (indirect, 5.1.8 → 5.7.1) · Repo · Changelog

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

↗️ @babel/runtime (indirect, 7.18.9 → 7.29.7) · Repo · Changelog