🚨 [security] Update next-auth 4.0.0-beta.6 → 4.24.15 (minor) by depfu[bot] · Pull Request #301 · https-quantumblockchainai-atlassian-net/crystal-ai-nextjs-planetscale-starter

depfu · 2026-07-23T16:11:24Z

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ next-auth (4.0.0-beta.6 → 4.24.15) · Repo · Changelog

Security Advisories 🚨

🚨 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.

🚨 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: 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.

🚨 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

🚨 next-auth before v4.10.2 and v3.29.9 leaks excessive information into log

Impact

An information disclosure vulnerability in next-auth before v4.10.2 and v3.29.9 allows an attacker with log access privilege to obtain excessive information such as an identity provider's secret in the log (which is thrown during OAuth error handling) and use it to leverage further attacks on the system, like impersonating the client to ask for extensive permissions.

Patches

We patched this vulnerability in v4.10.2 and v3.29.9 by moving the log for provider information to the debug level. In addition, we added a warning for having the debug: true option turned on in production and documented it here.

You have enabled the debug option. It is meant for development only, to help you catch issues in your authentication flow and you should consider removing this option when deploying to production. One way of only allowing debugging while not in production is to set debug: process.env.NODE_ENV !== "production", so you can commit this without needing to change the value.

If you want to log debug messages during production anyway, we recommend setting the logger option with proper sanitization of potentially sensitive user information.

To upgrade:
npm i next-auth@latest
# or
yarn add next-auth@latest
# or
pnpm add next-auth@latest
(This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3. This is not recommended. v3 is unmaintained.)

Workarounds

If for some reason you cannot upgrade, you can user the logger configuration option by sanitizing the logs:
// Example
import log from "your-logging-service"
export const authOptions: NextAuthOptions = {
  debug: process.env.NODE_ENV !== "production",
  logger: {
    error: (code, metadata) => {
      if (!(metadata instanceof Error) &&  metadata.provider) {
        // redact the provider secret here
        delete metadata.provider
        log.error(code, metadata)
      } else {
        log.error(code, metadata)
      }
    }
  },
}
References

Related documentation:

https://next-auth.js.org/warnings#debug_enabled

https://next-auth.js.org/configuration/options#logger

https://next-auth.js.org/getting-started/upgrade-v4

For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

Timeline

The issue was reported 18th of July, a response was sent out in less than 20 minutes and after identifying the issue a patch was published within a week.

🚨 NextAuth.js before 4.10.3 and 3.29.10 sending verification requests (magic link) to unwanted emails

Impact

next-auth users who are using the EmailProvider either in versions before 4.10.3 or 3.29.10 are affected.

If an attacker could forge a request that sent a comma-separated list of emails (eg.: attacker@attacker.com,victim@victim.com) to the sign-in endpoint, NextAuth.js would send emails to both the attacker and the victim's e-mail addresses. The attacker could then login as a newly created user with the email being attacker@attacker.com,victim@victim.com. This means that basic authorization like email.endsWith("@victim.com") in the signIn callback would fail to communicate a threat to the developer and would let the attacker bypass authorization, even with an @attacker.com address.

Patches

We patched this vulnerability in v4.10.3 and v3.29.10 by normalizing the email value that is sent to the sign-in endpoint before accessing it anywhere else. We also added a normalizeIdentifier callback on the EmailProvider configuration, where you can further tweak your requirements for what your system considers a valid e-mail address. (E.g.: strict RFC2821 compliance)

To upgrade, run one of the following:
npm i next-auth@latest
yarn add next-auth@latest
pnpm add next-auth@latest
(This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3. This is not recommended. v3 is unmaintained.)

Workarounds

If for some reason you cannot upgrade, you can normalize the incoming request like the following, using Advanced Initialization:
// pages/api/auth/[...nextauth].ts
function normalize(identifier) {

// Get the first two elements only,

// separated by @ from user input.

let [local, domain] = identifier.toLowerCase().trim().split("@")

// The part before "@" can contain a ","

// but we remove it on the domain part

domain = domain.split(",")[0]

return ${local}@${domain}

}
export default async function handler(req, res) {

if (req.body.email) req.body.email = normalize(req.body.email)

return await NextAuth(req, res, {/* your options */ })

}
References

