mailparser 3.9.37 → 3.9.39

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,3 +1,3 @@
1
1
  {
2
- ".": "3.9.37"
2
+ ".": "3.9.39"
3
3
  }
package/CHANGELOG.md CHANGED
@@ -1,5 +1,19 @@
1
1
  # Changelog
2
2
 
3
+ ## [3.9.39](https://github.com/nodemailer/mailparser/compare/v3.9.38...v3.9.39) (2026-10-14)
4
+
5
+
6
+ ### Bug Fixes
7
+
8
+ * **deps:** update nodemailer to 10.1.1, libmime to 5.4.8 and mailsplit to 5.4.21 ([43ddf3e](https://github.com/nodemailer/mailparser/commit/43ddf3e9214b2a14b20319d1679ffe001a3a6889))
9
+
10
+ ## [3.9.38](https://github.com/nodemailer/mailparser/compare/v3.9.37...v3.9.38) (2026-10-10)
11
+
12
+
13
+ ### Bug Fixes
14
+
15
+ * **deps:** update nodemailer to 10.1.0 ([278b12c](https://github.com/nodemailer/mailparser/commit/278b12cba8d285d659eb63cafd9a5de7abea5d22))
16
+
3
17
  ## [3.9.37](https://github.com/nodemailer/mailparser/compare/v3.9.36...v3.9.37) (2026-10-08)
4
18
 
5
19
 
package/SECURITY.md CHANGED
@@ -3,21 +3,24 @@
3
3
  mailparser is an email parsing library for Node.js. It is routinely pointed at
4
4
  untrusted, adversarial, and malformed messages, so parser robustness is a
5
5
  security concern: a crafted message should never be able to crash the host
6
- process, exhaust memory or CPU, pollute prototypes, or leak data across parses.
7
- We take security reports seriously and aim to respond quickly.
6
+ process, exhaust memory or CPU through amplification, pollute prototypes, or
7
+ leak data across parses. We welcome responsible reports of vulnerabilities that
8
+ present a credible security risk to users. Please distinguish security
9
+ vulnerabilities from ordinary bugs, unusual edge cases, and hardening
10
+ suggestions.
8
11
 
9
12
  ## Supported Versions
10
13
 
11
- Security fixes are released only against the latest version. We do not backport
12
- patches to older releases - upgrading to the current 3.x release line is the
13
- supported way to receive security updates.
14
+ Security fixes are released only against the latest major version. We do not
15
+ backport patches to older majors, so upgrading to the current release line is
16
+ the supported way to receive security updates.
14
17
 
15
18
  | Version | Supported |
16
19
  | ------- | ------------------ |
17
20
  | 3.x | :white_check_mark: |
18
21
  | < 3.0 | :x: |
19
22
 
20
- If you are on an older version, please upgrade. See the release notes at
23
+ If you are on an older major, please upgrade. See the release notes at
21
24
  <https://github.com/nodemailer/mailparser/releases> before updating.
22
25
 
23
26
  > [!NOTE]
@@ -26,51 +29,126 @@ If you are on an older version, please upgrade. See the release notes at
26
29
  > [PostalMime](https://github.com/postalsys/postal-mime), which works in both
27
30
  > Node.js and browser environments.
28
31
 
29
- ## Reporting a Vulnerability
32
+ ## What Qualifies as a Security Vulnerability
30
33
 
31
- **Please do not report security vulnerabilities through public GitHub issues,
32
- pull requests, or discussions.**
34
+ A security report should identify a realistic way for an attacker to cross a
35
+ security boundary in a supported version of mailparser. Unexpected behavior, a
36
+ failing test, or a technically correct proof of concept is not sufficient on its
37
+ own to establish security impact.
33
38
 
34
- Report privately through one of the following channels:
39
+ In particular, explain:
35
40
 
36
- 1. **GitHub Security Advisories (preferred).** Open a private report at
37
- <https://github.com/nodemailer/mailparser/security/advisories/new>. This keeps
38
- the discussion private until a fix is published and lets us credit you.
39
- 2. **Email.** Send details to **andris@postalsys.com** (the contact listed in
40
- [`SECURITY.txt`](SECURITY.txt)). Encrypt sensitive details if possible - our
41
- PGP key fingerprint is `5D952A46E1D8C931F6364E01DC6C83F4D584D364`.
41
+ - **Attacker capabilities:** Who is the attacker, and what inputs, systems, or
42
+ responses can they control _without_ already having the privileges or secrets
43
+ they are trying to gain?
44
+ - **Attack path:** How does attacker-controlled input reach the affected code
45
+ through a supported public API or a realistic application integration?
46
+ - **Prerequisites:** What configuration and user actions are required? If the
47
+ attack depends on unusual options or deliberately malformed input, explain why
48
+ those conditions could arise in a real application.
49
+ - **Impact:** What confidentiality, integrity, or availability boundary is
50
+ crossed, and what can the attacker achieve as a result?
42
51
 
43
- When reporting, please include as much of the following as you can:
52
+ A vulnerability involving an optional or less common feature can still qualify
53
+ if these conditions are met. Conversely, the existence of a defensive check in
54
+ the code does not, by itself, establish that every bypass of that check has a
55
+ realistic security impact.
44
56
 
45
- - The affected version(s) and environment (mailparser version, Node.js version,
46
- OS).
47
- - A clear description of the issue and its impact (e.g. denial of service via
48
- CPU or memory exhaustion, ReDoS, prototype pollution, unhandled exception that
49
- crashes the process, information disclosure between parses).
50
- - A minimal proof of concept - ideally the raw `.eml` sample or a short script
51
- that reproduces the issue.
52
- - Any suggested remediation, if you have one.
57
+ ## Reporting a Vulnerability
53
58
 
54
- We are a small team, so there is no guaranteed response time - sometimes reports
55
- are handled within hours, sometimes they take longer. Accepted issues are fixed
56
- in a new release and coordinated through a GitHub Security Advisory, and
57
- reporters who wish to be named are credited.
59
+ **Do not disclose suspected exploitable vulnerabilities through public GitHub
60
+ issues, pull requests, or discussions before coordinating with the
61
+ maintainers.**
58
62
 
59
- ## CVEs
63
+ Report privately through one of the following channels:
60
64
 
61
- We track and disclose vulnerabilities through GitHub Security Advisories. We do
62
- not request or manage CVE identifiers ourselves. If you need a CVE assigned for a
63
- reported issue, please request one yourself - for example, through GitHub's own
64
- CVE request flow on the published advisory, or another CNA.
65
+ 1. **GitHub Security Advisories (preferred):**
66
+ <https://github.com/nodemailer/mailparser/security/advisories/new>.
67
+ 2. **Email:** **andris@postalsys.com**, as listed in
68
+ [`SECURITY.txt`](SECURITY.txt). Encrypt sensitive details if possible.
69
+
70
+ ### Required Information
71
+
72
+ Please provide enough information to evaluate both the defect and its security
73
+ impact. Reports should include:
74
+
75
+ 1. The affected mailparser version or commit, Node.js version, and relevant
76
+ configuration.
77
+ 2. A concise description of the issue and the affected public API or code path
78
+ (`MailParser` or `simpleParser`. The raw `.eml` sample that triggers the
79
+ issue is the most useful reproduction).
80
+ 3. A minimal, tested reproduction, including steps to run it, expected behavior,
81
+ and observed behavior.
82
+ 4. A concrete threat model: attacker control, prerequisites, trust boundary, and
83
+ resulting impact. Clearly distinguish what your reproduction proves from what
84
+ you believe might be possible.
85
+ 5. An explanation of why the issue affects real deployments beyond a
86
+ deliberately constructed test setup, where this is not obvious.
87
+
88
+ A suggested fix is welcome but does not replace an explanation of
89
+ exploitability. A complete real-world exploit is not always necessary, but the
90
+ report must make a credible security impact clear.
91
+
92
+ ### Reports That May Be Treated as Ordinary Bugs
93
+
94
+ The following generally do **not** qualify for private security handling unless
95
+ you can demonstrate an additional, meaningful security boundary crossing:
96
+
97
+ - Issues that require the attacker to control trusted application code,
98
+ administrator-only configuration, or the secret they supposedly extract.
99
+ - Problems caused solely by application-level misuse, exposed credentials, or
100
+ insecure deployment choices outside mailparser's control.
101
+ - Contrived proof-of-concept setups where the tester controls both sides of a
102
+ request, without explaining how a separate attacker could trigger the issue.
103
+ - Parser quirks, unexpected behavior, and bypasses of internal checks with no
104
+ demonstrated security impact.
105
+ - Speculative findings based only on static analysis or an automated tool's
106
+ assessment, without a verified reproduction and credible attack scenario.
107
+
108
+ These may still be valid bugs and may be considered through the normal issue
109
+ tracker. Please coordinate before making any potentially exploitable details
110
+ public. Classification as a bug does not guarantee a fix or a particular
111
+ priority.
112
+
113
+ ### Automated and AI-Assisted Reports
114
+
115
+ Automated analysis and AI tools are welcome as research aids, but the person
116
+ submitting a report is responsible for verifying its claims. **Do not submit
117
+ bulk, unverified, or speculative AI-generated findings.** Test each finding
118
+ against a supported release and establish the actual security impact. Reports
119
+ that do not meet the requirements above may be closed without further
120
+ investigation or individual feedback; they can be resubmitted with stronger
121
+ evidence.
122
+
123
+ ## Triage and Disclosure
124
+
125
+ mailparser is maintained by a small team, and there is **no guaranteed response
126
+ or resolution time**. Reports are prioritized based on demonstrated impact,
127
+ exploitability, affected usage, and available maintenance resources.
128
+
129
+ A private report does not automatically become a security advisory. Confirmed
130
+ vulnerabilities may be fixed and disclosed through GitHub Security Advisories;
131
+ other findings may be closed, deferred, or handled as ordinary bugs. Please do
132
+ not disclose details of an unresolved, potentially exploitable issue publicly
133
+ without coordinating with the maintainers.
134
+
135
+ ## CVEs and Credit
136
+
137
+ We do not request or manage CVE identifiers. A report being acknowledged, a bug
138
+ being fixed, or a pull request being merged does **not** mean that mailparser
139
+ has confirmed a security vulnerability or endorsed a CVE assignment. We do not
140
+ guarantee advisories, CVE identifiers, or public credit for reports. For
141
+ confirmed vulnerabilities disclosed through an advisory, substantive reporters
142
+ may be credited if they wish.
65
143
 
66
144
  ## Scope
67
145
 
68
- In scope: the mailparser library source in this repository - the streaming MIME
146
+ In scope: the mailparser library source in this repository: the streaming MIME
69
147
  parser (`MailParser`), the convenience parser (`simpleParser`), header and
70
- address decoding, charset/transfer-encoding handling, and attachment and HTML/
71
- text extraction. Of particular interest are inputs that cause unbounded resource
72
- consumption, catastrophic regular-expression backtracking, prototype pollution,
73
- or process crashes.
148
+ address decoding, charset and transfer-encoding handling, and attachment and
149
+ HTML/text extraction. Of particular interest are small crafted inputs that cause
150
+ amplified resource consumption, catastrophic regular-expression backtracking,
151
+ prototype pollution, or process crashes.
74
152
 
75
153
  Out of scope:
76
154
 
@@ -78,13 +156,11 @@ Out of scope:
78
156
  Parsed email content is attacker-controlled data; you must sanitize and escape
79
157
  it before rendering, storing, or executing it. In particular, the `html` field
80
158
  is not sanitized for safe display in a browser.
81
- - Vulnerabilities in third-party dependencies that are already tracked and fixed
82
- upstream - report those to the respective project (we will still bump the
83
- dependency once a fix is available).
84
- - Issues that require an already-compromised host or a malicious local
85
- environment.
86
159
  - Resource consumption that is proportional to a legitimately large input (for
87
160
  example, parsing a genuine 100MB message uses memory) rather than amplified by
88
161
  a crafted small input.
162
+ - Vulnerabilities in third-party dependencies that are already tracked upstream
163
+ (we will still bump the dependency once a fix is available).
164
+ - Social-engineering reports.
89
165
 
90
166
  Thank you for helping keep mailparser and its users safe.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "mailparser",
3
- "version": "3.9.37",
3
+ "version": "3.9.39",
4
4
  "description": "Parse e-mails",
5
5
  "main": "index.js",
6
6
  "scripts": {
@@ -22,10 +22,10 @@
22
22
  "he": "1.2.0",
23
23
  "html-to-text": "10.0.1",
24
24
  "iconv-lite": "0.7.3",
25
- "libmime": "5.4.7",
25
+ "libmime": "5.4.8",
26
26
  "linkify-it": "5.0.2",
27
- "@zone-eu/mailsplit": "5.4.20",
28
- "nodemailer": "10.0.16",
27
+ "@zone-eu/mailsplit": "5.4.21",
28
+ "nodemailer": "10.1.1",
29
29
  "punycode.js": "2.3.1",
30
30
  "tlds": "1.261.0"
31
31
  },
@@ -41,7 +41,7 @@
41
41
  "grunt-contrib-nodeunit": "5.0.0",
42
42
  "grunt-eslint": "27.0.0",
43
43
  "iconv": "3.0.1",
44
- "prettier": "3.9.9",
44
+ "prettier": "3.9.10",
45
45
  "random-message": "1.1.0"
46
46
  },
47
47
  "repository": {