Nodemailer EUVD-2026-81298

Exploitation requires the consuming application to (1) perform a domain allow-list, same-domain, or user-confirmation check on the recipient using a UTS-46/IDNA-conformant parser (e.g. Node's url.domainToASCII, WHATWG URL, or Python idna), AND (2) then rely on Nodemailer (<9.1.0) to actually deliver to that address. The attacker must be able to influence the recipient address and supply a domain containing a UTS-46-mapped or ignored code point (e.g. an invisible U+00AD SOFT HYPHEN, full-width characters, or compatibility mappings) that folds to the trusted domain in the validator but encodes to a different xn-- label in Nodemailer's bundled raw RFC-3492 codec. Limiting factors: the divergence only matters when validation and delivery use different parsers, so applications that do no domain allow-listing, or that re-check Nodemailer's normalized output, are not exposed; address literals ('[127.0.0.1]', '[IPv6:::1]') and non-hostnames fall through unchanged and are unaffected; high attack complexity (AC:H) reflects the need to know the validator's normalization behavior and register the resulting punycode domain.

This is a real but conditional risk, not a drop-everything emergency. The vendor CVSS 4.0 vector (8.3, AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N) accurately captures the shape: network-reachable and unauthenticated to trigger, but with high attack complexity (AC:H) and a present attack requirement (AT:P) because exploitation depends on a specific interaction between an application's IDN-aware validator and Nodemailer's non-conformant encoder. No EPSS score was supplied, the CVE is not in CISA KEV, and no standalone public exploit is referenced (the patch's regression tests demonstrate the mismatch but are proof-of-concept fixtures, not weaponized exploit code) - so the correct read is 'no public exploit identified at time of analysis.' The primary impact is confidentiality (VC:H): email intended for a trusted allow-listed domain is silently delivered to an attacker-registrable domain, leaking message contents. CWE-436 (Interpretation Conflict) is the correct root cause - two parsers disagree on the canonical domain. Note this is explicitly the same weakness class as CVE-2025-13033 but reached via IDN/Punycode rather than quoted local-parts, and the earlier 7.0.7 fix does NOT cover it. The key limiter, and the reason not to treat the raw 8.3 as widespread mass-exploitation risk, is that harm only materializes when the consuming application runs a UTS-46-aware allow-list/same-domain check and then hands the raw address to Nodemailer for delivery; applications without such a check, or that pass Nodemailer's already-normalized output back into their check, are not exposed.

An application restricts outbound mail to a corporate allow-list (e.g. 'company.com') and validates the recipient using a UTS-46-conformant parser such as Node's url.domainToASCII, which folds an invisible U+00AD SOFT HYPHEN in 'compa­ny.com' down to the trusted 'company.com' and approves it. It then passes the original address to Nodemailer, whose bundled raw RFC-3492 codec maps nothing and encodes the domain to a different label ('xn--company-pka.com'), delivering the message - and any sensitive content or reset link it contains - to a domain the attacker has registered. No visible homograph is needed, so neither an automated check nor a human confirming the displayed recipient would notice; no public exploit is identified but the patch's tests concretely demonstrate the encoding divergence.