EmailProvider: https://next-auth.js.org/providers/email

Normalize the email address: https://next-auth.js.org/providers/email#normalizing-the-email-address

Email syntax: https://en.wikipedia.org/wiki/Email_address#Local-part

signIn callback: https://next-auth.js.org/configuration/callbacks#sign-in-callback

Advanced Initialization: https://next-auth.js.org/configuration/initialization#advanced-initialization

nodemailer address: https://nodemailer.com/message/addresses

For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

Timeline

The issue was reported 26th of July, a response was sent out in less than 1 hour and after identifying the issue a patch was published within 5 working days.

Acknowledgments

We would like to thank Socket for disclosing this vulnerability in a responsible manner and following up until it got published.

🚨 Improper handling of email input

Impact

An attacker can pass a compromised input to the e-mail signin endpoint that contains some malicious HTML, tricking the e-mail server to send it to the user, so they can perform a phishing attack. Eg.: balazs@email.com, <a href="http://attacker.com">Before signing in, claim your money!</a>. This was previously sent to balazs@email.com, and the content of the email containing a link to the attacker's site was rendered in the HTML. This has been remedied in the following releases, by simply not rendering that e-mail in the HTML, since it should be obvious to the receiver what e-mail they used:

next-auth v3 users before version 3.29.8 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide)

next-auth v4 users before version 4.8.0 are impacted.

Patches

We've released patches for this vulnerability in:

v3 - 3.29.8

v4 - 4.9.0

You can do:
npm i next-auth@latest
# or
yarn add next-auth@latest
#
pnpm add next-auth@latest
(This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3. This is not recommended.)

Workarounds

If for some reason you cannot upgrade, the workaround requires you to sanitize the email parameter that is passed to sendVerificationRequest and rendered in the HTML. If you haven't created a custom sendVerificationRequest, you only need to upgrade. Otherwise, make sure to either exclude email from the HTML body or efficiently sanitize it. Check out https://next-auth.js.org/providers/email#customizing-emails

References

Related documentation:

https://next-auth.js.org/providers/email#customizing-emails

https://next-auth.js.org/getting-started/upgrade-v4

A test case has been added so this kind of issue will be checked before publishing. See: https://github.com/nextauthjs/next-auth/blob/cd6ccfde898037290ae949d500ace8a378376cd8/packages/next-auth/tests/email.test.ts

For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

Timeline

The issue was reported 2022 June 29th, a response was sent out to the reporter in less than 1 hour, and after identifying the issue a patch was published within 4 working days.

🚨 Improper Handling of `callbackUrl` parameter in next-auth

Impact

An attacker can send a request to an app using NextAuth.js with an invalid callbackUrl query parameter, which internally we convert to a URL object. The URL instantiation would fail due to a malformed URL being passed into the constructor, causing it to throw an unhandled error which led to our API route handler timing out and logging in to fail. This has been remedied in the following releases:

next-auth v3 users before version 3.29.5 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide)

next-auth v4 users before version 4.5.0 are impacted.

Patches

We've released patches for this vulnerability in:

v3 - 3.29.5

v4 - 4.5.0

You can do:
npm i next-auth@latest
or
yarn add next-auth@latest
or
pnpm add next-auth@latest
(This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3. This is not recommended.)

Workarounds

If for some reason you cannot upgrade, the workaround requires you to rely on Advanced Initialization. Here is an example:

Before:
// pages/api/auth/[...nextauth].js
import NextAuth from "next-auth"
export default NextAuth(/* your config */)
After:
// pages/api/auth/[...nextauth].js
import NextAuth from "next-auth"
function isValidHttpUrl(url) {

try {

return /^https?:/.test(url).protocol

} catch {

return false;

}

}
export default async function handler(req, res) {

if (

req.query.callbackUrl &&

!isValidHttpUrl(req.query.callbackUrl)

) {

return res.status(500).send('');

}
return await NextAuth(req, res, /* your config */)

}
References

