imapflow 2.4.0 → 2.4.2

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # Changelog
 
+## [2.4.2](https://github.com/postalsys/imapflow/compare/v2.4.1...v2.4.2) (2026-10-14)
+
+
+### Bug Fixes
+
+* **deps:** update libmime to 5.4.8 and mailsplit to 5.4.21 ([8eafb46](https://github.com/postalsys/imapflow/commit/8eafb46f858893670dda1be115899b8b761391ab))
+
+## [2.4.1](https://github.com/postalsys/imapflow/compare/v2.4.0...v2.4.1) (2026-10-14)
+
+
+### Bug Fixes
+
+* **download:** bump libbase64 to decode padded base64 parts in linear memory ([1c83261](https://github.com/postalsys/imapflow/commit/1c832614dda83160de1387f08e7592add65e2779))
+
 ## [2.4.0](https://github.com/postalsys/imapflow/compare/v2.3.0...v2.4.0) (2026-10-10)
 
 

package/SECURITY.md

@@ -1,88 +1,159 @@
 # Security Policy
 
-ImapFlow is a Node.js IMAP client library. It opens TLS/cleartext connections to
-IMAP servers, sends account credentials, and parses untrusted protocol responses
-from those servers. Because it handles credentials and processes data from
-remote servers that may be malicious or buggy, we take security reports
-seriously and aim to respond quickly.
+ImapFlow is a Node.js IMAP client library. It opens TLS and cleartext
+connections to IMAP servers, sends account credentials, and parses untrusted
+protocol responses from servers that may be malicious or buggy. 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 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          |
 | ------- | ------------------ |
-| 1.x     | :white_check_mark: |
-| < 1.0   | :x:                |
+| 2.x     | :white_check_mark: |
+| < 2.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/postalsys/imapflow/releases> 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 ImapFlow. 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
 
-**Please do not report security vulnerabilities through public GitHub issues,
-pull requests, or discussions.**
+**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).** Open a private report at
-   <https://github.com/postalsys/imapflow/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 with the PGP key
-   referenced there if possible.
-
-When reporting, please include as much of the following as you can:
-
-- The affected version(s) and environment (ImapFlow version, Node.js version,
-  OS).
-- The component involved (e.g. the IMAP response stream/parser, literal and line
-  handling, TLS/STARTTLS upgrade, credential handling, the command compiler, or
-  the public client API).
-- A clear description of the issue and its impact (e.g. memory exhaustion or
-  denial of service from a malicious server, parser crash, credential
-  disclosure, TLS verification bypass, injection into the IMAP command stream,
-  prototype pollution, information disclosure).
-- A minimal proof of concept or reproduction steps - ideally a sample server
-  response or a short script that triggers the issue.
-- Any suggested remediation, if you have one.
-
-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.
-
-## CVEs
-
-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/postalsys/imapflow/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 ImapFlow version or commit, Node.js version, and relevant
+   configuration.
+2. A concise description of the issue and the affected public API or code path
+   (for example the IMAP response stream and parser, literal and line handling,
+   the TLS/STARTTLS upgrade, credential handling, the command compiler, or the
+   public client API. A sample server response is often 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 ImapFlow'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
+
+ImapFlow 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 ImapFlow 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 ImapFlow library source in this repository - the IMAP response
+In scope: the ImapFlow library source in this repository: the IMAP response
 stream and token parser (including handling of hostile or malformed server
-responses, literals, line lengths, and resource/DoS bounds), the TLS and
-STARTTLS upgrade path and certificate handling, credential handling during
+responses, literals, line lengths, and resource bounds), the TLS and STARTTLS
+upgrade path and certificate handling, credential handling during
 authentication, the command compiler that builds outgoing IMAP commands, and the
 public client API.
 
 Out of scope:
 
 - Vulnerabilities in your own application code that uses ImapFlow.
-- Misconfiguration of your usage - for example, disabling TLS certificate
+- Misconfiguration of your usage, for example disabling TLS certificate
   verification (`tls.rejectUnauthorized: false`), connecting over cleartext when
   TLS is available, or passing untrusted input directly into mailbox paths or
   command arguments without validation.
-- Vulnerabilities in the IMAP servers you connect to, or in third-party
-  dependencies (please report those to their respective maintainers; we will
-  upgrade once a fix is available).
+- Vulnerabilities in the IMAP servers you connect to.
 - Issues that require an already-compromised host or local access to the machine
   running ImapFlow.
-- Social-engineering reports and theoretical issues without a demonstrated,
-  concrete impact.
+- Social-engineering reports.
 
 Thank you for helping keep ImapFlow and its users safe.

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

@@ -1,3 +1,3 @@
 export declare const name = "imapflow";
-export declare const version = "2.4.0";
+export declare const version = "2.4.2";
 export declare const homepage = "https://imapflow.com/";

package/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 = "imapflow";
-exports.version = "2.4.0";
+exports.version = "2.4.2";
 exports.homepage = "https://imapflow.com/";

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

@@ -1,3 +1,3 @@
 export declare const name = "imapflow";
-export declare const version = "2.4.0";
+export declare const version = "2.4.2";
 export declare const homepage = "https://imapflow.com/";

package/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 = "imapflow";
-export const version = "2.4.0";
+export const version = "2.4.2";
 export const homepage = "https://imapflow.com/";

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "imapflow",
-    "version": "2.4.0",
+    "version": "2.4.2",
     "description": "IMAP Client for Node",
     "type": "module",
     "main": "./dist/cjs/imap-flow.js",
@@ -76,19 +76,19 @@
         "eslint-config-prettier": "10.1.8",
         "globals": "17.13.0",
         "imapkit": "5.0.1",
-        "prettier": "3.9.9",
+        "prettier": "3.9.10",
         "tsx": "4.23.15",
         "types-node-legacy": "npm:@types/node@20.0.0",
         "typescript": "6.0.3",
-        "typescript-eslint": "8.71.1",
-        "wrangler": "4.149.0"
+        "typescript-eslint": "8.71.2",
+        "wrangler": "4.151.0"
     },
     "dependencies": {
-        "@zone-eu/mailsplit": "5.4.20",
+        "@zone-eu/mailsplit": "5.4.21",
         "encoding-japanese": "2.4.0",
         "iconv-lite": "0.7.3",
-        "libbase64": "1.3.2",
-        "libmime": "5.4.7",
+        "libbase64": "1.3.3",
+        "libmime": "5.4.8",
         "libqp": "2.1.2",
         "pino": "10.3.1",
         "socks": "2.8.10"