CVE-2026-100699
Nodemailer before 10.0.9 Malformed Envelope Recipient via RFC 5322 Comment
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- Low
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
6.9
Nodemailer before 10.0.9 Malformed Envelope Recipient via RFC 5322 Comment
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
CVE-2026-100699- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20
- Updated
- 2026-11-02
EUVDEUVD-2026-87672
6.9
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
EUVD-2026-87672- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-fcjc-3m4q-q926
6.9
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address...
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
GHSA-fcjc-3m4q-q926- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20
- Updated
- 2026-11-02
GitHub AdvisoriesGHSA-g57g-f23g-4646
5.3
Nodemailer: Quoted local-part can produce malformed envelope recipient through RFC 5322 comment parsing
Summary
Nodemailer's address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string.
For example:
"user"@example.com(x)evil.com
is parsed as:
{
address: "[email protected] evil.com",
name: ""
}
The resulting address therefore contains additional attacker-controlled domain text separated by a literal space.
The parsed .address value is subsequently propagated into the SMTP envelope:
src/addressparser/index.ts
↓
recipient.address
↓
src/mime-node/index.ts
↓
envelope.to
The envelope construction uses the parsed address without another strict address validation step.
This appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted.
Reproduction
Input:
"user"@example.com(x)evil.com
Observed parser output:
address: "[email protected] evil.com"
name: ""
A second example:
"a"@b.com(c)d.com(e)f.com
produces:
address: "[email protected] d.com f.com"
name: ""
For comparison, the corresponding unquoted form:
[email protected](x)evil.com
takes a different code path and is handled by the existing protection differently.
Technical Details
The issue is caused by different parsing behavior for quoted and unquoted local-parts.
The quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting .address value.
That value is then used when constructing the message envelope:
envelope.to = recipients.map(to => to.address as string)
No additional strict recipient validation is performed at this boundary.
Security Impact
The confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into envelope.to.
The reporter did not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant.
The remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as:
[email protected] evil.com
An end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass.
Relationship to GHSA-cc9r-2j5m-2m83
This report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83.
The existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address.
Please evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant.
Suggested Fix
The parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted.
In particular:
"user"@example.com(x)evil.com
should not result in:
[email protected] evil.com
The envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation.
Verification Status
Confirmed:
- Parser accepts the quoted-local-part variant.
- Parser produces an address containing additional attacker-controlled text.
- The resulting address is propagated into
envelope.to.
Not confirmed by reporter:
- Successful delivery through a real SMTP server.
- Delivery to an unintended recipient.
- Exploitability against a specific downstream SMTP implementation.
- Record
GHSA-g57g-f23g-4646- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20, CWE-436
- Updated
- 2026-11-02
NVD
6.9
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
CVE-2026-100699- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20
- Updated
- 2026-11-02
OSV
6.9
Nodemailer before 10.0.9 Malformed Envelope Recipient via RFC 5322 Comment
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
CVE-2026-100699- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-20
- Updated
- 2026-11-02
Show 11 moreShow less
OSVDEBIAN-CVE-2026-100699
6.9
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
DEBIAN-CVE-2026-100699- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Updated
- 2026-11-02
OSVGHSA-g57g-f23g-4646
5.3
Nodemailer: Quoted local-part can produce malformed envelope recipient through RFC 5322 comment parsing
Summary
Nodemailer's address parser can produce an unexpected recipient address when an RFC 5322 comment follows the domain of an address whose local-part is a quoted string.
For example:
"user"@example.com(x)evil.com
is parsed as:
{
address: "[email protected] evil.com",
name: ""
}
The resulting address therefore contains additional attacker-controlled domain text separated by a literal space.
The parsed .address value is subsequently propagated into the SMTP envelope:
src/addressparser/index.ts
↓
recipient.address
↓
src/mime-node/index.ts
↓
envelope.to
The envelope construction uses the parsed address without another strict address validation step.
This appears to be a variant of the RFC 5322 comment parsing issue addressed by GHSA-cc9r-2j5m-2m83, but it follows a different parser path when the local-part is quoted.
Reproduction
Input:
"user"@example.com(x)evil.com
Observed parser output:
address: "[email protected] evil.com"
name: ""
A second example:
"a"@b.com(c)d.com(e)f.com
produces:
address: "[email protected] d.com f.com"
name: ""
For comparison, the corresponding unquoted form:
[email protected](x)evil.com
takes a different code path and is handled by the existing protection differently.
Technical Details
The issue is caused by different parsing behavior for quoted and unquoted local-parts.
The quoted-local-part variant allows the comment-separated trailing domain atoms to remain in the resulting .address value.
That value is then used when constructing the message envelope:
envelope.to = recipients.map(to => to.address as string)
No additional strict recipient validation is performed at this boundary.
Security Impact
The confirmed impact is that attacker-controlled comment content can result in a malformed/ambiguous recipient address being accepted by the parser and propagated into envelope.to.
The reporter did not confirm successful delivery to an unintended recipient through a real SMTP server using this exact quoted-local-part variant.
The remaining question is how real SMTP servers and other Nodemailer transports handle an envelope recipient containing a value such as:
[email protected] evil.com
An end-to-end SMTP test is required to determine whether this parser behavior results in an exploitable delivery or recipient-validation bypass.
Relationship to GHSA-cc9r-2j5m-2m83
This report is intended as a potential variant/follow-up to GHSA-cc9r-2j5m-2m83.
The existing advisory addresses RFC 5322 comment handling in email domains. This report identifies a separate parser path involving quoted local-parts that can preserve additional domain-like content in the normalized address.
Please evaluate whether this behavior is already covered by the existing fix or represents a remaining parser variant.
Suggested Fix
The parser should consistently reject or correctly terminate addresses containing trailing domain atoms after RFC 5322 comments, regardless of whether the local-part is quoted.
In particular:
"user"@example.com(x)evil.com
should not result in:
[email protected] evil.com
The envelope-generation layer should also avoid assuming that a parser-produced address is safe for SMTP delivery without appropriate validation.
Verification Status
Confirmed:
- Parser accepts the quoted-local-part variant.
- Parser produces an address containing additional attacker-controlled text.
- The resulting address is propagated into
envelope.to.
Not confirmed by reporter:
- Successful delivery through a real SMTP server.
- Delivery to an unintended recipient.
- Exploitability against a specific downstream SMTP implementation.
- Record
GHSA-g57g-f23g-4646- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20, CWE-436
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-100699
6.9
Nodemailer is a Node.js email-sending library. In versions >= 9.1.0 and < 10.0.9, the address parser (src/addressparser) mishandles addresses whose local-part is a quoted string and that are followed by RFC 5322 comments, allowing trailing comment-separated domain atoms to be retained in the normalized address. For example, the input "user"@example.com(x)evil.com is parsed to the address value '[email protected] evil.com', which contains additional attacker-controlled domain text separated by a literal space. This parsed value is used without further strict recipient validation when the message envelope is built (envelope.to in src/mime-node), so a malformed/ambiguous recipient address can be accepted and placed in the SMTP envelope. Whether this results in delivery to an unintended recipient on real SMTP servers has not been confirmed. The issue is a variant of the RFC 5322 comment parsing problem addressed in GHSA-cc9r-2j5m-2m83, affecting the separate quoted-local-part code path. Version 10.0.9 contains a fix.
- Record
UBUNTU-CVE-2026-100699- CVSS 4.0
- 6.9 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Updated
- 2026-11-02
OSVCLSA-2026-1790854662 No score
TuxCare security update for nodemailer (4 CVEs)
TuxCare rebuilt nodemailer to address 4 CVEs. Fixed in 9.1.0-tuxcare.4.
- Record
CLSA-2026-1790854662- Updated
- 2026-11-02
OSVCLSA-2026-1793790274 No score
TuxCare security update for nodemailer (2 CVEs)
TuxCare rebuilt nodemailer to address 2 CVEs. Fixed in 9.0.6-tuxcare.8.
- Record
CLSA-2026-1793790274- Updated
- 2026-11-04
OSVCLSA-2026-1793801901 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.5-tuxcare.9.
- Record
CLSA-2026-1793801901- Updated
- 2026-11-04
OSVCLSA-2026-1793808867 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.3-tuxcare.8.
- Record
CLSA-2026-1793808867- Updated
- 2026-11-04
OSVCLSA-2026-1793814042 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.2-tuxcare.9.
- Record
CLSA-2026-1793814042- Updated
- 2026-11-05
OSVCLSA-2026-1793828946 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.1-tuxcare.7.
- Record
CLSA-2026-1793828946- Updated
- 2026-11-05
OSVCLSA-2026-1793874971 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 9.0.0-tuxcare.10.
- Record
CLSA-2026-1793874971- Updated
- 2026-11-05
OSVCLSA-2026-1793882612 No score
TuxCare security update for nodemailer (1 CVE)
TuxCare rebuilt nodemailer to address 1 CVE. Fixed in 6.10.1-tuxcare.18.
- Record
CLSA-2026-1793882612- Updated
- 2026-11-06
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
nodemailernpm |
9.1.0 up to 10.0.9 | 10.0.9 |
nodemailerTuxCare:npm From an advisory covering 2 CVEs |
9.1.0-tuxcare.0 up to 9.1.0-tuxcare.4, plus listed versions 9.1.09.1.0-tuxcare.19.1.0-tuxcare.29.1.0-tuxcare.3 |
9.1.0-tuxcare.4 |
nodemailerTuxCare:npm |
9.0.6-tuxcare.0 up to 9.0.6-tuxcare.8, plus listed versions 9.0.69.0.6-tuxcare.19.0.6-tuxcare.29.0.6-tuxcare.39.0.6-tuxcare.49.0.6-tuxcare.59.0.6-tuxcare.69.0.6-tuxcare.7 |
9.0.6-tuxcare.8 |
nodemailerTuxCare:npm |
9.0.5-tuxcare.0 up to 9.0.5-tuxcare.9, plus listed versions 9.0.59.0.5-tuxcare.19.0.5-tuxcare.29.0.5-tuxcare.39.0.5-tuxcare.4 Show 4 moreShow less9.0.5-tuxcare.59.0.5-tuxcare.69.0.5-tuxcare.79.0.5-tuxcare.8 |
9.0.5-tuxcare.9 |
nodemailerTuxCare:npm |
9.0.3-tuxcare.0 up to 9.0.3-tuxcare.8, plus listed versions 9.0.39.0.3-tuxcare.19.0.3-tuxcare.29.0.3-tuxcare.39.0.3-tuxcare.49.0.3-tuxcare.59.0.3-tuxcare.69.0.3-tuxcare.7 |
9.0.3-tuxcare.8 |
nodemailerTuxCare:npm |
9.0.2-tuxcare.0 up to 9.0.2-tuxcare.9, plus listed versions 9.0.29.0.2-tuxcare.19.0.2-tuxcare.29.0.2-tuxcare.39.0.2-tuxcare.4 Show 4 moreShow less9.0.2-tuxcare.59.0.2-tuxcare.69.0.2-tuxcare.79.0.2-tuxcare.8 |
9.0.2-tuxcare.9 |
nodemailerTuxCare:npm |
9.0.1-tuxcare.0 up to 9.0.1-tuxcare.7, plus listed versions 9.0.19.0.1-tuxcare.19.0.1-tuxcare.29.0.1-tuxcare.39.0.1-tuxcare.49.0.1-tuxcare.59.0.1-tuxcare.6 |
9.0.1-tuxcare.7 |
nodemailerTuxCare:npm |
9.0.0-tuxcare.0 up to 9.0.0-tuxcare.10, plus listed versions 9.0.09.0.0-tuxcare.19.0.0-tuxcare.29.0.0-tuxcare.39.0.0-tuxcare.4 Show 5 moreShow less9.0.0-tuxcare.59.0.0-tuxcare.69.0.0-tuxcare.79.0.0-tuxcare.89.0.0-tuxcare.9 |
9.0.0-tuxcare.10 |
nodemailerTuxCare:npm |
6.10.1-tuxcare.0 up to 6.10.1-tuxcare.18, plus listed versions 6.10.16.10.1-tuxcare.16.10.1-tuxcare.106.10.1-tuxcare.116.10.1-tuxcare.12 Show 13 moreShow less6.10.1-tuxcare.136.10.1-tuxcare.146.10.1-tuxcare.156.10.1-tuxcare.166.10.1-tuxcare.176.10.1-tuxcare.26.10.1-tuxcare.36.10.1-tuxcare.46.10.1-tuxcare.56.10.1-tuxcare.66.10.1-tuxcare.76.10.1-tuxcare.86.10.1-tuxcare.9 |
6.10.1-tuxcare.18 |
node-nodemailerDebian:12 |
All versions, plus listed versions 10.0.0+~8.0.1-110.0.10+~8.0.1-110.0.10+~8.0.2-16.10.0+~6.4.17-16.8.0+~6.4.6-1 Show 22 moreShow less6.9.13+~6.4.14-16.9.15+~6.4.16-16.9.16+~6.4.16-16.9.4+~6.4.9-16.9.4+~6.4.9-26.9.4+~6.4.9-36.9.4+~6.4.9-47.0.10+~7.0.2-17.0.12+~7.0.5-17.0.5+~7.0.1-17.0.6+~7.0.1-17.0.9+~7.0.2-17.0.9+~7.0.2-28.0.11+~8.0.1-18.0.2+~7.0.11-18.0.3+~7.0.11-18.0.4+~7.0.11-18.0.4+~7.0.11-29.0.0+~8.0.1-19.0.3+~8.0.1-19.0.5+~8.0.1-19.0.6+~8.0.1-1 |
None known |
Show 7 moreShow less
| Package | Affected | Fixed |
|---|---|---|
node-nodemailerDebian:13 |
All versions, plus listed versions 10.0.0+~8.0.1-110.0.10+~8.0.1-110.0.10+~8.0.2-16.10.0+~6.4.17-16.10.0+~6.4.17-1+deb13u1 Show 15 moreShow less7.0.10+~7.0.2-17.0.12+~7.0.5-17.0.5+~7.0.1-17.0.6+~7.0.1-17.0.9+~7.0.2-17.0.9+~7.0.2-28.0.11+~8.0.1-18.0.2+~7.0.11-18.0.3+~7.0.11-18.0.4+~7.0.11-18.0.4+~7.0.11-29.0.0+~8.0.1-19.0.3+~8.0.1-19.0.5+~8.0.1-19.0.6+~8.0.1-1 |
None known |
node-nodemailerDebian:14 |
before 10.0.10+~8.0.1-1, plus listed versions 10.0.0+~8.0.1-16.10.0+~6.4.17-17.0.10+~7.0.2-17.0.12+~7.0.5-17.0.5+~7.0.1-1 Show 12 moreShow less7.0.6+~7.0.1-17.0.9+~7.0.2-17.0.9+~7.0.2-28.0.11+~8.0.1-18.0.2+~7.0.11-18.0.3+~7.0.11-18.0.4+~7.0.11-18.0.4+~7.0.11-29.0.0+~8.0.1-19.0.3+~8.0.1-19.0.5+~8.0.1-19.0.6+~8.0.1-1 |
10.0.10+~8.0.1-1 |
node-nodemailerUbuntu:20.04:LTS |
All versions, plus listed versions 6.3.0-26.3.1-16.4.0-16.4.1-16.4.2-16.4.5-1 |
None known |
node-nodemailerUbuntu:22.04:LTS |
All versions, plus listed versions 6.4.17-36.7.0-16.7.0-26.7.1+~6.4.4-1 |
None known |
node-nodemailerUbuntu:24.04:LTS |
All versions, plus listed versions 6.9.4+~6.4.9-26.9.4+~6.4.9-3ubuntu16.9.4+~6.4.9-4 |
None known |
node-nodemailerUbuntu:26.10 |
All versions, plus listed versions 8.0.4+~7.0.11-18.0.4+~7.0.11-29.0.0+~8.0.1-19.0.3+~8.0.1-19.0.5+~8.0.1-1 |
None known |
node-nodemailerUbuntu:26.04:LTS |
All versions, plus listed versions 7.0.5+~7.0.1-17.0.9+~7.0.2-27.0.10+~7.0.2-17.0.12+~7.0.5-18.0.4+~7.0.11-1 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, aliases | OSV | |
| affected | ||
| affected, aliases | OSV | |
| affected, aliases | OSV | |
| affected, aliases | OSV | |
| affected, aliases, facts | OSV | |
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-100699 is a medium vulnerability (CVSS 6.9) in Nodemailer, published September 26, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.23%, the 14th percentile. Fixed in nodemailer 10.0.9.
References
github.com/nodemailer/nodemailer/security/advisories/GHSA-g57g-f23g-4646
vulncheck.com/advisories/nodemailer-before-10.0.9-malformed-envelope-recipient-via-rfc-5322-comment
nvd.nist.gov/vuln/detail/CVE-2026-100699
github.com/advisories/GHSA-fcjc-3m4q-q926
github.com/nodemailer/nodemailer/commit/2f36eb1aa1dd33e312411dc9b888548e14db54ee
github.com/nodemailer/nodemailer/releases/tag/v10.0.9