This vulnerability was discovered not long after GHSA-q2mx-j4x2-2h74 was published and is very similar in nature.

Related documentation:

https://next-auth.js.org/getting-started/client#specifying-a-callbackurl

https://next-auth.js.org/configuration/callbacks#redirect-callback

A test case has been added so this kind of issue will be checked before publishing. See: e498483

For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

Timeline

The issue was reported 2022 June 10th, a response was sent out to the reporter in less than 2 hours, and a patch was published within 3 hours.

🚨 URL Redirection to Untrusted Site ('Open Redirect') in next-auth

Impact

We found that this vulnerability is present when the developer is implementing an OAuth 1 provider (by extension, it means Twitter, which is the only built-in provider using OAuth 1), but upgrading is still recommended.

next-auth v3 users before version 3.29.3 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our migration guide)

next-auth v4 users before version 4.3.3 are impacted.

Patches

We've released patches for this vulnerability in:

v3 - 3.29.3

v4 - 4.3.3

You can do:
npm i next-auth@latest
or
yarn add next-auth@latest
or
pnpm add next-auth@latest
(This will update to the latest v4 version, but you can change latest to 3 if you want to stay on v3.)

Workarounds

If you are not able to upgrade for any reason, you can add the following configuration to your callbacks option:
// async redirect(url, baseUrl) { // v3
async redirect({ url, baseUrl }) { // v4
    // Allows relative callback URLs
    if (url.startsWith("/")) return `${baseUrl}${url}`
    // Allows callback URLs on the same origin
    else if (new URL(url).origin === baseUrl) return url
    return baseUrl
}
References

This vulnerability was discovered right after GHSA-f9wg-5f46-cjmw was published and is very similar in nature.

Read more about the callbacks.redirect option in the documentation: https://next-auth.js.org/configuration/callbacks#redirect-callback

For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

Timeline

The issue was reported 2022 April 20th, a response was sent out to the reporter 8 minutes after, and a patch was produced within a few days.

🚨 NextAuth.js default redirect callback vulnerable to open redirects

next-auth v3 users before version 3.29.2 are impacted. (We recommend upgrading to v4 in most cases. See our migration guide).next-auth v4 users before version 4.3.2 are impacted. Upgrading to 3.29.2 or 4.3.2 will patch this vulnerability. If you are not able to upgrade for any reason, you can add a configuration to your callbacks option:
// async redirect(url, baseUrl) { // v3
async redirect({ url, baseUrl }) { // v4
    // Allows relative callback URLs
    if (url.startsWith("/")) return new URL(url, baseUrl).toString()
    // Allows callback URLs on the same origin
    else if (new URL(url).origin === baseUrl) return url
    return baseUrl
}
If you already have a redirect callback, make sure that you match the incoming url origin against the baseUrl.

🚨 NextAuth.js default redirect callback vulnerable to open redirects

next-auth v3 users before version 3.29.2 are impacted. (We recommend upgrading to v4 in most cases. See our migration guide).next-auth v4 users before version 4.3.2 are impacted. Upgrading to 3.29.2 or 4.3.2 will patch this vulnerability. If you are not able to upgrade for any reason, you can add a configuration to your callbacks option:
// async redirect(url, baseUrl) { // v3
async redirect({ url, baseUrl }) { // v4
    // Allows relative callback URLs
    if (url.startsWith("/")) return new URL(url, baseUrl).toString()
    // Allows callback URLs on the same origin
    else if (new URL(url).origin === baseUrl) return url
    return baseUrl
}
If you already have a redirect callback, make sure that you match the incoming url origin against the baseUrl.

Release Notes

4.2.1

More info than we can show here.

4.2.0

More info than we can show here.

4.1.2

More info than we can show here.

4.1.1

More info than we can show here.

4.1.0

More info than we can show here.

4.0.6

More info than we can show here.

4.0.5

