CVE-2026-92597

Executive Summary

CVE-2026-92597 is an address-parsing logic flaw in the Nodemailer library (lib/addressparser) affecting versions >= 6.9.16 and < 9.1.0. When an RFC 5322 comment is closed immediately before a non-break character, the tokenizer concatenates the atoms surrounding the comment rather than treating the comment as folding whitespace that terminates the domain. As a result, an address such as user@good-corp.com(x)evil.com is parsed as the single domain good-corp.comevil.com (registrable domain comevil.com), which Nodemailer then uses for both the SMTP envelope (RCPT TO) and the emitted To:/From: headers. Systems that validate recipient domains with a conformant parser or a naive prefix/substring allow-list and then pass the raw address to Nodemailer may deliver mail to an attacker-controlled domain. The vulnerability is network-exploitable with high attack complexity (CVSS 6.5, C:H/I:L/A:N); no public PoC, exploit code, or Nuclei template is available, and the issue is not in CISA KEV.

Technical Analysis

The root cause is a divergence between two parties' interpretation of the same string, categorized as CWE-436 (Interpretation Conflict). RFC 5322 permits comments (parenthesized text) within address fields, and conformant parsers treat a comment as folding whitespace that terminates the domain token — so a conformant parser reads user@good-corp.com(x)evil.com as the domain good-corp.com. Nodemailer's lib/addressparser does not. Per the NVD description, when a comment is closed immediately before a non-break character, the tokenizer concatenates the atoms surrounding the comment instead of treating the comment as a terminator, producing the domain good-corp.comevil.com (registrable domain comevil.com).

Two trust boundaries are crossed:

1. Validation vs. consumption gap. The application validates the recipient using a strict RFC 5322 parser (without inspecting parse defects) or a naive prefix/substring allow-list. Both can be satisfied by good-corp.com... because the string begins with the allow-listed domain or contains it as a substring — yet the value handed to Nodemailer is the raw address, which Nodemailer re-parses differently.
2. Envelope vs. header consistency. Nodemailer applies the mis-parsed domain to both the SMTP envelope (RCPT TO) and the emitted To:/From: headers. The delivery target therefore matches the attacker's intended (attacker-registrable) domain, and the visible header does too, reducing the chance that downstream inspection catches the discrepancy.

The parser bug is a tokenizer state issue: comment handling does not emit the whitespace/terminator that separates domain atoms. This is a pure parsing/interpretation defect; it does not require memory corruption, injection, or authentication.

Key constraints and scope notes:

• The vulnerable range as stated is >= 6.9.16 and < 9.1.0; the fix is in 9.1.0. The metadata "Affected Versions" array was empty in the supplied data, so the descriptive range above is the authoritative statement available.
• The NVD description is the only technical source provided. No endpoints, functions beyond lib/addressparser, or parameters are named beyond those quoted here; no additional implementation detail is asserted.
• CVSS vector components (AV:N, AC:H, PR:N, UI:N, S:U, C:H, I:L, A:N) are consistent with a remotely triggerable parsing flaw that requires specific input construction (AC:H) and yields high confidentiality impact (mail delivered to attacker domain) with limited integrity impact.

Attack surface: any server-side Node.js application that (a) depends on an affected Nodemailer version and (b) processes user-supplied recipient or sender addresses — e.g., contact forms, notification/digest mailers, password-reset flows, invitation systems, or multi-tenant relay services — where the recipient is validated separately from how it is passed to Nodemailer. Mail submission (RCPT TO) and header emission are both affected.

What is not claimed: no CVSS alteration, no EPSS value (not yet scored by FIRST.org), no KEV listing, no public PoC/exploit, no Nuclei template, and no confirmed in-the-wild exploitation are asserted here.

Exploitation Scenarios

No public PoC is available; the chain below is inferred from the vulnerability class (interpretation conflict) and the NVD description.

1. Reconnaissance / target identification. The attacker identifies a service that sends mail using Nodemailer and accepts an attacker-influenced recipient address. Typical candidates are public contact/"email us" forms, registration or password-reset endpoints, invite features, and API endpoints that accept a to-style recipient. The attacker customizes the payload domain to defeat the target's validation method.

2. Triggering the flaw class. The attacker supplies a recipient string of the form user@<allowed-domain>(x)<attacker-domain> — e.g., user@good-corp.com(x)evil.com. If the application validates with a strict RFC 5322 parser that ignores parse defects, or with a naive prefix/substring allow-list, the value passes validation because it begins with (or contains) the allow-listed domain. The raw string is then handed to Nodemailer.

3. Payload/execution mechanism (class level). Nodemailer's lib/addressparser mis-parses the comment as described, concatenating atoms so the effective domain becomes <allowed-domain><attacker-domain> — concretely good-corp.comevil.com, whose registrable domain comevil.com the attacker can register. Nodemailer uses this mis-parsed domain for the SMTP envelope (RCPT TO) and the emitted To:/From: headers. The message is therefore addressed and delivered to the attacker-controlled domain. No code execution or memory corruption is involved; the "payload" is the crafted address string itself.

4. Post-exploitation impact. Because delivery goes to the attacker-controlled registrable domain, the attacker receives mail that the application intended for the legitimate domain. Depending on the application flow, this can capture notification content, registration/reset confirmation links, invites, or other sensitive messages — yielding the high confidentiality impact reflected in the CVSS vector. Header manipulation (To:/From:) may also facilitate spoofing or social-engineering of downstream readers. Integrity impact is limited (I:L) and availability is unaffected (A:N). The high attack complexity (AC:H) reflects the need to craft an address that simultaneously satisfies the target's validation and induces the parser mis-parse.

Impact Assessment

• Business impact: Mis-delivery of application email to an attacker-registrable domain. Where those messages contain secrets or security-relevant links (password-reset tokens, invitation links, PII, internal notifications), the effect is data disclosure to an attacker. From:/To: header manipulation can additionally undermine trust in outbound mail and enable phishing or social engineering against recipients.
• Affected systems: Server-side Node.js applications using affected Nodemailer versions that send user-influenced addresses. Mail infrastructure downstream (relays, filters) may faithfully deliver to the attacker's domain because both the envelope and headers agree.
• Blast radius: Bounded by the rate and content of mail the application sends to attacker-influenced recipients. Where the same validation-then-forward pattern is reused across many endpoints or tenants, the exposure scales accordingly.
• CVSS subscores: AV:N (remote), AC:H (specific crafted input required), PR:N (no privileges), UI:N (no user interaction), S:U (unchanged scope), C:H (mail content and links disclosed to attacker-controlled domain), I:L (limited, via address/header manipulation), A:N (no availability impact). Overall 6.5 (Medium).

Detection Guidance

Detection centers on the distinctive artifact of this flaw: an email address containing a parenthesized RFC 5322 comment immediately before a non-space character, with an additional domain-like value following the comment (e.g., @domain.tld(...)domain.tld). Because the envelope and headers are consistent, network and application-log correlation is required.

Sigma Rule

title: Nodemailer RFC5322 Comment Address Mis-Parse Attempt (CVE-2026-92597)
id: 7f3c2b1a-9259-4c1e-9a6d-0cve92597001
status: experimental
description: Detects recipient addresses containing an RFC 5322 comment immediately
  followed by a non-break character and an additional domain, characteristic of
  CVE-2026-92597 address-parser mis-parse in Nodemailer.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-92597
author: Threat Intelligence - valtersit.com
date: 2026/01/01
logsource:
  category: application
  product: nodejs
detection:
  selection_comment_domain:
    recipient_address|re: '@[A-Za-z0-9.-]+\([^)]*\)[A-Za-z0-9.-]+'
  selection_parser_error:
    message|contains:
      - 'addressparser'
      - 'Nodemailer'
      - 'Invalid recipient'
  condition: selection_comment_domain
falsepositives:
  - Legitimate RFC 5322 addresses that include a display comment after the domain,
    such as 'user@example.com (work)' - these have whitespace before the comment.
level: high
tags:
  - attack.t1190
  - cve.2026-92597

YARA Rule

rule CVE_2026_92597_Nodemailer_AddressParser_Comment_Bypass
{
    meta:
        author = "Threat Intelligence - valtersit.com"
        description = "Detects address strings exploiting CVE-2026-92597: an RFC 5322 comment closed immediately before a non-break character, concatenating surrounding domain atoms in Nodemailer"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-92597"
        cve = "CVE-2026-92597"
        date = "2026-01-01"

    strings:
        // address@domain immediately followed by (comment) with no whitespace,
        // then more domain-like characters - the concatenation-triggering pattern
        $pattern = /[A-Za-z0-9._%+-]+@[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)+\([^)\r\n]*\)[A-Za-z0-9.-]+/
        // Nodemailer address parser source signature (wrapped-up fixed code contains
        // the version string); useful for identifying deployed library versions
        $nodemailer = "nodemailer" ascii nocase
        $version = /9\.[01]\.[0-9]+/ ascii

    condition:
        $pattern and filesize < 1MB
}

Suricata IDS Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 25 (msg:"CVE-2026-92597 Nodemailer RFC5322 Comment Address Mis-Parse in SMTP RCPT TO"; flow:established,to_server; content:"RCPT TO:"; nocase; pcre:"/RCPT TO:\\s*<[^@\\s>]+@[A-Za-z0-9.-]+\\x28[^)\\r\\n]*\\x29[A-Za-z0-9.-]+/i"; reference:cve,2026-92597; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-92597; classtype:attempted-recon; sid:9259701; rev:1;)

Elastic Detection

sequence by host.id with maxspan=5m
  [ process where event.type == "start" and process.name in ("node", "nodejs") ]
  [ network where event.action == "connection_attempted" and
      (destination.port == 25 or destination.port == 587 or destination.port == 465) and
      process.name in ("node", "nodejs") ]
  [ file where event.category == "file" and
      wildcard(file.name, "*mail*log*") and
      wildcard(file.path, "*node_modules/nodemailer*") ]

Splunk SPL Query

index=app OR index=smtp OR index=mail
| eval addr = coalesce(recipient, rcpt_to, "to_address", "to")
| where match(addr, "@[A-Za-z0-9._-]+\([^)]*\)[A-Za-z0-9.-]+")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(addr) as suspicious_addresses
        values(src_ip) as sources
        values(user) as users by host
| where count > 0
| sort - count
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="nodemailer,cve_2026_92597,mail,">
  <rule id="925970" level="12">
    <decoded_as>json</decoded_as>
    <field name="recipient_address">\.\+\(\.\+\)\.\+</field>
    <description>CVE-2026-92597: Nodemailer address parser mis-parse - RFC 5322 comment concatenates domain atoms; possible malicious recipient address</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
  <rule id="925971" level="8">
    <decoded_as>json</decoded_as>
    <field name="log_message">addressparser|Nodemailer.*invalid.*recipient</field>
    <description>Nodemailer parser encountered malformed RFC 5322 address - potential CVE-2026-92597 exploitation attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED per tracked sources (no patch evidence from any tracked source; Vendor Fix and Workarounds fields are N/A in the supplied data).

1. Immediate mitigations (no code patch available from tracked sources):

   • Reject addresses that contain an RFC 5322 comment adjacent to non-whitespace domain characters. Specifically, refuse or normalize any address matching @<domain>(<comment>)<non-space> before validation and before submission to Nodemailer.
   • Do not rely on naive prefix/substring allow-lists. Validate against an exact-match allow-list of full compatible/complete address forms using a parser whose output is positively inspected (reject on any parse defect or deviation), not merely a parser that returns a technically-valid result.
   • Enforce a policy that the exact string validated is the exact string sent; centralize address handling so validation and sending consume the same normalized value.
   • As defense in depth, restrict outbound mail to expected destination domains at the relay/MTA layer and log envelope/header domains for discrepancy review.
   • Pin or patch dependencies once a vetted fixed build is available from trusted sources; do not apply unverified "unofficial" packages.

2. Patch/upgrade steps:

   • Upgrade Nodemailer to 9.1.0 or later, per the NVD description ("Fixed in 9.1.0"). Confirm the installed version in your lockfile and dependency tree, and rebuild artifacts/vendor bundles.
   • Given patch confidence 0/4, obtain the upgrade only from the official upstream distribution and verify integrity (registry signatures/checksums) before deployment. Re-scan dependent applications to confirm the vulnerable version is fully removed.

3. Long-term hardening:

   • Treat email addresses as identity-critical input: apply strict canonical/complete-form validation and fail closed on ambiguous addresses.
   • Adopt differential parsing checks in test suites — feed known interpretation-conflict payloads (e.g., user@good-corp.com(x)evil.com) and assert rejection.
   • Maintain an SBOM and continuous dependency scanning to detect regressions to affected ranges (>= 6.9.16 and < 9.1.0).
   • Monitor upstream advisories and this CVE entry for an official fix and re-evaluate patch confidence; because CISA KEV status is NO and EPSS is unscored, prioritize by exposure of internet-facing mail-sending endpoints.

References

1. NVD — CVE-2026-92597: https://nvd.nist.gov/vuln/detail/CVE-2026-92597
2. Nodemailer project (upstream library and release history — verify 9.1.0 fix): https://nodemailer.com/
3. Nodemailer source repository (lib/addressparser): https://github.com/nodemailer/nodemailer
4. MITRE CWE-436 — Interpretation Conflict: https://cwe.mitre.org/data/definitions/436.html
5. CISA Known Exploited Vulnerabilities Catalog (CVE-2026-92597 NOT listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor campaigns / exploit-in-the-wild evidence: None observed or reported. No public PoC, exploit code, or Nuclei template exists for CVE-2026-92597 at the time of writing, the CVE is not in CISA KEV, and EPSS has not yet scored it. The exploitation scenarios above are inferred from the vulnerability class (CWE-436 interpretation conflict) and the NVD description, not from observed campaigns.