CVE-2026-23829: Github.com/axllent/mailpit Mailpit Has An SMTP Header Vulnerability

MODERATE
Advisory Identifier: GHSA-54wq-72mp-cq7c
CVSS 5.3
CWE-150 CWE-93
Published
Advisory Summary

CVE-2026-23829 is a MODERATE (CVSS 5.3) mailpit has an smtp header vulnerability (CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences) affecting Github.com/axllent/mailpit libraries in the Go ecosystem. The issue involves mailpit has an smtp header injection via regex bypass. Remediation is available by upgrading affected packages to version 1.28.3.

CVE-2026-23829 at a Glance

CVE Identifier CVE-2026-23829
GHSA Identifier GHSA-54wq-72mp-cq7c
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Affected Product Github.com/axllent/mailpit
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-23829

To remediate this vulnerability, upgrade all affected Github.com/axllent/mailpit dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/axllent/mailpit fixed: 1.28.3
Upgrade github.com/axllent/mailpit to 1.28.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/axllent/mailpit

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-23829, inspect your project dependencies for Github.com/axllent/mailpit:

inspect dependencies for github.com/axllent/mailpit

Analyze the terminal output to locate any version of Github.com/axllent/mailpit in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.28.3), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences, where the product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component. In Github.com/axllent/mailpit, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# Vulnerability Report: SMTP Header Injection via Regex Bypass **Vulnerable Code:** `mailpit/internal/smtpd/smtpd.go` ## Executive Summary Mailpit's SMTP server is vulnerable to **Header Injection** due to an insufficient Regular Expression used to validate `RCPT TO` and `MAIL FROM` addresses. An attacker can inject arbitrary SMTP headers (or corrupt existing ones) by including carriage return characters (`\r`) in the email address. This header injection occurs because the regex intended to filter control characters fails to exclude `\r` and `\n` when used inside a character class. ## RFC Compliance & Design Analysis **"Is this behavior intentional for a testing tool?"** No. While testing tools are often permissive, this specific behavior violates the core SMTP protocol and fails the developer's own intent. 1. **RFC 5321 Violation:** The SMTP protocol strictly forbids Control Characters (CR, LF, Null) in the envelope address (`Mailbox`). * *RFC 5321 Section 4.1.2:* A `Mailbox` consists of an `Atom` or `Quoted-string`. An `Atom` explicitly excludes "specials, SPACE and CTLs" (Control Characters). 2. **Failed Intent:** The existence of `\v` in the regex `[^<>\v]` proves the developer **intended** to block vertical whitespace. The vulnerability is that `\v` in Go regex (`re2`) inside brackets `[]` matches *only* Vertical Tab, not CR/LF. If the design were to allow everything, the `\v` exclusion wouldn't exist. 3. **Data Corruption:** Allowing `\r` results in the generation of malformed `.eml` files where the `Received` header is broken. This is not a feature; it's a bug that creates invalid email files. 4. RFC 5321 also enforces address lengths which are not applied in Mailpit. ## Technical Analysis ### The Flaw The vulnerability exists in the regex definitions used to parse SMTP commands: ```go // internal/smtpd/smtpd.go:32-33 rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\v]+)>( |$)(.*)?`) mailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\v]+)>( |$)(.*)?`) ``` The developer likely intended `[^<>\v]` to mean "Match anything that is NOT a `<` OR `>` OR `Vertical Whitespace`". However, in Go's `regexp` (RE2) syntax, the behavior of `\v` changes depending on context: - **Outside** brackets: `\v` matches all vertical whitespace: `[\n\v\f\r\x85\u2028\u2029]`. - **Inside** brackets (`[...]`): `\v` matches **only** the Vertical Tab character (`\x0B`). **Result:** The regex `[^<>\v]` **allows** Carriage Return (`\r`) and Line Feed (`\n`) characters to pass through, as they are not `<` or `>` or `\x0B`. ### Exploit Scenario ### Exploit Scenario When Mailpit constructs the `Received` header, it uses the validated recipient address directly: ```go // internal/smtpd/smtpd.go:865 buffer.WriteString(fmt.Sprintf(" for <%s>; %s\r\n", to[0], now)) ``` If `to[0]` contains `victim\rINJECTED-HEADER: YES`, the resulting string in memory becomes: ```text for <victim\rINJECTED-HEADER: YES>; ... ``` While `bufio.ReadString` prevents injecting immediate `\n` (newlines), `\r` (Carriage Return) bypasses this check. **The Result:** The stored EML file contains a "Bare CR". - **RFC Violation:** RFC 5321 strictly forbids Bare CR. Lines must end in CRLF. - **UI Behavior:** Browsers typically render Bare CR as a space, so it may look like `victim INJECTED` in the Mailpit UI. - **Real Impact:** The raw email is corrupted. If this email is exported or relayed, downstream systems (Outlook, older MTAs) may interpret the Bare CR as a line break, triggering a full **Header Injection**. Furthermore, Mailpit failing to reject this gives developers a **false sense of security**, as their code might be generating malformed emails that work in Mailpit but fail in production (e.g., with Gmail or Exchange). ### Raw EML Verification The following screenshot of the raw `.eml` file confirms that the `\r` character successfully broke the `Received` header structure in the stored file, effectively creating a new line for the injected content. <img width="621" height="230" alt="image" src="https://github.com/user-attachments/assets/1611f07e-316d-436a-95d6-9b14c9a8ecc6" /> <img width="1058" height="441" alt="image" src="https://github.com/user-attachments/assets/9543d904-6e0a-4c8b-b283-abbe05b752d0" /> <img width="668" height="196" alt="image" src="https://github.com/user-attachments/assets/907e4467-aab6-4bb4-83ce-743af4f6ba8d" /> As seen in lines of the screenshot: ```text for <victim INJECTED_VIA_CR:YES>; Tue, 13 Jan ... ``` The `INJECTED_VIA_CR:YES` payload is treated as a start of a new line by the text editor (VS Code), which honors `\r` as a line break. This proves the injection matches the "Bare CR" attack vector. ## Additional Proof of Concepts ### 1. Null Byte Injection (`\x00`) The regex `[^<>\v]+` also allows the Null Byte (`\x00`). **Test:** `test_null_byte.py` sent `RCPT TO:<victim\x00-NULL-BYTE-HERE>`. **Result:** Server accepted the message (`250 OK`). **Impact:** The API returns an empty `[]` for the To field in the message summary, indicating the parser failure in the UI/API layer. The raw message content confirms the Null Byte is stored in the database. ### 3. Detailed Character Compatibility Tests (0-127 ASCII) confirm that the regex `[^<>\v]` blocks **only** the following: - `<` (Less Than) - `>` (Greater Than) - `\x0B` (Vertical Tab) **Crucially, it ALLOWS:** | Character | Hex | Regex Status | Network Status | Impact | | :--- | :--- | :--- | :--- | :--- | | **Carriage Return** | `\r` (`0x0D`) | **ALLOWED** | **Passed** | **Header Injection** | | **Line Feed** | `\n` (`0x0A`) | **ALLOWED** | Blocked* | *Blocked by `bufio.ReadString`, not regex. | | **Null Byte** | `\x00` (`0x00`) | **ALLOWED** | **Passed** | API DoS / Corrupt Data | | **Tab** | `\t` (`0x09`) | **ALLOWED** | **Passed** | Formatting issues | | **Delete** | `\x7F` (`0x7F`) | **ALLOWED** | **Passed** | Potential obfuscation | | **Controls** | `0x01`-`0x1F` | **ALLOWED** | **Passed** | (Except `0x0A`, `0x0B`, `0x0D`) | *This confirms that the regex fails to implement a proper "Safe Text" allowlist, defaulting instead to a flawed denylist.* ## Proof of Concept The following Python script demonstrates the injection of a "bare CR" into the headers, which is successfully accepted by the server. ```python import socket def exploit(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 1025)) s.recv(1024) s.send(b"EHLO test.com\r\n") s.recv(1024) s.send(b"MAIL FROM:<attacker@evil.com>\r\n") s.recv(1024) # Injecting \r payload = b"RCPT TO:<victim\rX-Injected: Yes>\r\n" s.send(payload) resp = s.recv(1024) print(f"Server Response: {resp.decode()}") # Expect 250 OK s.send(b"DATA\r\n") s.recv(1024) s.send(b"Subject: Test\r\n\r\nBody\r\n.\r\n") s.recv(1024) s.close() exploit() ``` ## Remediation Update the regex to explicitly exclude `\r` and `\n`, or use the correct character class escape for control characters. **Recommended Fix:** Use `\x00-\x1F` to exclude all ASCII control characters. ```go // Fix: Exclude all control characters explicitly rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\x00-\x1f]+)>( |$)(.*)?`) mailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\x00-\x1f]+)>( |$)(.*)?`) ``` Alternatively, strictly exclude CR and LF: ```go rcptToRE = regexp.MustCompile(`(?i)TO: ?<([^<>\r\n]+)>( |$)(.*)?`) ``` ## Classification & References - **CWE-93:** [Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html) - **CWE-150:** [Improper Neutralization of Escape, Meta, or Control Sequences](https://cwe.mitre.org/data/definitions/150.html) - **OWASP:** [Injection Flaws](https://owasp.org/www-community/attacks/Injection_Flaws) - **CAPEC-106:** [Command Injection](https://capec.mitre.org/data/definitions/106.html) (Related usage pattern) - [[RFC 5321 Section 4.5.3.1 - Size Limits](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1)](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1)

CVE-2026-23829 Affected Github.com/axllent/mailpit Versions

1 component(s)
Fixed Versions:
1.28.3
Product / Package Ecosystem Affected Versions Fixed Version
github.com/axllent/mailpit
Go
< 1.28.3
1.28.3

References

Frequently Asked Questions

What is CVE-2026-23829?
CVE-2026-23829 is a security vulnerability in Github.com/axllent/mailpit involving Mailpit has an SMTP Header Injection via Regex Bypass under CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences.
Which Github.com/axllent/mailpit versions are affected?
Affected versions include releases prior to 1.28.3 across affected packages: github.com/axllent/mailpit.
What version fixes CVE-2026-23829?
Upgrading to 1.28.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/axllent/mailpit affected?
Yes, github.com/axllent/mailpit is affected in releases prior to 1.28.3. Upgrade your dependency to 1.28.3 or later.
What is the CVSS score of CVE-2026-23829?
CVE-2026-23829 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.
What CWE is associated with CVE-2026-23829?
CVE-2026-23829 is classified under CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences (The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as escape, meta, or control character sequences when they are sent to a downstream component.).
How can I check Go dependencies for CVE-2026-23829?
Run the dependency tree command: 'inspect dependencies for github.com/axllent/mailpit'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-54wq-72mp-cq7c",
  "modified" : "2026-02-02T14:50:34Z",
  "published" : "2026-01-20T17:54:55Z",
  "aliases" : [ "CVE-2026-23829" ],
  "summary" : "Mailpit has an SMTP Header Injection via Regex Bypass",
  "details" : "# Vulnerability Report: SMTP Header Injection via Regex Bypass\n\n**Vulnerable Code:** `mailpit/internal/smtpd/smtpd.go`\n\n## Executive Summary\nMailpit's SMTP server is vulnerable to **Header Injection** due to an insufficient Regular Expression used to validate `RCPT TO` and `MAIL FROM` addresses. An attacker can inject arbitrary SMTP headers (or corrupt existing ones) by including carriage return characters (`\\r`) in the email address. This header injection occurs because the regex intended to filter control characters fails to exclude `\\r` and `\\n` when used inside a character class.\n\n## RFC Compliance & Design Analysis\n**\"Is this behavior intentional for a testing tool?\"**\nNo. While testing tools are often permissive, this specific behavior violates the core SMTP protocol and fails the developer's own intent.\n\n1.  **RFC 5321 Violation:** The SMTP protocol strictly forbids Control Characters (CR, LF, Null) in the envelope address (`Mailbox`).\n    *   *RFC 5321 Section 4.1.2:* A `Mailbox` consists of an `Atom` or `Quoted-string`. An `Atom` explicitly excludes \"specials, SPACE and CTLs\" (Control Characters).\n2.  **Failed Intent:** The existence of `\\v` in the regex `[^<>\\v]` proves the developer **intended** to block vertical whitespace. The vulnerability is that `\\v` in Go regex (`re2`) inside brackets `[]` matches *only* Vertical Tab, not CR/LF. If the design were to allow everything, the `\\v` exclusion wouldn't exist.\n3.  **Data Corruption:** Allowing `\\r` results in the generation of malformed `.eml` files where the `Received` header is broken. This is not a feature; it's a bug that creates invalid email files.\n4. RFC 5321 also enforces address lengths which are not applied in Mailpit.\n\n## Technical Analysis\n\n### The Flaw\nThe vulnerability exists in the regex definitions used to parse SMTP commands:\n\n```go\n// internal/smtpd/smtpd.go:32-33\nrcptToRE   = regexp.MustCompile(`(?i)TO: ?<([^<>\\v]+)>( |$)(.*)?`)\nmailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\\v]+)>( |$)(.*)?`)\n```\n\nThe developer likely intended `[^<>\\v]` to mean \"Match anything that is NOT a `<` OR `>` OR `Vertical Whitespace`\".\n\nHowever, in Go's `regexp` (RE2) syntax, the behavior of `\\v` changes depending on context:\n- **Outside** brackets: `\\v` matches all vertical whitespace: `[\\n\\v\\f\\r\\x85\\u2028\\u2029]`.\n- **Inside** brackets (`[...]`): `\\v` matches **only** the Vertical Tab character (`\\x0B`).\n\n**Result:** The regex `[^<>\\v]` **allows** Carriage Return (`\\r`) and Line Feed (`\\n`) characters to pass through, as they are not `<` or `>` or `\\x0B`.\n\n### Exploit Scenario\n### Exploit Scenario\nWhen Mailpit constructs the `Received` header, it uses the validated recipient address directly:\n\n```go\n// internal/smtpd/smtpd.go:865\nbuffer.WriteString(fmt.Sprintf(\"        for <%s>; %s\\r\\n\", to[0], now))\n```\n\nIf `to[0]` contains `victim\\rINJECTED-HEADER: YES`, the resulting string in memory becomes:\n\n```text\n        for <victim\\rINJECTED-HEADER: YES>; ...\n```\n\nWhile `bufio.ReadString` prevents injecting immediate `\\n` (newlines), `\\r` (Carriage Return) bypasses this check. \n\n**The Result:** The stored EML file contains a \"Bare CR\".\n- **RFC Violation:** RFC 5321 strictly forbids Bare CR. Lines must end in CRLF.\n- **UI Behavior:** Browsers typically render Bare CR as a space, so it may look like `victim INJECTED` in the Mailpit UI.\n- **Real Impact:** The raw email is corrupted. If this email is exported or relayed, downstream systems (Outlook, older MTAs) may interpret the Bare CR as a line break, triggering a full **Header Injection**. Furthermore, Mailpit failing to reject this gives developers a **false sense of security**, as their code might be generating malformed emails that work in Mailpit but fail in production (e.g., with Gmail or Exchange).\n\n### Raw EML Verification\nThe following screenshot of the raw `.eml` file confirms that the `\\r` character successfully broke the `Received` header structure in the stored file, effectively creating a new line for the injected content.\n\n<img width=\"621\" height=\"230\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1611f07e-316d-436a-95d6-9b14c9a8ecc6\" />\n\n<img width=\"1058\" height=\"441\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9543d904-6e0a-4c8b-b283-abbe05b752d0\" />\n\n<img width=\"668\" height=\"196\" alt=\"image\" src=\"https://github.com/user-attachments/assets/907e4467-aab6-4bb4-83ce-743af4f6ba8d\" />\n\n\n\nAs seen in lines  of the screenshot:\n```text\n        for <victim\nINJECTED_VIA_CR:YES>; Tue, 13 Jan ...\n```\nThe `INJECTED_VIA_CR:YES` payload is treated as a start of a new line by the text editor (VS Code), which honors `\\r` as a line break. This proves the injection matches the \"Bare CR\" attack vector.\n\n## Additional Proof of Concepts\n\n### 1. Null Byte Injection (`\\x00`)\nThe regex `[^<>\\v]+` also allows the Null Byte (`\\x00`).\n**Test:** `test_null_byte.py` sent `RCPT TO:<victim\\x00-NULL-BYTE-HERE>`.\n**Result:** Server accepted the message (`250 OK`).\n**Impact:** The API returns an empty `[]` for the To field in the message summary, indicating the parser failure in the UI/API layer. The raw message content confirms the Null Byte is stored in the database.\n\n### 3. Detailed Character Compatibility\nTests (0-127 ASCII) confirm that the regex `[^<>\\v]` blocks **only** the following:\n- `<` (Less Than)\n- `>` (Greater Than)\n- `\\x0B` (Vertical Tab)\n\n**Crucially, it ALLOWS:**\n| Character | Hex | Regex Status | Network Status | Impact |\n| :--- | :--- | :--- | :--- | :--- |\n| **Carriage Return** | `\\r` (`0x0D`) | **ALLOWED** | **Passed** | **Header Injection** |\n| **Line Feed** | `\\n` (`0x0A`) | **ALLOWED** | Blocked* | *Blocked by `bufio.ReadString`, not regex. |\n| **Null Byte** | `\\x00` (`0x00`) | **ALLOWED** | **Passed** | API DoS / Corrupt Data |\n| **Tab** | `\\t` (`0x09`) | **ALLOWED** | **Passed** | Formatting issues |\n| **Delete** | `\\x7F` (`0x7F`) | **ALLOWED** | **Passed** | Potential obfuscation |\n| **Controls** | `0x01`-`0x1F` | **ALLOWED** | **Passed** | (Except `0x0A`, `0x0B`, `0x0D`) |\n\n*This confirms that the regex fails to implement a proper \"Safe Text\" allowlist, defaulting instead to a flawed denylist.*\n\n## Proof of Concept\nThe following Python script demonstrates the injection of a \"bare CR\" into the headers, which is successfully accepted by the server.\n\n```python\nimport socket\n\ndef exploit():\n    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n    s.connect((\"127.0.0.1\", 1025))\n    s.recv(1024)\n    s.send(b\"EHLO test.com\\r\\n\")\n    s.recv(1024)\n    s.send(b\"MAIL FROM:<attacker@evil.com>\\r\\n\")\n    s.recv(1024)\n    \n    # Injecting \\r \n    payload = b\"RCPT TO:<victim\\rX-Injected: Yes>\\r\\n\"\n    s.send(payload)\n    resp = s.recv(1024)\n    print(f\"Server Response: {resp.decode()}\") # Expect 250 OK\n    \n    s.send(b\"DATA\\r\\n\")\n    s.recv(1024)\n    s.send(b\"Subject: Test\\r\\n\\r\\nBody\\r\\n.\\r\\n\")\n    s.recv(1024)\n    s.close()\n    \nexploit()\n```\n\n## Remediation\nUpdate the regex to explicitly exclude `\\r` and `\\n`, or use the correct character class escape for control characters.\n\n**Recommended Fix:**\nUse `\\x00-\\x1F` to exclude all ASCII control characters.\n\n```go\n// Fix: Exclude all control characters explicitly\nrcptToRE   = regexp.MustCompile(`(?i)TO: ?<([^<>\\x00-\\x1f]+)>( |$)(.*)?`)\nmailFromRE = regexp.MustCompile(`(?i)FROM: ?<(|[^<>\\x00-\\x1f]+)>( |$)(.*)?`)\n```\n\nAlternatively, strictly exclude CR and LF:\n```go\nrcptToRE   = regexp.MustCompile(`(?i)TO: ?<([^<>\\r\\n]+)>( |$)(.*)?`)\n```\n## Classification & References\n- **CWE-93:** [Improper Neutralization of CRLF Sequences ('CRLF Injection')](https://cwe.mitre.org/data/definitions/93.html)\n- **CWE-150:** [Improper Neutralization of Escape, Meta, or Control Sequences](https://cwe.mitre.org/data/definitions/150.html)\n- **OWASP:** [Injection Flaws](https://owasp.org/www-community/attacks/Injection_Flaws)\n- **CAPEC-106:** [Command Injection](https://capec.mitre.org/data/definitions/106.html) (Related usage pattern)\n- [[RFC 5321 Section 4.5.3.1 - Size Limits](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1)](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/axllent/mailpit"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.28.3"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.28.2"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/axllent/mailpit/security/advisories/GHSA-54wq-72mp-cq7c"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-23829"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/axllent/mailpit/commit/36cc06c125954dec6673219dafa084e13cc14534"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/axllent/mailpit"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/axllent/mailpit/releases/tag/v1.28.3"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-150", "CWE-93" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-01-20T17:54:55Z",
    "nvd_published_at" : "2026-01-19T00:15:48Z"
  }
}