More info than we can show here.

4.0.4

More info than we can show here.

4.0.3

More info than we can show here.

4.0.2

More info than we can show here.

4.0.1

More info than we can show here.

4.0.0

More info than we can show here.

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

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)

changeset-bot · 2026-07-23T16:11:29Z

⚠️ No Changeset found

Latest commit: 8015c32

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

guardrails · 2026-07-23T16:11:50Z

⚠️ We detected 57 security issues in this pull request:

Vulnerable Libraries (57)

Severity	Details
N/A	pkg:npm/ajv@6.12.6 (t) upgrade to: 8.18.0
N/A	pkg:npm/ajv@8.6.3 (t) upgrade to: 8.18.0
Medium	pkg:npm/bn.js@4.12.0 (t) upgrade to: 5.2.3
Medium	pkg:npm/bn.js@5.2.0 (t) upgrade to: 5.2.3
Medium	pkg:npm/brace-expansion@1.1.11 (t) upgrade to: 5.0.5
High	pkg:npm/braces@3.0.2 (t) upgrade to: 3.0.3
High	pkg:npm/browserify-sign@4.2.1 (t) upgrade to: 4.2.2
Critical	pkg:npm/cipher-base@1.0.4 (t) upgrade to: 1.0.5
Medium	pkg:npm/cookiejar@2.1.3 (t) upgrade to: 2.1.4
High	pkg:npm/cross-spawn@6.0.5 (t) upgrade to: 7.0.5
High	pkg:npm/cross-spawn@7.0.3 (t) upgrade to: 7.0.5
High	pkg:npm/debug@2.6.9 (t) upgrade to: 3.1.0
High	pkg:npm/defu@5.0.0 (t) upgrade to: 6.1.5
N/A	pkg:npm/diff@4.0.2 (t) upgrade to: 4.0.4,8.0.3,5.2.2
N/A	pkg:npm/elliptic@6.5.4 (t) upgrade to: 6.6.1
Medium	pkg:npm/eslint@7.32.0 (t) upgrade to: 9.26.0
Critical	pkg:npm/flatted@3.2.2 (t) upgrade to: 3.4.2
High	pkg:npm/form-data@3.0.1 (t) upgrade to: 4.0.6,2.5.6,3.0.5
Critical	pkg:npm/formidable@1.2.2 (t) upgrade to: 3.2.4
Medium	pkg:npm/h3@0.2.12 (t) upgrade to: 2.0.1-rc.15,1.15.6
Critical	pkg:npm/ipx@0.7.2 (t) upgrade to: 1.3.2,2.1.1,3.1.1
High	pkg:npm/js-yaml@3.14.1 (t) upgrade to: 3.15.0,4.3.0
High	pkg:npm/json5@1.0.1 (t) upgrade to: 2.2.2
High	pkg:npm/json5@2.2.0 (t) upgrade to: 2.2.2
High	pkg:npm/loader-utils@1.2.3 (t) upgrade to: 1.4.2,2.0.4,3.2.1
High	pkg:npm/lodash@4.17.21 (t) upgrade to: 4.18.0
Medium	pkg:npm/micromatch@4.0.4 (t) - no patch available
High	pkg:npm/minimatch@3.0.4 (t) upgrade to: 3.0.5
Critical	pkg:npm/minimist@1.2.5 (t) upgrade to: 1.2.6
N/A	pkg:npm/nanoid@3.1.30 (t) upgrade to: 5.0.9,3.3.8
Critical	pkg:npm/next@12.0.5 (t) upgrade to: 14.2.25,15.2.3,12.3.5,13.5.9
High	pkg:npm/node-fetch@2.6.1 (t) upgrade to: 3.1.1,2.6.7
High	pkg:npm/node-fetch@2.6.6 (t) upgrade to: 3.1.1,2.6.7
High	pkg:npm/node-forge@0.10.0 (t) upgrade to: 1.4.0
N/A	pkg:npm/pbkdf2@3.1.2 (t) upgrade to: 3.1.3
Medium	pkg:npm/picomatch@2.3.0 (t) upgrade to: 4.0.4,3.0.2,2.3.2
High	pkg:npm/postcss@8.2.15 (t) upgrade to: 8.5.12
High	pkg:npm/postcss@8.3.11 (t) upgrade to: 8.5.12
Low	pkg:npm/qs@6.10.1 (t) upgrade to: 6.14.2
Medium	pkg:npm/semver@5.7.1 (t) upgrade to: 7.5.2
Medium	pkg:npm/semver@6.3.0 (t) upgrade to: 7.5.2
Medium	pkg:npm/semver@7.3.5 (t) upgrade to: 7.5.2
Medium	pkg:npm/serialize-javascript@6.0.0 (t) upgrade to: 7.0.5
Critical	pkg:npm/sha.js@2.4.11 (t) upgrade to: 2.4.12
N/A	pkg:npm/sharp@0.28.3 (t) upgrade to: 0.35.0
High	pkg:npm/shell-quote@1.7.3 (t) upgrade to: 1.8.4
High	pkg:npm/simple-get@3.1.0 (t) upgrade to: 3.1.1,2.8.2,4.0.1
N/A	pkg:npm/tar-fs@2.1.1 (t) upgrade to: 3.0.9,1.16.5,2.1.3
High	pkg:npm/terser@5.9.0 (t) upgrade to: 5.14.2,4.8.1
High	pkg:npm/tmp@0.2.1 (t) upgrade to: 0.2.6
Medium	pkg:npm/tough-cookie@4.0.0 (t) upgrade to: 4.1.3
N/A	pkg:npm/uuid@11.1.1 (t) upgrade to: 14.0.0
Low	pkg:npm/webpack@5.62.1 (t) upgrade to: 5.104.0
Medium	pkg:npm/word-wrap@1.2.3 (t) - no patch available
High	pkg:npm/ws@7.5.5 (t) upgrade to: 7.5.10,8.17.1,5.2.4,6.2.3
Medium	pkg:npm/ws@8.2.3 (t) upgrade to: 8.20.1
Medium	pkg:npm/yaml@1.10.2 (t) upgrade to: 2.8.3,1.10.3

