Summary
Nodemailer: Quadratic backtracking in the addressparser free-text fallback allows remote denial of service
When addressparser finds no address by its strict reading, it falls back to pulling one out of the free text with /\s*\b[^@\s]+@[^\s]+\b\s*/. That pattern backtracks quadratically: [^@\s]+ is retried from every offset and rescans the run to the next @ each time. A single header value holding a long whitespace-free run with no usable @ blocks the Node.js event loop for tens of seconds.
It is cheaper to exploit than GHSA-prgh-xp8r-p3m5: 273KB is enough for ~43s, where the comment-joined shape needed ~1.5MB for ~10s.
Details
The fallback in src/addressparser/index.ts ran the pattern as a search. [^@\s]+ crosses neither whitespace nor @, so from each start offset it scans forward to the next @ or to the end of the run and then fails, and the engine simply advances one character and repeats. Three shapes make every offset fail:
- the run holds no
@at all - the only
@has nothing after it - the only
@has nothing before it
A fourth reaches it with a valid address present but placed past a long run, so the long run is walked before the match is found.
PoC
const addressparser = require('nodemailer/lib/addressparser');
const s = Date.now();
addressparser(' >' + '>[x][x]'.repeat(40000)); // 273KB
console.log(Date.now() - s, 'ms'); // ~43000 ms, blocking
Measured on 10.0.5:
| Value | Parse time |
|---|---|
'[x]'.repeat(40000) (117KB) |
9.0 s |
'[x]'.repeat(40000) + '@' (117KB) |
8.9 s |
'@' + '[x]'.repeat(40000) (117KB) |
8.8 s |
' >' + '>[x][x]'.repeat(40000) (273KB) |
42.9 s |
Impact
Algorithmic-complexity denial of service. Node is single threaded, so the block stalls the whole process. Reachable without authentication anywhere inbound header values are handed to this parser, mailparser being the notable case, and reachable from application input wherever a user-supplied string is used as a message address, since mime-node parses to, from and cc when composing.
A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.
GHSA-V53P-9FQP-M79J has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (10.0.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The search is replaced by a single linear pass that finds the one offset the pattern can match at, which is then applied there with a sticky regex. Match results are unchanged, verified against the previous implementation over 3.4 million random strings comparing both the match offset and the matched text, plus 800k full-parse comparisons.
Found while validating the report in GHSA-prgh-xp8r-p3m5, not reported externally.
Frequently Asked Questions
- What is GHSA-V53P-9FQP-M79J? GHSA-V53P-9FQP-M79J is a high-severity inefficient regular expression (ReDoS) vulnerability in nodemailer (npm), affecting versions <= 10.0.5. It is fixed in 10.0.6. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
- How severe is GHSA-V53P-9FQP-M79J? GHSA-V53P-9FQP-M79J has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of nodemailer are affected by GHSA-V53P-9FQP-M79J? nodemailer (npm) versions <= 10.0.5 is affected.
- Is there a fix for GHSA-V53P-9FQP-M79J? Yes. GHSA-V53P-9FQP-M79J is fixed in 10.0.6. Upgrade to this version or later.
- Is GHSA-V53P-9FQP-M79J exploitable, and should I be worried? Whether GHSA-V53P-9FQP-M79J is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-V53P-9FQP-M79J is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-V53P-9FQP-M79J? Upgrade
nodemailerto 10.0.6 or later.