GHSA-r7g4-qg5f-qqm2

What it actually does

The flaw causes Nodemailer’s OAuth2 token-fetching path to improperly validate TLS certificates when contacting an OAuth2 token endpoint. If an attacker can intercept or redirect that outbound HTTPS connection, they may present an untrusted or fraudulent certificate that the vulnerable code accepts, allowing interception of OAuth2 client credentials, refresh tokens, authorization grants, or access tokens used for email authentication. The vulnerability affects nodemailer npm versions before 8.0.8 and is fixed in 8.0.8.

Why it matters to the business

Applications that use vulnerable Nodemailer versions with OAuth2-backed mail delivery could have email authentication credentials intercepted by an attacker with a network interception position. This can lead to unauthorized email sending, mailbox or account abuse depending on granted OAuth scopes, phishing from trusted application identities, exposure of sensitive email content, service disruption from revoked credentials, and reputational damage. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported exploit maturity, but it has been public for 55 days and should be remediated because successful exploitation can compromise long-lived OAuth refresh tokens.

How an attack unfolds

An attacker first obtains a position where they can observe or manipulate network traffic between an application using Nodemailer and the configured OAuth2 token endpoint, such as through a malicious proxy, compromised network device, rogue Wi-Fi, DNS manipulation, or another man-in-the-middle condition. When the application attempts to refresh or obtain an OAuth2 access token for sending mail, the attacker redirects or intercepts the HTTPS request and presents a fraudulent TLS certificate. Because the vulnerable Nodemailer token-fetching code does not correctly reject the invalid certificate, the OAuth2 request may be sent through the attacker-controlled channel. The attacker can then capture sensitive OAuth material such as client secrets, authorization codes, refresh tokens, or access tokens, and either proxy the request onward to avoid immediate failure or reuse the captured credentials later. With valid tokens or secrets, the attacker can send unauthorized email, impersonate the application’s mail identity, or access other OAuth-protected resources depending on the permissions granted to the compromised credentials.

How to fix it

Upgrade nodemailer to version 8.0.8 or later wherever it is used. For npm-based projects, update package manifests and lockfiles, then rebuild and redeploy affected applications. Verify transitive dependency usage with package manager tooling because Nodemailer may be included indirectly by higher-level mail libraries or application frameworks. If immediate upgrade is not possible, reduce risk by restricting outbound access from application workloads to only the expected OAuth2 token endpoints, enforcing trusted DNS and proxy paths, disabling untrusted TLS interception for token traffic, monitoring for unexpected OAuth token endpoint destinations, and rotating OAuth client secrets and refresh tokens if interception is suspected. After upgrade, revoke and reissue any OAuth credentials that may have traversed untrusted networks while the vulnerable version was in use.

How to confirm the fix worked

Confirm that all deployed application artifacts, containers, build outputs, and lockfiles resolve nodemailer to 8.0.8 or later. Useful checks include `npm ls nodemailer`, reviewing `package-lock.json`, `npm-shrinkwrap.json`, `pnpm-lock.yaml`, or `yarn.lock`, and inspecting container images or serverless bundles for bundled copies. Validate runtime behavior by confirming OAuth2 token requests fail when presented with an invalid, self-signed, expired, or hostname-mismatched certificate in a controlled test environment. Confirm outbound traffic from affected applications goes only to expected OAuth2 token endpoints over valid TLS. If credentials were rotated, verify that old refresh tokens, client secrets, and access tokens are no longer accepted by the identity provider.

Typical attack path

1. Identify an application or service using Nodemailer with OAuth2 authentication and a vulnerable nodemailer version before 8.0.8.
2. Gain a network interception or redirection position between the application and the OAuth2 token endpoint, such as via proxy compromise, DNS manipulation, rogue access point, or malicious network routing.
3. Wait for the application to request or refresh an OAuth2 access token for email delivery.
4. Present a fraudulent TLS certificate or intercept the TLS connection to the token endpoint.
5. Capture OAuth2 credentials, refresh tokens, authorization grants, or access tokens transmitted during the token request.
6. Optionally forward the request to the legitimate token endpoint to reduce operational symptoms and avoid detection.
7. Reuse the captured OAuth material to send mail, impersonate the application identity, or access other OAuth-authorized resources until the credentials are revoked or expired.

How to detect it

Because exploitation occurs during outbound OAuth2 token retrieval and may not leave a distinctive application error, focus on identity provider, mail provider, network, DNS, proxy, and dependency evidence. Review OAuth2 token endpoint logs for token requests from unexpected IP addresses, autonomous systems, countries, proxies, or infrastructure not associated with the application runtime. Look for unusual refresh-token use, repeated token grants, new client-secret usage patterns, failed and successful token exchanges close together, or token activity followed by unexpected email sending. Review mail provider audit logs for abnormal send volume, unauthorized recipients, suspicious subjects or attachments, new sending locations, or authentication events using the application’s OAuth client. Inspect proxy, firewall, TLS inspection, and DNS logs for application workloads connecting to unexpected token endpoint hostnames or IPs, certificate validation anomalies, DNS responses inconsistent with the identity provider, or traffic routed through unapproved proxies. Review host and container images for vulnerable nodemailer versions to establish exposure windows. If suspicious activity is found, preserve logs, revoke OAuth refresh tokens, rotate client secrets, and investigate downstream mail abuse. There are no universal file, process, registry, or network indicators unique to exploitation of this issue.

What your security team should do

• Prioritize upgrading all direct and transitive nodemailer installations to 8.0.8 or later.
• Inventory applications that use Nodemailer with OAuth2 authentication, especially internet-facing or high-volume mail-sending services.
• Review dependency lockfiles, container images, CI build artifacts, and deployed packages to ensure vulnerable versions are not still present after source updates.
• Rotate OAuth client secrets and refresh tokens for affected mail integrations if there is any possibility of prior network interception or untrusted proxying.
• Restrict egress from application workloads so OAuth2 token requests can only reach approved identity provider token endpoints.
• Review identity provider logs for unusual token requests, suspicious source IPs, impossible travel patterns, unexpected client usage, or abnormal refresh-token activity.
• Monitor mail provider logs for unauthorized sending, spikes in message volume, phishing-like content, new sender patterns, or authentication from unexpected locations.
• Add software composition analysis checks to CI/CD to block nodemailer versions earlier than 8.0.8.
• Document compensating controls for any application that cannot be upgraded immediately and set an explicit remediation deadline.