More info on how to fix Vulnerable Libraries in JavaScript.

👉 Go to the dashboard for detailed results.

📥 Happy? Share your feedback with us.

socket-security · 2026-07-23T16:12:01Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	next-auth@4.0.0-beta.6 ⏵ 4.24.15	^-5	⁺²⁰	⁺¹	⁺³

View full report

mergify · 2026-07-23T16:12:22Z

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

Queue this pull request

Update next-auth to version 4.24.15

8015c32

depfu Bot added the depfu label Jul 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

🚨 [security] Update next-auth 4.0.0-beta.6 → 4.24.15 (minor) - #301

🚨 [security] Update next-auth 4.0.0-beta.6 → 4.24.15 (minor)#301
depfu[bot] wants to merge 1 commit into
mainfrom
depfu/update/yarn/next-auth-4.24.15

depfu Bot commented Jul 23, 2026

Uh oh!

changeset-bot Bot commented Jul 23, 2026

Uh oh!

guardrails Bot commented Jul 23, 2026

Uh oh!

socket-security Bot commented Jul 23, 2026

Uh oh!

mergify Bot commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

depfu Bot commented Jul 23, 2026

What changed?

✳️ next-auth (4.0.0-beta.6 → 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

Impact

Patches

Workarounds

References

For more information

Timeline

Impact

Patches

Workarounds

References

For more information

Timeline

Acknowledgments

Impact

Patches

Workarounds

References

For more information

Timeline

Impact

Patches

Workarounds

References

For more information

Timeline

Impact

Patches

Workarounds

References

For more information

Timeline

Uh oh!

changeset-bot Bot commented Jul 23, 2026

⚠️ No Changeset found

Uh oh!

guardrails Bot commented Jul 23, 2026

Uh oh!

socket-security Bot commented Jul 23, 2026

Uh oh!

mergify Bot commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants