GHSA-5jpx-9hw9-2fx4

What it actually does

The flaw can cause NextAuth.js email authentication messages, such as verification or magic-link emails, to be delivered to an unintended recipient. At a technical level, this creates an information disclosure condition because email contents intended for one user may be exposed to another address. In deployments where email links are used for passwordless sign-in or account verification, exposure of those links may also create a path to unauthorized account access if the link remains valid and is used before expiration.

Why it matters to the business

Organizations using affected NextAuth.js versions may inadvertently send sensitive authentication emails to the wrong recipient, creating privacy, compliance, and account-trust risks. The operational impact is highest for applications that rely on email magic links for login, onboarding, passwordless authentication, or account recovery, because a misdelivered message may expose an authentication link or user-identifying information. This issue is not listed in CISA KEV and has no reported exploit maturity in the provided data, but it has been public for 285 days, so affected applications should be remediated during normal security patch cycles or sooner for internet-facing authentication flows.

How an attack unfolds

An attacker would target an application using a vulnerable NextAuth.js email provider flow. They would interact with the sign-in, verification, or email-based authentication endpoint and attempt to trigger conditions that cause the application to generate an email for one identity while delivering it to another address. If the attacker can cause or receive a misdelivered message, they may learn private account information contained in the email. If the message contains a valid magic login or verification link, the attacker may attempt to redeem that link before it expires, potentially gaining access to the affected account depending on how the application validates tokens, binds tokens to recipients, and handles active sessions.

How to fix it

Upgrade affected NextAuth.js installations to a fixed release: next-auth 4.24.12 or later for the 4.x line, or next-auth 5.0.0-beta.30 or later for the 5.x beta line. For Red Hat Certificate System 7.2 packaging, update rhpki-common to 0:7.2.0-11 or later through the vendor-supported channel. After upgrading, restart application processes so the patched package is loaded. Review any custom Email provider configuration, custom sendVerificationRequest logic, adapter code, or email normalization logic to ensure the recipient address used for token generation and message delivery is consistent and cannot be attacker-controlled independently. Consider invalidating outstanding email verification tokens and expiring active sessions for high-risk applications that rely on magic links.

How to confirm the fix worked

Confirm exposure by checking dependency manifests and installed package versions. For npm-based applications, use commands such as npm ls next-auth, pnpm why next-auth, yarn why next-auth, and inspect package-lock.json, pnpm-lock.yaml, or yarn.lock for next-auth versions older than 4.24.12 in the 4.x line or older than 5.0.0-beta.30 in the beta line. For Red Hat systems, validate the installed package with rpm -q rhpki-common and confirm it is 0:7.2.0-11 or later. Confirm the fix by exercising the email authentication flow in a test environment and verifying that the requested identity, generated token, and delivered recipient address remain consistent across logs and email provider events. Also verify that old containers, serverless bundles, build artifacts, and cached deployments are not still shipping a vulnerable next-auth version.

Typical attack path

1. Identify an application using NextAuth.js email authentication or verification flows.
2. Trigger the email sign-in, verification, onboarding, or recovery process with crafted or manipulated email-related input.
3. Cause or wait for the application to send a verification or magic-link email to an unintended recipient.
4. Inspect the misdelivered email for user-identifying information, verification tokens, or login links.
5. If a valid authentication link is exposed, attempt to redeem it before expiration.
6. Use any resulting session to access data or functionality available to the affected user.

How to detect it

There is no universal exploit string for this issue because exploitation depends on application-specific logging and email provider behavior. To assess possible prior exploitation, correlate application authentication logs, NextAuth.js logs, adapter/database audit logs for verification token creation and use, and outbound email provider logs from services such as SES, SendGrid, Mailgun, Postmark, SMTP relays, or mail transfer agents. Look for cases where the email address used to request a sign-in or verification action differs from the email recipient recorded by the mail provider, or where a verification token generated for one identity is redeemed by a different account, IP address, user agent, or geolocation shortly after delivery. Investigate repeated email sign-in attempts with unusual casing, Unicode, encoded characters, aliasing, plus-addressing, whitespace, comma-separated values, or header-like input. Review successful sign-ins immediately following failed or unusual email delivery events, especially where the recipient address does not match the authenticated user. Because the issue is an information disclosure flaw and not a conventional payload-based remote-code-execution vulnerability, absence of a known IOC does not prove absence of exploitation.

What your security team should do

• Prioritize patching applications that use NextAuth.js Email provider, passwordless login, account verification, or account recovery flows.
• Upgrade next-auth to 4.24.12 or later, or 5.0.0-beta.30 or later, and update rhpki-common to 0:7.2.0-11 or later where applicable.
• Inventory all applications and downstream services that bundle next-auth directly or transitively, including containers and serverless deployments.
• Review email authentication logs for mismatches between the identity requested, token generated, and recipient address delivered.
• Invalidate outstanding verification or magic-link tokens after patching if the application handles sensitive data or privileged accounts.
• Shorten magic-link token lifetime and ensure tokens are single-use, recipient-bound, and invalidated after use.
• Add regression tests for email authentication flows to ensure the generated authentication token can only be delivered to and redeemed by the intended address.