@mavogel/awscdk-rootmail 0.1.20 → 0.1.21

package/.jsii

@@ -8,13 +8,13 @@
     ]
   },
   "bundled": {
-    "@aws-sdk/client-cloudwatch-logs": "^3.1151.0",
-    "@aws-sdk/client-route-53": "^3.1151.0",
-    "@aws-sdk/client-s3": "^3.1151.0",
-    "@aws-sdk/client-ses": "^3.1151.0",
-    "@aws-sdk/client-ssm": "^3.1151.0",
+    "@aws-sdk/client-cloudwatch-logs": "^3.1152.0",
+    "@aws-sdk/client-route-53": "^3.1152.0",
+    "@aws-sdk/client-s3": "^3.1152.0",
+    "@aws-sdk/client-ses": "^3.1152.0",
+    "@aws-sdk/client-ssm": "^3.1152.0",
     "cdk-nag": "^3.0.1",
-    "mailparser": "^3.9.38",
+    "mailparser": "^3.9.39",
     "uuid": "^14.0.3"
   },
   "dependencies": {
@@ -9620,6 +9620,6 @@
       "symbolId": "src/ses-receive:SESReceiveProps"
     }
   },
-  "version": "0.1.20",
-  "fingerprint": "SXVPnty43T2jFSDUY4TbDYNrxUTXzDBEf+im0KvlE3Q="
+  "version": "0.1.21",
+  "fingerprint": "B8+T8BHS/1ZL9hQ+6HZrufVgi5O/f3zYXERuO93gpcs="
 }

package/lib/rootmail.js

@@ -11,7 +11,7 @@ const ses_receive_1 = require("./ses-receive");
  * Rootmail construct
  */
 class Rootmail extends constructs_1.Construct {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@mavogel/awscdk-rootmail.Rootmail", version: "0.1.20" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@mavogel/awscdk-rootmail.Rootmail", version: "0.1.21" };
     /**
      * The name parameter in SSM to store the domain name server.
      */

package/lib/ses-receive.js

