Description

Nodemailer versions 5.0.0 through 10.0.1 use a process-global DNS cache that is keyed only by the DNS host, while each cache entry also stores the caller-specific TLS servername. When two direct TLS/SMTPS transports (secure: true) resolve the same non-IP host with different tls.servername values, the first transport's servername is returned on the cache hit and overwrites the second transport's explicitly configured value, so Nodemailer sends the wrong SNI value and validates the peer certificate against the wrong identity. In multi-tenant services or SNI-routed SMTP gateways, an attacker who can prime the cache can cause a victim transport to connect to the attacker's TLS virtual host and accept the attacker's certificate even with rejectUnauthorized: true, disclosing the victim's SMTP credentials. Fixed in 10.0.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-26T14:16:55.143Z",
  "pubdate": "2026-09-26T14:16:55.143Z",
  "executiveSummary": "Nodemailer versions 5.0.0 through 10.0.1 are susceptible to a security vulnerability involving the mishandling of TLS SNI (Server Name Indication) due to an improper process-global DNS cache implementation.\nThe vulnerability occurs because the DNS cache is keyed exclusively by the hostname, ignoring the unique tls.servername configuration required for distinct TLS handshakes.\nWhen multiple SMTPS transports resolve the same host with differing SNI requirements, the initial configuration is cached and subsequently applied to all future connections for that host.\nThis behavior facilitates a cross-protocol or cross-tenant attack vector, allowing an attacker to intercept or divert SMTP traffic.\nBy priming the cache, an attacker can force a victim transport to connect to a malicious TLS virtual host. Even with rejectUnauthorized: true enabled, the library validates the peer certificate against the incorrect identity stored in the cache.\nThe primary risk implication is the potential disclosure of sensitive SMTP credentials and unauthorized communication interception, particularly in multi-tenant environments or systems relying on SNI-routed SMTP gateways.",
  "technicalDetails": "The vulnerability resides in the process-global DNS caching mechanism implemented in Nodemailer versions 5.0.0 through 10.0.1. The cache architecture uses the target hostname as the unique lookup key, failing to account for transport-specific TLS parameters.\nWhen a transport is configured with secure: true, Nodemailer performs a DNS lookup. If the result is already in the global cache, the library retrieves the cached TLS servername associated with the previous lookup for that hostname.\nThe root cause is the collision between the shared DNS cache and the caller-specific tls.servername property. In a scenario where Transport A and Transport B both target the same hostname but require different SNI identities, the cache hit from the first transport overwrites the secondary transport's configuration.\nThe attack flow proceeds as follows: 1. The attacker identifies a target host that is frequently accessed by a victim via Nodemailer. 2. The attacker triggers the victim's service to connect to an attacker-controlled server (or an SNI-routed gateway) that shares the target hostname. 3. The attacker's server initiates the first connection, populating the global cache with the attacker's expected SNI value. 4. When the legitimate victim transport attempts to connect, it retrieves the attacker-provided SNI configuration from the cache instead of its intended identity.\nBecause the library mistakenly believes the cached SNI value corresponds to the host, it performs the TLS handshake using the attacker's identity. If the attacker presents a certificate that satisfies the requirements for the poisoned SNI value, the victim transport will complete the connection.\nThe impact is significant as this circumvents the validation logic intended to ensure the peer certificate matches the server identity. Even if the victim explicitly configures rejectUnauthorized: true, the validation is performed against the poisoned identity rather than the intended target identity. This results in the client sending SMTP credentials over a connection established with an attacker-controlled endpoint.\nThis vulnerability is particularly dangerous in multi-tenant services where different users might share infrastructure or rely on centralized SMTP gateways that utilize SNI for routing traffic to specific backends. The attacker does not require elevated privileges on the victim's infrastructure, only the ability to cause the application to perform the initial lookup for the hostname."
}