Nodemailer IDN allow-list bypass can redirect email to attacker-controlled domains

Nodemailer before 9.1.0 fails to apply UTS-46 normalization when encoding international domain names, causing the domain resolver to compute a different Punycode A-label than standards-compliant parsers. Attackers can craft recipient addresses with invisible characters or compatibility mappings that pass domain allow-list checks but are delivered to attacker-controlled domains via SMTP.

• nodemailer with semver >= 0 and < 9.1.0 is marked affected in the normalized record.
• The developer advisory identifies releases < 9.1.0 as affected and 9.1.0 as patched.
• The record also contains default_status: unaffected, while explicitly identifying the version range above as affected.
• The supplied evidence does not establish the status of parallel release branches or releases after the patched release beyond the boundaries stated directly.

Nodemailer processes the recipient domain in _normalizeAddress within lib/mime-node/index.js. In affected releases, the domain is lowercased and then encoded with the bundled RFC 3492 Punycode codec, without the full UTS-46 mapping and normalization that should occur before Punycode generation.

1. An application may validate the recipient domain with a UTS-46-conformant parser such as url.domainToASCII, new URL(), a browser-side parser, or an IDN library.
2. An attacker supplies an address containing an ignored or mapped character, such as an invisible character or compatibility character. The validator can see a trusted domain while Nodemailer generates a different Punycode A-label.
3. Nodemailer uses its resulting domain in the SMTP envelope RCPT TO and in address headers, so the trust decision and the actual delivery destination can disagree.

Exploitation requires an application to accept attacker-influenced recipient input, make an allow-list, block-list, or same-domain decision with a different parser, and then rely on Nodemailer for delivery. The record characterizes the issue as network reachable, requiring no privileges and no user interaction, but with high attack complexity. Whether a particular resulting A-label can be registered in the target TLD, and the practical impact, remain deployment-dependent.

The flaw can be triggered remotely through recipient-address data when an application accepts attacker-controlled input and validates the domain with a parser that interprets it differently from Nodemailer.

• The normalized record states that authentication is not required.
• The normalized record states that user interaction is not required.
• Complexity is high because the attacker must create a parser discrepancy and reach an email-sending flow that makes a domain-based trust decision.
• The record marks a public exploit as available; the developer advisory includes a proof of concept showing that an allow-list can accept one domain while the SMTP envelope uses a different A-label.
• Active exploitation in the wild is not established by the supplied evidence.

The technical outcome is an interpretation conflict between the parser used to decide which domain is trusted and the Nodemailer code that creates the SMTP recipient. An address that the application treats as belonging to a trusted domain can appear in the SMTP envelope under a different A-label, sending the message to an unintended destination.

• The primary effect is potential loss of email confidentiality and corruption of the recipient-routing decision.
• The supplied evidence does not describe a direct code-execution or privilege-acquisition path; the risk depends on the content the application sends and the attacker's ability to influence the address.
• Affected workflows can include domain confirmation, domain-gated registration, notification routing, and delivery restricted to a tenant or corporate domain.
• Some A-labels created from special characters may not be registrable in the target TLD, but the mismatch between the approved domain and the delivered domain remains a security concern.

• Email intended for a trusted domain can be delivered to another domain controlled by an attacker, potentially exposing message content, links, or information sent by email.
• Allow-list, block-list, and same-corporate-domain controls can approve the wrong recipient domain.
• A confirmation or logging flow may display the trusted normalized domain while the SMTP envelope contains a different destination.
• Domain-gated features such as employee-only registration, tenant-limited delivery, or notification routing can be misdirected when they accept attacker-influenced recipient addresses.
• The practical impact depends on the data sent by the application and whether it makes a domain trust decision before invoking Nodemailer.

1. Upgrade nodemailer to exactly 9.1.0, then rebuild the dependency tree and verify that the deployed artifact contains the intended release.
2. Review every application using domain allow-lists, same-domain checks, tenant routing, or domain confirmation before calling Nodemailer. Check lockfiles and packaged dependencies in containers and deployment artifacts.
3. If an upgrade is not yet possible, apply UTS-46 mapping before or during domain encoding, and use the same normalization rules for validation and delivery. The advisory suggests matching url.domainToASCII and url.domainToUnicode behavior, but warns that these are WHATWG host parsers rather than pure IDNA mappers.
4. Do not pass URL-syntax-bearing input to url.domainToASCII without validation. Handle or reject characters such as /, \\, ?, #, %, and control characters before invoking the mapper so that it cannot introduce a different interpretation.
5. Consider rejecting a domain when the value produced by the current codec differs from the value after UTS-46 mapping. Test ignored characters, compatibility characters, Unicode normalization, and invalid-domain cases before re-enabling the sending flow.

1. Inventory applications and lockfiles that use Nodemailer, then identify deployments in the affected release branch.
2. Search for allow-list, block-list, same corporate domain, tenant, or routing decisions based on a recipient domain before the application calls Nodemailer. Prioritize uses of new URL(), url.domainToASCII, browser-side checks, and IDN libraries.
3. Review the dependency and code path to determine whether address normalization passes through _normalizeAddress in lib/mime-node/index.js and whether SMTP delivery uses a Nodemailer-generated RCPT TO value.
4. In a controlled test environment, compare the domain accepted by validation with the A-label appearing in the SMTP envelope for addresses containing invisible characters, compatibility characters, or Unicode requiring UTS-46 mapping. Do not use sensitive data in testing.
5. Compare application validation records with SMTP telemetry to identify cases where the approved domain differs from the domain in RCPT TO. This is precautionary monitoring, not a confirmed IOC; absence of a mismatch does not prove that the deployment is safe.