@@ -11,7 +11,7 @@ const ses_receipt_ruleset_activation_1 = require("./ses-receipt-ruleset-activati
  * SES Receive construct
  */
 class SESReceive extends constructs_1.Construct {
-    static [JSII_RTTI_SYMBOL_1] = { fqn: "@mavogel/awscdk-rootmail.SESReceive", version: "0.1.20" };
+    static [JSII_RTTI_SYMBOL_1] = { fqn: "@mavogel/awscdk-rootmail.SESReceive", version: "0.1.21" };
     constructor(scope, id, props) {
         super(scope, id);
         const filteredEmailSubjects = props.filteredEmailSubjects || [];

package/node_modules/@aws-sdk/client-cloudwatch-logs/dist-cjs/index.js

@@ -70,7 +70,7 @@ const commonParams = {
     UseDualStack: { type: "builtInParams", name: "useDualstackEndpoint" },
 };
 
-var version = "3.1150.0";
+var version = "3.1151.0";
 var packageInfo = {
 	version: version};
 

package/node_modules/@aws-sdk/client-cloudwatch-logs/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-sdk/client-cloudwatch-logs",
-  "version": "3.1151.0",
+  "version": "3.1152.0",
   "description": "AWS SDK for JavaScript Cloudwatch Logs Client for Node.js, Browser and React Native",
   "homepage": "https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-cloudwatch-logs",
   "license": "Apache-2.0",

package/node_modules/@aws-sdk/client-route-53/dist-cjs/index.js

@@ -70,7 +70,7 @@ const commonParams = {
     UseDualStack: { type: "builtInParams", name: "useDualstackEndpoint" },
 };
 
-var version = "3.1150.0";
+var version = "3.1151.0";
 var packageInfo = {
 	version: version};
 

package/node_modules/@aws-sdk/client-route-53/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-sdk/client-route-53",
-  "version": "3.1151.0",
+  "version": "3.1152.0",
   "description": "AWS SDK for JavaScript Route 53 Client for Node.js, Browser and React Native",
   "homepage": "https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-route-53",
   "license": "Apache-2.0",

package/node_modules/@aws-sdk/client-s3/dist-cjs/index.js

@@ -4779,7 +4779,7 @@ var WriteGetObjectResponse$ = [9, n0, _WGOR,
 class CreateSessionCommand extends command(_ep4, _mw0, "CreateSession", CreateSession$) {
 }
 
-var version = "3.1150.0";
+var version = "3.1151.0";
 var packageInfo = {
 	version: version};
 

package/node_modules/@aws-sdk/client-s3/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-sdk/client-s3",
-  "version": "3.1151.0",
+  "version": "3.1152.0",
   "description": "AWS SDK for JavaScript S3 Client for Node.js, Browser and React Native",
   "homepage": "https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-s3",
   "license": "Apache-2.0",
@@ -67,7 +67,7 @@
     "tslib": "^2.6.2"
   },
   "devDependencies": {
-    "@aws-sdk/signature-v4-crt": "3.1151.0",
+    "@aws-sdk/signature-v4-crt": "3.1152.0",
     "@smithy/snapshot-testing": "^2.3.2",
     "@tsconfig/node20": "20.1.8",
     "@types/node": "^20.14.8",

package/node_modules/@aws-sdk/client-ses/dist-cjs/index.js

@@ -69,7 +69,7 @@ const commonParams = {
     UseDualStack: { type: "builtInParams", name: "useDualstackEndpoint" },
 };
 
-var version = "3.1150.0";
+var version = "3.1151.0";
 var packageInfo = {
 	version: version};
 

package/node_modules/@aws-sdk/client-ses/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-sdk/client-ses",
-  "version": "3.1151.0",
+  "version": "3.1152.0",
   "description": "AWS SDK for JavaScript Ses Client for Node.js, Browser and React Native",
   "homepage": "https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-ses",
   "license": "Apache-2.0",

package/node_modules/@aws-sdk/client-ssm/dist-cjs/index.js

@@ -69,7 +69,7 @@ const commonParams = {
     UseDualStack: { type: "builtInParams", name: "useDualstackEndpoint" },
 };
 
-var version = "3.1150.0";
+var version = "3.1151.0";
 var packageInfo = {
 	version: version};
 

package/node_modules/@aws-sdk/client-ssm/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aws-sdk/client-ssm",
-  "version": "3.1151.0",
+  "version": "3.1152.0",
   "description": "AWS SDK for JavaScript Ssm Client for Node.js, Browser and React Native",
   "homepage": "https://github.com/aws/aws-sdk-js-v3/tree/main/clients/client-ssm",
   "license": "Apache-2.0",

package/node_modules/@zone-eu/mailsplit/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@zone-eu/mailsplit",
-    "version": "5.4.20",
+    "version": "5.4.21",
     "description": "Split email messages into an object stream",
     "main": "index.js",
     "types": "index.d.ts",
@@ -15,8 +15,8 @@
     "author": "Andris Reinman",
     "license": "(MIT OR EUPL-1.1+)",
     "dependencies": {
-        "libbase64": "1.3.2",
-        "libmime": "5.4.7",
+        "libbase64": "1.3.3",
+        "libmime": "5.4.8",
         "libqp": "2.1.2"
     },
     "devDependencies": {
@@ -25,7 +25,7 @@
         "@types/grunt": "0.4.32",
         "@types/libmime": "5.3.0",
         "@types/libqp": "1.1.3",
-        "@types/node": "26.6.4",
+        "@types/node": "26.6.5",
         "eslint": "8.29.0",
         "eslint-config-nodemailer": "1.2.0",
         "eslint-config-prettier": "9.1.0",

package/node_modules/libbase64/.github/VULNERABILITY_REPORT.yml

@@ -0,0 +1,75 @@
+name: "libbase64 security vulnerability report"
+description: "Report an exploitable security vulnerability in libbase64"
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Before reporting, read our
+        [Security Policy](https://github.com/nodemailer/libbase64/security/policy).
+
+        Reports must demonstrate a credible security impact.
+        Technically valid bugs without a realistic attack
+        scenario belong in the regular issue tracker.
+
+  - type: textarea
+    id: summary
+    attributes:
+      label: Vulnerability summary
+      description: Describe the vulnerability and affected versions.
+    validations:
+      required: true
+
+  - type: textarea
+    id: attacker
+    attributes:
+      label: Attacker capabilities
+      description: |
+        What can an attacker control without already having
+        privileged access to the application or its configuration?
+    validations:
+      required: true
+      min_length: 100
+
+  - type: textarea
+    id: exploit
+    attributes:
+      label: Realistic exploitation scenario
+      description: |
+        Describe how this can be exploited in a real application.
+        Explain the prerequisites and security boundary crossed.
+    validations:
+      required: true
+      min_length: 150
+
+  - type: textarea
+    id: poc
+    attributes:
+      label: Proof of concept
+      description: Provide reproducible steps or working code.
+    validations:
+      required: true
+
+  - type: textarea
+    id: impact
+    attributes:
+      label: Security impact
+      description: |
+        What can the attacker achieve? Who is affected?
+        Explain why this is a security vulnerability rather
+        than an ordinary bug.
+    validations:
+      required: true
+      min_length: 100
+
+  - type: checkboxes
+    id: confirmation
+    attributes:
+      label: Reporting requirements
+      options:
+        - label: I have read the Security Policy.
+          required: true
+        - label: I have verified the finding against a supported version.
+          required: true
+        - label: I have described a credible attacker-controlled scenario.
+          required: true

package/node_modules/libbase64/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [1.3.3](https://github.com/nodemailer/libbase64/compare/v1.3.2...v1.3.3) (2026-10-14)
+
+
+### Bug Fixes
+
+* **decoder:** decode padded segments into one buffer instead of a Buffer per segment ([0c01914](https://github.com/nodemailer/libbase64/commit/0c0191457e343769e8b68adb4052d71fa267abd1))
+
 ## [1.3.2](https://github.com/nodemailer/libbase64/compare/v1.3.1...v1.3.2) (2026-10-04)
 
 

package/node_modules/libbase64/SECURITY.md

@@ -0,0 +1,147 @@
+# Security Policy
+
+libbase64 encodes and decodes base64 strings and streams, with line wrapping for
+MIME. It is used to decode untrusted email content. We welcome responsible
+reports of vulnerabilities that present a credible security risk to users.
+Please distinguish security vulnerabilities from ordinary bugs, unusual edge
+cases, and hardening suggestions.
+
+## Supported Versions
+
+Security fixes are released only against the latest major version. We do not
+backport patches to older majors, so upgrading to the current release line is
+the supported way to receive security updates.
+
+| Version | Supported          |
+| ------- | ------------------ |
+| 1.x     | :white_check_mark: |
+| < 1.0   | :x:                |
+
+If you are on an older major, please upgrade. See [CHANGELOG.md](CHANGELOG.md)
+before updating.
+
+## What Qualifies as a Security Vulnerability
+
+A security report should identify a realistic way for an attacker to cross a
+security boundary in a supported version of libbase64. Unexpected behavior, a
+failing test, or a technically correct proof of concept is not sufficient on its
+own to establish security impact.
+
+In particular, explain:
+
+- **Attacker capabilities:** Who is the attacker, and what inputs, systems, or
+  responses can they control _without_ already having the privileges or secrets
+  they are trying to gain?
+- **Attack path:** How does attacker-controlled input reach the affected code
+  through a supported public API or a realistic application integration?
+- **Prerequisites:** What configuration and user actions are required? If the
+  attack depends on unusual options or deliberately malformed input, explain why
+  those conditions could arise in a real application.
+- **Impact:** What confidentiality, integrity, or availability boundary is
+  crossed, and what can the attacker achieve as a result?
+
+A vulnerability involving an optional or less common feature can still qualify
+if these conditions are met. Conversely, the existence of a defensive check in
+the code does not, by itself, establish that every bypass of that check has a
+realistic security impact.
+
+## Reporting a Vulnerability
+
+**Do not disclose suspected exploitable vulnerabilities through public GitHub
+issues, pull requests, or discussions before coordinating with the
+maintainers.**
+
+Report privately through one of the following channels:
+
+1. **GitHub Security Advisories (preferred):**
+   <https://github.com/nodemailer/libbase64/security/advisories/new>.
+2. **Email:** **andris@reinman.eu**. Encrypt sensitive details if possible (PGP
+   key fingerprint `5D952A46E1D8C931F6364E01DC6C83F4D584D364`).
+
+### Required Information
+
+Please provide enough information to evaluate both the defect and its security
+impact. Reports should include:
+
+1. The affected libbase64 version or commit, Node.js version, and relevant
+   configuration.
+2. A concise description of the issue and the affected public API or code path.
+3. A minimal, tested reproduction, including steps to run it, expected behavior,
+   and observed behavior.
+4. A concrete threat model: attacker control, prerequisites, trust boundary, and
+   resulting impact. Clearly distinguish what your reproduction proves from what
+   you believe might be possible.
+5. An explanation of why the issue affects real deployments beyond a
+   deliberately constructed test setup, where this is not obvious.
+
+A suggested fix is welcome but does not replace an explanation of
+exploitability. A complete real-world exploit is not always necessary, but the
+report must make a credible security impact clear.
+
+### Reports That May Be Treated as Ordinary Bugs
+
+The following generally do **not** qualify for private security handling unless
+you can demonstrate an additional, meaningful security boundary crossing:
+
+- Issues that require the attacker to control trusted application code,
+  administrator-only configuration, or the secret they supposedly extract.
+- Problems caused solely by application-level misuse, exposed credentials, or
+  insecure deployment choices outside libbase64's control.
+- Contrived proof-of-concept setups where the tester controls both sides of a
+  request, without explaining how a separate attacker could trigger the issue.
+- Parser quirks, unexpected behavior, and bypasses of internal checks with no
+  demonstrated security impact.
+- Speculative findings based only on static analysis or an automated tool's
+  assessment, without a verified reproduction and credible attack scenario.
+
+These may still be valid bugs and may be considered through the normal issue
+tracker. Please coordinate before making any potentially exploitable details
+public. Classification as a bug does not guarantee a fix or a particular
+priority.
+
+### Automated and AI-Assisted Reports
+
+Automated analysis and AI tools are welcome as research aids, but the person
+submitting a report is responsible for verifying its claims. **Do not submit
+bulk, unverified, or speculative AI-generated findings.** Test each finding
+against a supported release and establish the actual security impact. Reports
+that do not meet the requirements above may be closed without further
+investigation or individual feedback; they can be resubmitted with stronger
+evidence.
+
+## Triage and Disclosure
+
+libbase64 is maintained by a single person, and there is **no guaranteed
+response or resolution time**. Reports are prioritized based on demonstrated
+impact, exploitability, affected usage, and available maintenance resources.
+
+A private report does not automatically become a security advisory. Confirmed
+vulnerabilities may be fixed and disclosed through GitHub Security Advisories;
+other findings may be closed, deferred, or handled as ordinary bugs. Please do
+not disclose details of an unresolved, potentially exploitable issue publicly
+without coordinating with the maintainers.
+
+## CVEs and Credit
+
+We do not request or manage CVE identifiers. A report being acknowledged, a bug
+being fixed, or a pull request being merged does **not** mean that libbase64 has
+confirmed a security vulnerability or endorsed a CVE assignment. We do not
+guarantee advisories, CVE identifiers, or public credit for reports. For
+confirmed vulnerabilities disclosed through an advisory, substantive reporters
+may be credited if they wish.
+
+## Scope
+
+In scope: the libbase64 source in this repository: the encoder and decoder
+functions and their stream variants. Of particular interest are inputs that
+crash the process, corrupt output beyond the malformed input, or consume
+resources out of proportion to their size.
+
+Out of scope:
+
+- Resource consumption that is proportional to a legitimately large input.
+- Vulnerabilities in your own application code, including how it handles decoded
+  data.
+- Social-engineering reports.
+
+Thank you for helping keep libbase64 and its users safe.

package/node_modules/libbase64/lib/libbase64.js

@@ -28,17 +28,29 @@ function decode(str) {
     str = str || '';
 
     // Buffer.from() stops decoding at the first padding char, so input made of several
-    // padded segments (eg. every line padded on its own) is decoded segment by segment
+    // padded segments (eg. every line padded on its own) is decoded segment by segment.
+    // Segments are found with indexOf and written into one buffer: splitting the input and
+    // keeping a Buffer per segment cost memory per segment, tens of times the input size
+    // for a body that pads every line.
     if (typeof str === 'string') {
         let padPos = str.indexOf('=');
-        if (padPos >= 0 && /[a-zA-Z0-9+/\-_]/.test(str.substr(padPos))) {
-            let parts = [];
-            for (let segment of str.split(/[=]+/)) {
-                if (segment) {
-                    parts.push(Buffer.from(segment, 'base64'));
+        if (padPos >= 0 && /[a-zA-Z0-9+/\-_]/.test(str.slice(padPos))) {
+            // a segment of n characters decodes to at most n * 3 / 4 bytes
+            let output = Buffer.alloc(Math.floor((str.length * 3) / 4));
+            let length = 0;
+            let start = 0;
+            while (start <= str.length) {
+                let end = str.indexOf('=', start);
+                if (end < 0) {
+                    end = str.length;
                 }
+                if (end > start) {
+                    length += output.write(str.substring(start, end), length, 'base64');
+                }
+                start = end + 1;
             }
-            return Buffer.concat(parts);
+            // copied out so the result does not keep the oversized buffer alive
+            return Buffer.from(output.subarray(0, length));
         }
     }
 

package/node_modules/libbase64/package.json

@@ -1,6 +1,6 @@
 {
     "name": "libbase64",
-    "version": "1.3.2",
+    "version": "1.3.3",
     "description": "Encode and decode base64 encoded strings",
     "main": "lib/libbase64.js",
     "scripts": {

package/node_modules/libmime/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [5.4.8](https://github.com/nodemailer/libmime/compare/v5.4.7...v5.4.8) (2026-10-14)
+
+
+### Bug Fixes
+
+* **deps:** update libbase64 to 1.3.3 ([4fa88fb](https://github.com/nodemailer/libmime/commit/4fa88fb0c6ff1f4a06bd67b53bf4bad2b1a6f5c2))
+
 ## [5.4.7](https://github.com/nodemailer/libmime/compare/v5.4.6...v5.4.7) (2026-10-04)
 
 

package/node_modules/libmime/package.json

@@ -1,7 +1,7 @@
 {
     "name": "libmime",
     "description": "Encode and decode quoted printable and base64 strings",
-    "version": "5.4.7",
+    "version": "5.4.8",
     "main": "lib/libmime.js",
     "files": [
         "lib",
@@ -26,7 +26,7 @@
     "dependencies": {
         "encoding-japanese": "2.4.0",
         "iconv-lite": "0.7.3",
-        "libbase64": "1.3.2",
+        "libbase64": "1.3.3",
         "libqp": "2.1.2"
     },
     "devDependencies": {

package/node_modules/mailparser/.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-    ".": "3.9.38"
+    ".": "3.9.39"
 }

package/node_modules/mailparser/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [3.9.39](https://github.com/nodemailer/mailparser/compare/v3.9.38...v3.9.39) (2026-10-14)
+
+
+### Bug Fixes
+
+* **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))
+
 ## [3.9.38](https://github.com/nodemailer/mailparser/compare/v3.9.37...v3.9.38) (2026-10-10)
 
 

package/node_modules/mailparser/SECURITY.md

@@ -3,21 +3,24 @@
 mailparser is an email parsing library for Node.js. It is routinely pointed at
 untrusted, adversarial, and malformed messages, so parser robustness is a
 security concern: a crafted message should never be able to crash the host
-process, exhaust memory or CPU, pollute prototypes, or leak data across parses.
-We take security reports seriously and aim to respond quickly.
+process, exhaust memory or CPU through amplification, pollute prototypes, or
+leak data across parses. We welcome responsible reports of vulnerabilities that
+present a credible security risk to users. Please distinguish security
+vulnerabilities from ordinary bugs, unusual edge cases, and hardening
+suggestions.
 
 ## Supported Versions
 
-Security fixes are released only against the latest version. We do not backport
-patches to older releases - upgrading to the current 3.x release line is the
-supported way to receive security updates.
+Security fixes are released only against the latest major version. We do not
+backport patches to older majors, so upgrading to the current release line is
+the supported way to receive security updates.
 
 | Version | Supported          |
 | ------- | ------------------ |
 | 3.x     | :white_check_mark: |
 | < 3.0   | :x:                |
 
-If you are on an older version, please upgrade. See the release notes at
+If you are on an older major, please upgrade. See the release notes at
 <https://github.com/nodemailer/mailparser/releases> before updating.
 
 > [!NOTE]
@@ -26,51 +29,126 @@ If you are on an older version, please upgrade. See the release notes at
 > [PostalMime](https://github.com/postalsys/postal-mime), which works in both
 > Node.js and browser environments.
 
-## Reporting a Vulnerability
+## What Qualifies as a Security Vulnerability
 
-**Please do not report security vulnerabilities through public GitHub issues,
-pull requests, or discussions.**
+A security report should identify a realistic way for an attacker to cross a
+security boundary in a supported version of mailparser. Unexpected behavior, a
+failing test, or a technically correct proof of concept is not sufficient on its
+own to establish security impact.
 
-Report privately through one of the following channels:
+In particular, explain:
 
-1. **GitHub Security Advisories (preferred).** Open a private report at
-   <https://github.com/nodemailer/mailparser/security/advisories/new>. This keeps
-   the discussion private until a fix is published and lets us credit you.
-2. **Email.** Send details to **andris@postalsys.com** (the contact listed in
-   [`SECURITY.txt`](SECURITY.txt)). Encrypt sensitive details if possible - our
-   PGP key fingerprint is `5D952A46E1D8C931F6364E01DC6C83F4D584D364`.
+- **Attacker capabilities:** Who is the attacker, and what inputs, systems, or
+  responses can they control _without_ already having the privileges or secrets
+  they are trying to gain?
+- **Attack path:** How does attacker-controlled input reach the affected code
+  through a supported public API or a realistic application integration?
+- **Prerequisites:** What configuration and user actions are required? If the
+  attack depends on unusual options or deliberately malformed input, explain why
+  those conditions could arise in a real application.
+- **Impact:** What confidentiality, integrity, or availability boundary is
+  crossed, and what can the attacker achieve as a result?
 
-When reporting, please include as much of the following as you can:
+A vulnerability involving an optional or less common feature can still qualify
+if these conditions are met. Conversely, the existence of a defensive check in
+the code does not, by itself, establish that every bypass of that check has a
+realistic security impact.
 
-- The affected version(s) and environment (mailparser version, Node.js version,
-  OS).
-- A clear description of the issue and its impact (e.g. denial of service via
-  CPU or memory exhaustion, ReDoS, prototype pollution, unhandled exception that
-  crashes the process, information disclosure between parses).
-- A minimal proof of concept - ideally the raw `.eml` sample or a short script
-  that reproduces the issue.
-- Any suggested remediation, if you have one.
+## Reporting a Vulnerability
 
-We are a small team, so there is no guaranteed response time - sometimes reports
-are handled within hours, sometimes they take longer. Accepted issues are fixed
-in a new release and coordinated through a GitHub Security Advisory, and
-reporters who wish to be named are credited.
+**Do not disclose suspected exploitable vulnerabilities through public GitHub
+issues, pull requests, or discussions before coordinating with the
+maintainers.**
 
-## CVEs
+Report privately through one of the following channels:
 
-We track and disclose vulnerabilities through GitHub Security Advisories. We do
-not request or manage CVE identifiers ourselves. If you need a CVE assigned for a
-reported issue, please request one yourself - for example, through GitHub's own
-CVE request flow on the published advisory, or another CNA.
+1. **GitHub Security Advisories (preferred):**
+   <https://github.com/nodemailer/mailparser/security/advisories/new>.
+2. **Email:** **andris@postalsys.com**, as listed in
+   [`SECURITY.txt`](SECURITY.txt). Encrypt sensitive details if possible.
+
+### Required Information
+
+Please provide enough information to evaluate both the defect and its security
+impact. Reports should include:
+
+1. The affected mailparser version or commit, Node.js version, and relevant
+   configuration.
+2. A concise description of the issue and the affected public API or code path
+   (`MailParser` or `simpleParser`. The raw `.eml` sample that triggers the
+   issue is the most useful reproduction).
+3. A minimal, tested reproduction, including steps to run it, expected behavior,
+   and observed behavior.
+4. A concrete threat model: attacker control, prerequisites, trust boundary, and
+   resulting impact. Clearly distinguish what your reproduction proves from what
+   you believe might be possible.
+5. An explanation of why the issue affects real deployments beyond a
+   deliberately constructed test setup, where this is not obvious.
+
+A suggested fix is welcome but does not replace an explanation of
+exploitability. A complete real-world exploit is not always necessary, but the
+report must make a credible security impact clear.
+
+### Reports That May Be Treated as Ordinary Bugs
+
+The following generally do **not** qualify for private security handling unless
+you can demonstrate an additional, meaningful security boundary crossing:
+
+- Issues that require the attacker to control trusted application code,
+  administrator-only configuration, or the secret they supposedly extract.
+- Problems caused solely by application-level misuse, exposed credentials, or
+  insecure deployment choices outside mailparser's control.
+- Contrived proof-of-concept setups where the tester controls both sides of a
+  request, without explaining how a separate attacker could trigger the issue.
+- Parser quirks, unexpected behavior, and bypasses of internal checks with no
+  demonstrated security impact.
+- Speculative findings based only on static analysis or an automated tool's
+  assessment, without a verified reproduction and credible attack scenario.
+
+These may still be valid bugs and may be considered through the normal issue
+tracker. Please coordinate before making any potentially exploitable details
+public. Classification as a bug does not guarantee a fix or a particular
+priority.
+
+### Automated and AI-Assisted Reports
+
+Automated analysis and AI tools are welcome as research aids, but the person
+submitting a report is responsible for verifying its claims. **Do not submit
+bulk, unverified, or speculative AI-generated findings.** Test each finding
+against a supported release and establish the actual security impact. Reports
+that do not meet the requirements above may be closed without further
+investigation or individual feedback; they can be resubmitted with stronger
+evidence.
+
+## Triage and Disclosure
+
+mailparser is maintained by a small team, and there is **no guaranteed response
+or resolution time**. Reports are prioritized based on demonstrated impact,
+exploitability, affected usage, and available maintenance resources.
+
+A private report does not automatically become a security advisory. Confirmed
+vulnerabilities may be fixed and disclosed through GitHub Security Advisories;
+other findings may be closed, deferred, or handled as ordinary bugs. Please do
+not disclose details of an unresolved, potentially exploitable issue publicly
+without coordinating with the maintainers.
+
+## CVEs and Credit
+
+We do not request or manage CVE identifiers. A report being acknowledged, a bug
+being fixed, or a pull request being merged does **not** mean that mailparser
+has confirmed a security vulnerability or endorsed a CVE assignment. We do not
+guarantee advisories, CVE identifiers, or public credit for reports. For
+confirmed vulnerabilities disclosed through an advisory, substantive reporters
+may be credited if they wish.
 
 ## Scope
 
-In scope: the mailparser library source in this repository - the streaming MIME
+In scope: the mailparser library source in this repository: the streaming MIME
 parser (`MailParser`), the convenience parser (`simpleParser`), header and
-address decoding, charset/transfer-encoding handling, and attachment and HTML/
-text extraction. Of particular interest are inputs that cause unbounded resource
-consumption, catastrophic regular-expression backtracking, prototype pollution,
-or process crashes.
+address decoding, charset and transfer-encoding handling, and attachment and
+HTML/text extraction. Of particular interest are small crafted inputs that cause
+amplified resource consumption, catastrophic regular-expression backtracking,
+prototype pollution, or process crashes.
 
 Out of scope:
 
@@ -78,13 +156,11 @@ Out of scope:
   Parsed email content is attacker-controlled data; you must sanitize and escape
   it before rendering, storing, or executing it. In particular, the `html` field
   is not sanitized for safe display in a browser.
-- Vulnerabilities in third-party dependencies that are already tracked and fixed
-  upstream - report those to the respective project (we will still bump the
-  dependency once a fix is available).
-- Issues that require an already-compromised host or a malicious local
-  environment.
 - Resource consumption that is proportional to a legitimately large input (for
   example, parsing a genuine 100MB message uses memory) rather than amplified by
   a crafted small input.
+- Vulnerabilities in third-party dependencies that are already tracked upstream
+  (we will still bump the dependency once a fix is available).
+- Social-engineering reports.
 
 Thank you for helping keep mailparser and its users safe.

package/node_modules/mailparser/package.json

@@ -1,6 +1,6 @@
 {
     "name": "mailparser",
-    "version": "3.9.38",
+    "version": "3.9.39",
     "description": "Parse e-mails",
     "main": "index.js",
     "scripts": {
@@ -22,10 +22,10 @@
         "he": "1.2.0",
         "html-to-text": "10.0.1",
         "iconv-lite": "0.7.3",
-        "libmime": "5.4.7",
+        "libmime": "5.4.8",
         "linkify-it": "5.0.2",
-        "@zone-eu/mailsplit": "5.4.20",
-        "nodemailer": "10.1.0",
+        "@zone-eu/mailsplit": "5.4.21",
+        "nodemailer": "10.1.1",
         "punycode.js": "2.3.1",
         "tlds": "1.261.0"
     },
@@ -41,7 +41,7 @@
         "grunt-contrib-nodeunit": "5.0.0",
         "grunt-eslint": "27.0.0",
         "iconv": "3.0.1",
-        "prettier": "3.9.9",
+        "prettier": "3.9.10",
         "random-message": "1.1.0"
     },
     "repository": {

package/node_modules/nodemailer/CHANGELOG.md

@@ -1,5 +1,12 @@
 # CHANGELOG
 
+## [10.1.1](https://github.com/nodemailer/nodemailer/compare/v10.1.0...v10.1.1) (2026-10-14)
+
+
+### Bug Fixes
+
+* **fetch:** strip credentials on any cross-origin redirect ([a15360c](https://github.com/nodemailer/nodemailer/commit/a15360cd2cd12e4670e96ab0b7290e8c862391cf))
+
 ## [10.1.0](https://github.com/nodemailer/nodemailer/compare/v10.0.16...v10.1.0) (2026-10-10)
 
 

package/node_modules/nodemailer/SECURITY.md

@@ -1,7 +1,9 @@
 # Security Policy
 
-Nodemailer is a widely deployed, zero-dependency e-mail library. We take security
-reports seriously and aim to respond quickly.
+Nodemailer is a widely deployed, zero-dependency email library. We welcome
+responsible reports of vulnerabilities that present a credible security risk to
+users. Please distinguish security vulnerabilities from ordinary bugs, unusual
+edge cases, and hardening suggestions.
 
 ## Supported Versions
 
@@ -17,45 +19,119 @@ the supported way to receive security updates.
 If you are on an older major, please upgrade. See the migration notes at
 <https://nodemailer.com/> before updating.
 
-## Reporting a Vulnerability
+## What Qualifies as a Security Vulnerability
 
-**Please do not report security vulnerabilities through public GitHub issues,
-pull requests, or discussions.**
+A security report should identify a realistic way for an attacker to cross a
+security boundary in a supported version of Nodemailer. Unexpected behavior,
+a failing test, or a technically correct proof of concept is not sufficient on
+its own to establish security impact.
 
-Report privately through one of the following channels:
+In particular, explain:
 
-1. **GitHub Security Advisories (preferred).** Open a private report at
-   <https://github.com/nodemailer/nodemailer/security/advisories/new>. This keeps
-   the discussion private until a fix is published and lets us credit you.
-2. **Email.** Send details to **andris@reinman.eu** (the contact listed in
-   [`SECURITY.txt`](SECURITY.txt)). Encrypt sensitive details if possible.
+- **Attacker capabilities:** Who is the attacker, and what inputs, systems, or
+  responses can they control _without_ already having the privileges or secrets
+  they are trying to gain?
+- **Attack path:** How does attacker-controlled input reach the affected code
+  through a supported Nodemailer API or a realistic application integration?
+- **Prerequisites:** What configuration and user actions are required? If the
+  attack depends on unusual options or deliberately malformed input, explain
+  why those conditions could arise in a real application.
+- **Impact:** What confidentiality, integrity, or availability boundary is
+  crossed, and what can the attacker achieve as a result?
 
-When reporting, please include as much of the following as you can:
+A vulnerability involving an optional or less common feature can still qualify
+if these conditions are met. Conversely, the existence of a defensive check in
+the code does not, by itself, establish that every bypass of that check has a
+realistic security impact.
 
-- The affected version(s) and environment (Node.js version, OS).
-- The component involved (e.g. SMTP connection, address parsing, MIME/header
-  generation, DKIM).
-- A clear description of the issue and its impact (e.g. header/SMTP command
-  injection, information disclosure, DoS).
-- A minimal proof of concept or reproduction steps.
-- Any suggested remediation, if you have one.
+## Reporting a Vulnerability
 
-Nodemailer is maintained by a single person, so there is no guaranteed response
-time: sometimes reports are handled within hours, sometimes they take longer.
-Accepted issues are fixed in a new release and coordinated through a GitHub
-Security Advisory, and reporters who wish to be named are credited.
+**Do not disclose suspected exploitable vulnerabilities through public GitHub
+issues, pull requests, or discussions before coordinating with the maintainer.**
 
-## CVEs
+Report privately through one of the following channels:
 
-We track and disclose vulnerabilities through GitHub Security Advisories. We do
-not request or manage CVE identifiers ourselves. If you need a CVE assigned for a
-reported issue, please request one yourself, for example through GitHub's own
-CVE request flow on the published advisory, or another CNA.
+1. **GitHub Security Advisories (preferred):**
+   <https://github.com/nodemailer/nodemailer/security/advisories/new>.
+2. **Email:** **andris@reinman.eu**, as listed in
+   [`SECURITY.txt`](SECURITY.txt). Encrypt sensitive details if possible.
+
+### Required Information
+
+Please provide enough information to evaluate both the defect and its security
+impact. Reports should include:
+
+1. The affected Nodemailer version or commit, Node.js version, and relevant
+   configuration.
+2. A concise description of the issue and the affected public API or code path.
+3. A minimal, tested reproduction, including steps to run it, expected behavior,
+   and observed behavior.
+4. A concrete threat model: attacker control, prerequisites, trust boundary, and
+   resulting impact. Clearly distinguish what your reproduction proves from what
+   you believe might be possible.
+5. An explanation of why the issue affects applications beyond a deliberately
+   constructed test setup, where this is not obvious.
+
+A suggested fix is welcome but does not replace an explanation of exploitability.
+A complete real-world exploit is not always necessary, but the report must make
+a credible security impact clear.
+
+### Reports That May Be Treated as Ordinary Bugs
+
+The following generally do **not** qualify for private security handling unless
+you can demonstrate an additional, meaningful security boundary crossing:
+
+- Issues that require the attacker to control trusted application code,
+  administrator-only configuration, or the secret they supposedly extract.
+- Problems caused solely by application-level misuse, exposed credentials, or
+  insecure deployment choices outside Nodemailer's control.
+- Contrived proof-of-concept setups where the tester controls both sides of a
+  request, without explaining how a separate attacker could trigger the issue.
+- Parser quirks, unexpected behavior, and bypasses of internal checks with no
+  demonstrated security impact.
+- Speculative findings based only on static analysis or an automated tool's
+  assessment, without a verified reproduction and credible attack scenario.
+
+These may still be valid bugs and may be considered through the normal issue
+tracker. Please coordinate before making any potentially exploitable details
+public. Classification as a bug does not guarantee a fix or a particular
+priority.
+
+### Automated and AI-Assisted Reports
+
+Automated analysis and AI tools are welcome as research aids, but the person
+submitting a report is responsible for verifying its claims. **Do not submit
+bulk, unverified, or speculative AI-generated findings.** Test each finding
+against a supported release and establish the actual security impact. Reports
+that do not meet the requirements above may be closed without further
+investigation or individual feedback; they can be resubmitted with stronger
+evidence.
+
+## Triage and Disclosure
+
+Nodemailer is maintained by a single person, and there is **no guaranteed
+response or resolution time**. Reports are prioritized based on demonstrated
+impact, exploitability, affected usage, and available maintenance resources.
+
+A private report does not automatically become a security advisory. Confirmed
+vulnerabilities may be fixed and disclosed through GitHub Security Advisories;
+other findings may be closed, deferred, or handled as ordinary bugs. Please do
+not disclose details of an unresolved, potentially exploitable issue publicly
+without coordinating with the maintainer.
+
+## CVEs and Credit
+
+We do not request or manage CVE identifiers. A report being acknowledged, a bug
+being fixed, or a pull request being merged does **not** mean that Nodemailer
+has confirmed a security vulnerability or endorsed a CVE assignment. We do not
+guarantee advisories, CVE identifiers, or public credit for reports. For
+confirmed vulnerabilities disclosed through an advisory, substantive reporters
+may be credited if they wish.
 
 ## Scope
 
 In scope: the `nodemailer` package source in this repository: message and MIME
-generation, SMTP/LMTP client behaviour, address parsing, header handling, DKIM
+generation, SMTP/LMTP client behavior, address parsing, header handling, DKIM
 signing, and the bundled transports.
 
 Out of scope: vulnerabilities in your own application code, misconfiguration of

package/node_modules/nodemailer/dist/cjs/fetch/index.js

@@ -116,6 +116,10 @@ function parseFetchUrl(url) {
     }
     return parsed;
 }
+// the port a request to the URL goes to, explicit or the default of its scheme
+function fetchPort(parsed) {
+    return parsed.port ? Number(parsed.port) : parsed.protocol === 'https:' ? 443 : 80;
+}
 function nmfetch(url, options) {
     options = options || {};
     options.fetchRes = options.fetchRes || new node_stream_1.PassThrough();
@@ -232,7 +236,7 @@ function nmfetch(url, options) {
         method,
         host: parsed.hostname,
         path: parsed.path,
-        port: parsed.port ? parsed.port : parsed.protocol === 'https:' ? 443 : 80,
+        port: fetchPort(parsed),
         headers,
         // Validate TLS certificates by default. Callers that genuinely need to
         // reach a self-signed/internal host opt out explicitly with
@@ -334,17 +338,19 @@ function nmfetch(url, options) {
                 // the shared fetchRes once it times out. Callers listen with req.once().
                 return fail(new Error('Unsupported protocol for URL ' + redirectUrl), redirectUrl);
             }
-            // Do not forward credentials when the redirect leaves the original
-            // security context: a different host, or a downgrade from https to
-            // http (which would otherwise put them on the wire in cleartext).
-            // Strip sensitive request headers so an attacker who controls the
-            // redirect target cannot harvest them.
-            const crossHost = redirectParsed.hostname !== parsed.hostname;
-            const downgrade = parsed.protocol === 'https:' && redirectParsed.protocol === 'http:';
-            if (options.headers && (crossHost || downgrade)) {
+            // Do not forward credentials when the redirect leaves the origin: a different
+            // scheme, host or port is a different security context (an https to http
+            // downgrade would also put them on the wire in cleartext). Strip sensitive
+            // request headers so an attacker who controls the redirect target cannot
+            // harvest them.
+            const crossOrigin = redirectParsed.protocol !== parsed.protocol ||
+                redirectParsed.hostname !== parsed.hostname ||
+                fetchPort(redirectParsed) !== fetchPort(parsed);
+            if (options.headers && crossOrigin) {
                 const sensitive = ['authorization', 'cookie', 'proxy-authorization'];
                 Object.keys(options.headers).forEach(key => {
-                    if (sensitive.includes(key.toLowerCase())) {
+                    // normalized the way the request headers are built above, a padded name is sent too
+                    if (sensitive.includes(key.toLowerCase().trim())) {
                         delete options.headers[key];
                     }
                 });

package/node_modules/nodemailer/dist/cjs/package-info.d.ts

@@ -1,3 +1,3 @@
 export declare const name = "nodemailer";
-export declare const version = "10.1.0";
+export declare const version = "10.1.1";
 export declare const homepage = "https://nodemailer.com/";

package/node_modules/nodemailer/dist/cjs/package-info.js

@@ -3,5 +3,5 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.homepage = exports.version = exports.name = void 0;
 exports.name = 'nodemailer';
-exports.version = '10.1.0';
+exports.version = '10.1.1';
 exports.homepage = 'https://nodemailer.com/';

package/node_modules/nodemailer/dist/esm/fetch/index.js

@@ -78,6 +78,10 @@ function parseFetchUrl(url) {
     }
     return parsed;
 }
+// the port a request to the URL goes to, explicit or the default of its scheme
+function fetchPort(parsed) {
+    return parsed.port ? Number(parsed.port) : parsed.protocol === 'https:' ? 443 : 80;
+}
 function nmfetch(url, options) {
     options = options || {};
     options.fetchRes = options.fetchRes || new PassThrough();
@@ -194,7 +198,7 @@ function nmfetch(url, options) {
         method,
         host: parsed.hostname,
         path: parsed.path,
-        port: parsed.port ? parsed.port : parsed.protocol === 'https:' ? 443 : 80,
+        port: fetchPort(parsed),
         headers,
         // Validate TLS certificates by default. Callers that genuinely need to
         // reach a self-signed/internal host opt out explicitly with
@@ -296,17 +300,19 @@ function nmfetch(url, options) {
                 // the shared fetchRes once it times out. Callers listen with req.once().
                 return fail(new Error('Unsupported protocol for URL ' + redirectUrl), redirectUrl);
             }
-            // Do not forward credentials when the redirect leaves the original
-            // security context: a different host, or a downgrade from https to
-            // http (which would otherwise put them on the wire in cleartext).
-            // Strip sensitive request headers so an attacker who controls the
-            // redirect target cannot harvest them.
-            const crossHost = redirectParsed.hostname !== parsed.hostname;
-            const downgrade = parsed.protocol === 'https:' && redirectParsed.protocol === 'http:';
-            if (options.headers && (crossHost || downgrade)) {
+            // Do not forward credentials when the redirect leaves the origin: a different
+            // scheme, host or port is a different security context (an https to http
+            // downgrade would also put them on the wire in cleartext). Strip sensitive
+            // request headers so an attacker who controls the redirect target cannot
+            // harvest them.
+            const crossOrigin = redirectParsed.protocol !== parsed.protocol ||
+                redirectParsed.hostname !== parsed.hostname ||
+                fetchPort(redirectParsed) !== fetchPort(parsed);
+            if (options.headers && crossOrigin) {
                 const sensitive = ['authorization', 'cookie', 'proxy-authorization'];
                 Object.keys(options.headers).forEach(key => {
-                    if (sensitive.includes(key.toLowerCase())) {
+                    // normalized the way the request headers are built above, a padded name is sent too
+                    if (sensitive.includes(key.toLowerCase().trim())) {
                         delete options.headers[key];
                     }
                 });

package/node_modules/nodemailer/dist/esm/package-info.d.ts

@@ -1,3 +1,3 @@
 export declare const name = "nodemailer";
-export declare const version = "10.1.0";
+export declare const version = "10.1.1";
 export declare const homepage = "https://nodemailer.com/";

package/node_modules/nodemailer/dist/esm/package-info.js

@@ -1,4 +1,4 @@
 // Generated by scripts/build.js from package.json. Do not edit by hand.
 export const name = 'nodemailer';
-export const version = '10.1.0';
+export const version = '10.1.1';
 export const homepage = 'https://nodemailer.com/';

package/node_modules/nodemailer/package.json

@@ -1,6 +1,6 @@
 {
     "name": "nodemailer",
-    "version": "10.1.0",
+    "version": "10.1.1",
     "description": "Easy as cake e-mail sending from your Node.js applications",
     "type": "module",
     "main": "./dist/cjs/nodemailer.js",
@@ -151,7 +151,7 @@
     },
     "homepage": "https://nodemailer.com/",
     "devDependencies": {
-        "@aws-sdk/client-sesv2": "3.1146.0",
+        "@aws-sdk/client-sesv2": "3.1151.0",
         "@types/node": "20.19.43",
         "bunyan": "1.8.15",
         "c8": "12.0.0",
@@ -161,14 +161,14 @@
         "libbase64": "1.3.2",
         "libmime": "5.4.7",
         "libqp": "2.1.2",
-        "mailauth": "7.1.1",
-        "prettier": "3.9.9",
+        "mailauth": "7.3.0",
+        "prettier": "3.9.10",
         "proxy": "1.0.2",
         "proxy-test-server": "1.0.0",
-        "smtp-server": "3.19.17",
+        "smtp-server": "3.19.21",
         "tsx": "4.23.15",
         "typescript": "6.0.3",
-        "typescript-eslint": "8.71.1"
+        "typescript-eslint": "8.71.2"
     },
     "engines": {
         "node": ">=20.0.0"

package/package.json

@@ -79,15 +79,15 @@
     "constructs": "^10.5.1"
   },
   "dependencies": {
-    "@aws-sdk/client-cloudwatch-logs": "^3.1151.0",
-    "@aws-sdk/client-route-53": "^3.1151.0",
-    "@aws-sdk/client-s3": "^3.1151.0",
-    "@aws-sdk/client-ses": "^3.1151.0",
-    "@aws-sdk/client-ssm": "^3.1151.0",
+    "@aws-sdk/client-cloudwatch-logs": "^3.1152.0",
+    "@aws-sdk/client-route-53": "^3.1152.0",
+    "@aws-sdk/client-s3": "^3.1152.0",
+    "@aws-sdk/client-ses": "^3.1152.0",
+    "@aws-sdk/client-ssm": "^3.1152.0",
     "@mavogel/mvc-projen": "^0.0.60",
     "cdk-nag": "^3.0.1",
     "constructs": "^10.5.1",
-    "mailparser": "^3.9.38",
+    "mailparser": "^3.9.39",
     "uuid": "^14.0.3"
   },
   "bundledDependencies": [
@@ -122,7 +122,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "0.1.20",
+  "version": "0.1.21",
   "jest": {
     "coverageProvider": "v8",
     "transformIgnorePatterns": [