GHSA-v53p-9fqp-m79j

### Summary 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 ```js 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. ### Patch The