CVE-2026-110870: 
Grafana Analyse et atténuation des vulnérabilités

CVE-2026-110870 is an improper input validation vulnerability in Nodemailer's address parser that fails to strip RFC 5322 comments embedded inside angle-bracket addresses (e.g., Name <user@domain.com(comment)>). It affects Nodemailer versions 3.0.0 through 10.0.12 (fixed in 10.0.13) and was disclosed on October 14–15, 2026. The flaw allows illegal characters to reach envelope.to and the SMTP RCPT TO command, causing delivery failures or domain allow-list bypasses. It carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory GHSA-g73g-hqqh-jr95, Red Hat Bugzilla).

The root cause lies in the Nodemailer tokenizer's single-slot operatorExpecting state variable in src/addressparser/index.ts (CWE-20: Improper Input Validation; CWE-791: Incomplete Filtering of Special Elements). When the tokenizer encounters a < character opening an angle-bracket address, it sets operatorExpecting to >, which prevents any subsequent character — including ( — from being recognized as an operator. As a result, RFC 5322 comment content inside angle brackets is never tokenized as a comment, never stripped, and passes verbatim into the parsed address value. The existing safety net function _recoverAddrSpec() also fails to catch this case because it requires whitespace in the address string to proceed, and comment-injected addresses like user@good-corp.com(x)evil.com contain none. This is a distinct code path from three previously patched address-parser advisories (GHSA-cc9r-2j5m-2m83, GHSA-g57g-f23g-4646, GHSA-prgh-xp8r-p3m5), none of which touch the tokenizer's operator stack logic (GitHub Advisory GHSA-g73g-hqqh-jr95).

Successful exploitation causes two concrete outcomes: (1) delivery failure — a conformant SMTP server (e.g., aiosmtpd) rejects the malformed RCPT TO value containing illegal characters ( and ), silently dropping the message for what the application believed was a valid recipient; and (2) domain allow-list bypass — different email parsers interpret the same malformed address string differently, so an application validating the recipient domain with Python's email.policy.default (which reads the domain as good-corp.com) may approve a value that Nodemailer then sends as user@good-corp.com(x)evil.com, potentially routing mail to an attacker-controlled domain depending on the receiving MTA's comment handling. All address fields processed through MimeNode._parseAddresses() — including to, cc, bcc, from, replyTo, and envelope — are equally affected (GitHub Advisory GHSA-g73g-hqqh-jr95).

No public proof-of-concept exploit code or exploit kits have been identified, and there is no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires no authentication, no user interaction, and no special privileges — an attacker only needs the ability to supply a crafted recipient address to an application using a vulnerable Nodemailer version (GitHub Advisory GHSA-g73g-hqqh-jr95, Red Hat Bugzilla).

1. Identify target application: Locate a web application or service that uses Nodemailer (versions 3.0.0–10.0.12) to send email and accepts user-controlled recipient addresses (e.g., contact forms, notification settings, invitation flows).
2. Craft malicious recipient address: Construct an email address embedding an RFC 5322 comment inside angle brackets, such as Legit User <user@good-corp.com(x)evil.com>, where (x) is the injected comment and evil.com is an attacker-controlled domain.
3. Submit the crafted address: Supply the malicious recipient string to the application's email-sending functionality. If the application validates the domain using a parser like Python's email.policy.default without inspecting .defects, it will read the domain as good-corp.com and pass validation.
4. Observe Nodemailer behavior: Nodemailer's address parser fails to strip the comment, producing envelope.to: ['user@good-corp.com(x)evil.com'] and writing this value raw into the SMTP RCPT TO command.
5. Achieve objective: Depending on the receiving MTA — a strict server rejects the message (causing delivery failure/DoS for the intended recipient), while a lenient or attacker-controlled MTA may interpret the comment differently, potentially delivering the email to an unintended domain, bypassing domain allow-list controls (GitHub Advisory GHSA-g73g-hqqh-jr95).

• Application Logs: Email sending errors referencing EENVELOPE, 501 Syntax: RCPT TO, or all recipients were rejected for addresses containing parentheses in the domain portion.
• Email Headers/Envelope: Outbound To: headers or logged envelope.to values containing parentheses within the domain segment (e.g., user@domain.com(text)otherdomain.com).
• SMTP Transaction Logs: RCPT TO commands on the wire containing parenthesis characters ( or ) within the recipient address, which are illegal per RFC 5321.
• Application Input: User-supplied recipient fields containing angle-bracket addresses with parenthesized content inside the brackets, such as Name <localpart@domain(comment)otherdomain> (GitHub Advisory GHSA-g73g-hqqh-jr95).

Upgrade Nodemailer to version 10.0.13 or later, which contains the fix for this vulnerability. No configuration-based workaround is available; the fix requires a code-level change to the tokenizer's operator stack logic in src/addressparser/index.ts. As a defense-in-depth measure, applications should independently validate all recipient addresses before passing them to Nodemailer, rejecting any address containing RFC 5322 special characters such as ( or ) in the domain portion (GitHub Advisory GHSA-g73g-hqqh-jr95, Red Hat Bugzilla).

The vulnerability was reported by researcher StarPlatinu and published by Nodemailer maintainer andris9 via GitHub Security Advisories on September 30, 2026. The advisory provides an unusually detailed root cause analysis, including a comparison table showing how different parsers interpret the same malformed address string — mirroring the methodology used in the related advisory GHSA-cc9r-2j5m-2m83. Red Hat tracked the issue via Bugzilla (Bug 2552969) with medium priority, and VulnCheck independently published an advisory. No significant broader media coverage or social media discussion has been identified beyond standard vulnerability database aggregation (GitHub Advisory GHSA-g73g-hqqh-jr95, Red Hat Bugzilla).