Common Weakness Enumeration

CWE-150

Allowed

Improper Neutralization of Escape, Meta, or Control Sequences

Abstraction: Variant · Status: Incomplete

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.

115 vulnerabilities reference this CWE, most recent first.

GHSA-4F45-VH57-P56G

Vulnerability from github – Published: 2023-08-14 06:30 – Updated: 2024-04-04 06:54

Details

An authentication bypass exists on CyberPower PowerPanel Enterprise by failing to sanitize meta-characters from the username, allowing an attacker to login into the application with the default user "cyberpower" by appending a non-printable character.An unauthenticated attacker can leverage this vulnerability to log in to the CypberPower PowerPanel Enterprise as an administrator with hardcoded default credentials.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-3265"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-14T05:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "An authentication bypass exists on CyberPower PowerPanel Enterprise by failing to sanitize meta-characters from the username, allowing an attacker to login into the application with the default user \"cyberpower\" by appending a non-printable character.An unauthenticated attacker can leverage this vulnerability to log in to the CypberPower PowerPanel Enterprise as an administrator with hardcoded default credentials.",
  "id": "GHSA-4f45-vh57-p56g",
  "modified": "2024-04-04T06:54:38Z",
  "published": "2023-08-14T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3265"
    },
    {
      "type": "WEB",
      "url": "https://www.trellix.com/en-us/about/newsroom/stories/research/the-threat-lurking-in-data-centers.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4HMJ-39M8-JWC7

Vulnerability from github – Published: 2026-03-29 15:50 – Updated: 2026-04-24 19:53

Summary

OpenClaw has ACP CLI approval prompt ANSI escape sequence injection

Details

Summary

ACP CLI approval prompt ANSI escape sequence injection

Affected Packages / Versions

Package: openclaw
Affected versions: >= 2026.2.13, <= 2026.3.24
First patched version: 2026.3.25
Latest published npm version at verification time: 2026.3.24

Details

ACP tool titles could previously carry ANSI control sequences into approval prompts and permission logs, letting untrusted tool metadata spoof terminal output. Commit 464e2c10a5edceb380d815adb6ff56e1a4c50f60 sanitizes tool titles at the source and broadens ANSI stripping to full CSI sequences.

Verified vulnerable on tag v2026.3.24 and fixed on main by commit 464e2c10a5edceb380d815adb6ff56e1a4c50f60.

Fix Commit(s)

464e2c10a5edceb380d815adb6ff56e1a4c50f60

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.2.13"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35651"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:50:41Z",
    "nvd_published_at": "2026-04-10T17:17:05Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nACP CLI approval prompt ANSI escape sequence injection\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Affected versions: `\u003e= 2026.2.13, \u003c= 2026.3.24`\n- First patched version: `2026.3.25`\n- Latest published npm version at verification time: `2026.3.24`\n\n## Details\n\nACP tool titles could previously carry ANSI control sequences into approval prompts and permission logs, letting untrusted tool metadata spoof terminal output. Commit `464e2c10a5edceb380d815adb6ff56e1a4c50f60` sanitizes tool titles at the source and broadens ANSI stripping to full CSI sequences.\n\nVerified vulnerable on tag `v2026.3.24` and fixed on `main` by commit `464e2c10a5edceb380d815adb6ff56e1a4c50f60`.\n\n## Fix Commit(s)\n\n- `464e2c10a5edceb380d815adb6ff56e1a4c50f60`",
  "id": "GHSA-4hmj-39m8-jwc7",
  "modified": "2026-04-24T19:53:46Z",
  "published": "2026-03-29T15:50:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4hmj-39m8-jwc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35651"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/464e2c10a5edceb380d815adb6ff56e1a4c50f60"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-ansi-escape-sequence-injection-in-approval-prompt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has ACP CLI approval prompt ANSI escape sequence injection"
}

GHSA-54WQ-72MP-CQ7C

Vulnerability from github – Published: 2026-01-20 17:54 – Updated: 2026-02-02 14:50

Summary

Mailpit has an SMTP Header Injection via Regex Bypass

Details

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.

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).
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.
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.
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:

// 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

When Mailpit constructs the Received header, it uses the validated recipient address directly:

// 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:

        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.

As seen in lines of the screenshot:

        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)

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.

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.

// 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:

rcptToRE   = regexp.MustCompile(`(?i)TO: ?<([^<>\r\n]+)>( |$)(.*)?`)

Classification & References

CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
OWASP: Injection Flaws
CAPEC-106: Command Injection (Related usage pattern)
[RFC 5321 Section 4.5.3.1 - Size Limits](https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1)

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.28.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/axllent/mailpit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.28.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-20T17:54:55Z",
    "nvd_published_at": "2026-01-19T00:15:48Z",
    "severity": "MODERATE"
  },
  "details": "# Vulnerability Report: SMTP Header Injection via Regex Bypass\n\n**Vulnerable Code:** `mailpit/internal/smtpd/smtpd.go`\n\n## Executive Summary\nMailpit\u0027s 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 \u0026 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\u0027s 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 `[^\u003c\u003e\\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\u0027t 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\u0027s 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: ?\u003c([^\u003c\u003e\\v]+)\u003e( |$)(.*)?`)\nmailFromRE = regexp.MustCompile(`(?i)FROM: ?\u003c(|[^\u003c\u003e\\v]+)\u003e( |$)(.*)?`)\n```\n\nThe developer likely intended `[^\u003c\u003e\\v]` to mean \"Match anything that is NOT a `\u003c` OR `\u003e` OR `Vertical Whitespace`\".\n\nHowever, in Go\u0027s `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 `[^\u003c\u003e\\v]` **allows** Carriage Return (`\\r`) and Line Feed (`\\n`) characters to pass through, as they are not `\u003c` or `\u003e` 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 \u003c%s\u003e; %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 \u003cvictim\\rINJECTED-HEADER: YES\u003e; ...\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\u003cimg width=\"621\" height=\"230\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1611f07e-316d-436a-95d6-9b14c9a8ecc6\" /\u003e\n\n\u003cimg width=\"1058\" height=\"441\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9543d904-6e0a-4c8b-b283-abbe05b752d0\" /\u003e\n\n\u003cimg width=\"668\" height=\"196\" alt=\"image\" src=\"https://github.com/user-attachments/assets/907e4467-aab6-4bb4-83ce-743af4f6ba8d\" /\u003e\n\n\n\nAs seen in lines  of the screenshot:\n```text\n        for \u003cvictim\nINJECTED_VIA_CR:YES\u003e; 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 `[^\u003c\u003e\\v]+` also allows the Null Byte (`\\x00`).\n**Test:** `test_null_byte.py` sent `RCPT TO:\u003cvictim\\x00-NULL-BYTE-HERE\u003e`.\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 `[^\u003c\u003e\\v]` blocks **only** the following:\n- `\u003c` (Less Than)\n- `\u003e` (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:\u003cattacker@evil.com\u003e\\r\\n\")\n    s.recv(1024)\n    \n    # Injecting \\r \n    payload = b\"RCPT TO:\u003cvictim\\rX-Injected: Yes\u003e\\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: ?\u003c([^\u003c\u003e\\x00-\\x1f]+)\u003e( |$)(.*)?`)\nmailFromRE = regexp.MustCompile(`(?i)FROM: ?\u003c(|[^\u003c\u003e\\x00-\\x1f]+)\u003e( |$)(.*)?`)\n```\n\nAlternatively, strictly exclude CR and LF:\n```go\nrcptToRE   = regexp.MustCompile(`(?i)TO: ?\u003c([^\u003c\u003e\\r\\n]+)\u003e( |$)(.*)?`)\n```\n## Classification \u0026 References\n- **CWE-93:** [Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027)](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)",
  "id": "GHSA-54wq-72mp-cq7c",
  "modified": "2026-02-02T14:50:34Z",
  "published": "2026-01-20T17:54:55Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mailpit has an SMTP Header Injection via Regex Bypass"
}

GHSA-768G-4QPG-32W7

Vulnerability from github – Published: 2025-12-05 12:30 – Updated: 2025-12-05 21:30

Details

Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache HTTP Server through environment variables set via the Apache configuration unexpectedly superseding variables calculated by the server for CGI programs.

This issue affects Apache HTTP Server from 2.4.0 through 2.4.65.

Users are recommended to upgrade to version 2.4.66 which fixes the issue.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-65082"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-05T11:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache HTTP Server through environment variables set via the Apache configuration unexpectedly superseding variables calculated by the server for CGI programs.\n\nThis issue affects Apache HTTP Server from 2.4.0 through 2.4.65.\n\nUsers are recommended to upgrade to version 2.4.66 which fixes the issue.",
  "id": "GHSA-768g-4qpg-32w7",
  "modified": "2025-12-05T21:30:23Z",
  "published": "2025-12-05T12:30:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65082"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/12/04/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-76R7-HHXJ-R776

Vulnerability from github – Published: 2025-08-13 22:32 – Updated: 2025-08-21 21:36

Summary

Active Record logging vulnerable to ANSI escape injection

Details

This vulnerability has been assigned the CVE identifier CVE-2025-55193

Impact

The ID passed to find or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.

Releases

The fixed releases are available at the normal locations.

Credits

Thanks to lio346 from Unit 515 of OPSWAT for reporting this vulnerability

Severity

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0"
            },
            {
              "fixed": "8.0.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2"
            },
            {
              "fixed": "7.2.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-13T22:32:18Z",
    "nvd_published_at": "2025-08-13T23:15:26Z",
    "severity": "MODERATE"
  },
  "details": "This vulnerability has been assigned the CVE identifier CVE-2025-55193\n\n### Impact\nThe ID passed to `find` or similar methods may be logged without escaping. If this is directly to the terminal it may include unescaped ANSI sequences.\n\n### Releases\nThe fixed releases are available at the normal locations.\n\n### Credits\n\nThanks to [lio346](https://hackerone.com/lio346) from Unit 515 of OPSWAT for reporting this vulnerability",
  "id": "GHSA-76r7-hhxj-r776",
  "modified": "2025-08-21T21:36:39Z",
  "published": "2025-08-13T22:32:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/security/advisories/GHSA-76r7-hhxj-r776"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55193"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/commit/3beef20013736fd52c5dcfdf061f7999ba318290"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/commit/568c0bc2f1e74c65d150a84b89a080949bf9eb9b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/commit/6a944ca4805e72050a0fbb1a461534eb760d3202"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rails/rails"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activerecord/CVE-2025-55193.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Active Record logging vulnerable to ANSI escape injection"
}

GHSA-7GCP-2GMQ-W3XH

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2023-03-09 00:37

Summary

RubyGems Code Injection vulnerability

Details

RubyGems prior to 2.6.13 is vulnerable to maliciously crafted gem specifications that include terminal escape characters. Printing the gem specification would execute terminal escape sequences.

Severity

9.8 (Critical)


                  
                    CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rubygems-update"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-0899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-09T00:37:49Z",
    "nvd_published_at": "2017-08-31T20:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "RubyGems prior to 2.6.13 is vulnerable to maliciously crafted gem specifications that include terminal escape characters. Printing the gem specification would execute terminal escape sequences.",
  "id": "GHSA-7gcp-2gmq-w3xh",
  "modified": "2023-03-09T00:37:49Z",
  "published": "2022-05-13T01:38:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubygems/rubygems/commit/1bcbc7fe637b03145401ec9c094066285934a7f1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubygems/rubygems/commit/ef0aa611effb5f54d40c7fba6e8235eb43c5a491"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/226335"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2017:3485"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0378"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0585"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rubygems/rubygems"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/07/msg00012.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201710-01"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170907215801/http://www.securitytracker.com/id/1039249"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170915000000*/http://www.securityfocus.com/bid/100576#:~:text=1%20snapshot-,11%3A49%3A33,-Note"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2017/dsa-3966"
    },
    {
      "type": "WEB",
      "url": "http://blog.rubygems.org/2017/08/27/2.6.13-released.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "RubyGems Code Injection vulnerability"
}

GHSA-7GPV-C5RV-9QXM

Vulnerability from github – Published: 2026-03-20 18:31 – Updated: 2026-04-14 15:30

Details

An improper neutralization of escape, meta, or control sequences vulnerability has been reported to affect QHora. If a local attacker gains an administrator account, they can then exploit the vulnerability to cause unexpected behavior.

We have already fixed the vulnerability in the following version: QuRouter 2.6.3.009 and later

Severity

6.7 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

5.6 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:H/E:U

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-62845"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-20T17:16:42Z",
    "severity": "MODERATE"
  },
  "details": "An improper neutralization of escape, meta, or control sequences vulnerability has been reported to affect QHora. If a local attacker gains an administrator account, they can then exploit the vulnerability to cause unexpected behavior.\n\nWe have already fixed the vulnerability in the following version:\nQuRouter 2.6.3.009 and later",
  "id": "GHSA-7gpv-c5rv-9qxm",
  "modified": "2026-04-14T15:30:28Z",
  "published": "2026-03-20T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62845"
    },
    {
      "type": "WEB",
      "url": "https://www.qnap.com/en/security-advisory/qsa-26-12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:H/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-7M59-RFR2-GH4P

Vulnerability from github – Published: 2024-04-29 00:30 – Updated: 2024-07-03 18:37

Details

RARLAB WinRAR before 7.00, on Linux and UNIX platforms, allows attackers to spoof the screen output, or cause a denial of service, via ANSI escape sequences.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-33899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-29T00:15:07Z",
    "severity": "HIGH"
  },
  "details": "RARLAB WinRAR before 7.00, on Linux and UNIX platforms, allows attackers to spoof the screen output, or cause a denial of service, via ANSI escape sequences.",
  "id": "GHSA-7m59-rfr2-gh4p",
  "modified": "2024-07-03T18:37:14Z",
  "published": "2024-04-29T00:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33899"
    },
    {
      "type": "WEB",
      "url": "https://sdushantha.medium.com/ansi-escape-injection-vulnerability-in-winrar-a2cbfac4b983"
    },
    {
      "type": "WEB",
      "url": "https://www.rarlab.com/rarnew.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-88G2-R9RW-G55H

Vulnerability from github – Published: 2024-08-22 16:41 – Updated: 2025-01-21 18:31

Summary

gitoxide-core does not neutralize special characters for terminals

Details

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
Reading and blocking cannot be performed.
Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Severity

2.5 (Low)


                  
                    CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "gitoxide-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.45.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "gitoxide"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.41.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-43785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-22T16:41:28Z",
    "nvd_published_at": "2024-08-22T15:15:16Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `gix` and `ein` commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.\n\n### Details\n\n`gitoxide-core`, which provides most underlying functionality of the `gix` and `ein` commands, does not neutralize newlines, backspaces, or control characters\u2014including those that form ANSI escape sequences\u2014that appear in a repository\u0027s paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.\n\nANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.\n\nThe effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.\n\n### PoC\n\nOn a Unix-like system in a POSIX-compatible shell, run:\n\n```sh\ngit init misleading-path\ncd misleading-path\ntouch \"$(printf \u0027\\033]0;Boo!\\007\\033[2K\\r\\033[91mError: Repository is corrupted. Run \\033[96mEVIL_COMMAND\\033[91m to attempt recovery.\\033[0m\u0027)\"\ngit add .\ngit commit -m \u0027Initial commit\u0027\n```\n\nIn the repository\u2014or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository\u2014run this command, which outputs entries in a three-column form showing type, hash, and filename:\n\n```sh\ngix tree entries\n```\n\nAlthough the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with `EVIL_COMMAND` in another color, and with no other text:\n\n```text\nError: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.\n```\n\nIn some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to `Boo!`, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.\n\nTo see what is actually produced, `gix tree entries` can be piped to a command that displays special characters symbolically, such as `less` or `cat -v` if available.\n\n```text\nBLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m\n```\n\nThat shows the effect on `gix tree entries`, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the `user.name` used to create a commit.\n\n### Impact\n\nFor users who do not clone or operate in clones of untrusted repositories, there is no impact.\nWindows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.\n\nBecause different `gix` and `ein` commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where `gix clone` fails to clone it but produces a misleading message.\n\nAlthough this is mainly exploitable on systems *other* than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:\n\n- The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.\n- The misleading output can only be take place *when* the application is already producing output. This limitation complicates the production of believable messages.\n- Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.\n- Reading and blocking cannot be performed.\n- Applications other than the gitoxide `gix` and `ein` executables are unaffected. The exception is if another application uses `gitoxide-core`. But this is explicitly discouraged in the `gitoxide-core` documentation and is believed to be rare.",
  "id": "GHSA-88g2-r9rw-g55h",
  "modified": "2025-01-21T18:31:55Z",
  "published": "2024-08-22T16:41:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Byron/gitoxide/security/advisories/GHSA-88g2-r9rw-g55h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-88g2-r9rw-g55h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43785"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Byron/gitoxide"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0364.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gitoxide-core does not neutralize special characters for terminals"
}

GHSA-89XP-C3MQ-QJ84

Vulnerability from github – Published: 2025-03-17 00:30 – Updated: 2025-03-17 14:45

Summary

gurk (aka gurk-rs) mishandles ANSI escape sequences

Details

gurk (aka gurk-rs) through 0.6.3 mishandles ANSI escape sequences.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "gurk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-17T14:45:39Z",
    "nvd_published_at": "2025-03-17T00:15:13Z",
    "severity": "MODERATE"
  },
  "details": "gurk (aka gurk-rs) through 0.6.3 mishandles ANSI escape sequences.",
  "id": "GHSA-89xp-c3mq-qj84",
  "modified": "2025-03-17T14:45:39Z",
  "published": "2025-03-17T00:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30089"
    },
    {
      "type": "WEB",
      "url": "https://github.com/boxdot/gurk-rs/issues/384"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/gurk"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/boxdot/gurk-rs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gurk (aka gurk-rs) mishandles ANSI escape sequences"
}

Mitigation

Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.

Mitigation MIT-5

Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Mitigation MIT-28

Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Mitigation MIT-20

Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

Mitigation

Implementation

When using output from an LLM, neutralize or strip escape codes before redirecting output to the terminal or other rendering engine that would process the codes. The neutralization could require that the character be printable and/or allowable whitespace, such as a carriage return or newline. Be deliberate about what to allow.

Mitigation

Build and Compilation

When using an LLM: during tokenizer training, suppress escape codes from the tokenizer's vocabulary. Depending on context, this could be accomplished by removing the codes from input to the tokenizer, or removing the map from the string to its token ID. It is generally unlikely that this removal would adversely affect the quality or correctness of what is generated, e.g. advice requests for terminal settings to change colors.

CAPEC-134: Email Injection

An adversary manipulates the headers and content of an email message by injecting data via the use of delimiter characters native to the protocol.

CAPEC-41: Using Meta-characters in E-mail Headers to Inject Malicious Payloads

This type of attack involves an attacker leveraging meta-characters in email headers to inject improper behavior into email programs. Email software has become increasingly sophisticated and feature-rich. In addition, email applications are ubiquitous and connected directly to the Web making them ideal targets to launch and propagate attacks. As the user demand for new functionality in email applications grows, they become more like browsers with complex rendering and plug in routines. As more email functionality is included and abstracted from the user, this creates opportunities for attackers. Virtually all email applications do not list email header information by default, however the email header contains valuable attacker vectors for the attacker to exploit particularly if the behavior of the email client application is known. Meta-characters are hidden from the user, but can contain scripts, enumerations, probes, and other attacks against the user's system.

CAPEC-81: Web Server Logs Tampering

Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.

CAPEC-93: Log Injection-Tampering-Forging

This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability.

← Back to the CWE list

CWE-150

Improper Neutralization of Escape, Meta, or Control Sequences

Summary

Affected Packages / Versions

Details

Fix Commit(s)

Vulnerability Report: SMTP Header Injection via Regex Bypass

Executive Summary

RFC Compliance & Design Analysis

Technical Analysis

The Flaw

Exploit Scenario

Exploit Scenario

Raw EML Verification

Additional Proof of Concepts

1. Null Byte Injection (\x00)

3. Detailed Character Compatibility

Proof of Concept

Remediation

Classification & References

Impact

Releases

Credits

Summary

Details

PoC

Impact

Mitigation

Mitigation MIT-5

Mitigation MIT-28

Mitigation MIT-20

Mitigation

Mitigation

CAPEC-134: Email Injection

CAPEC-41: Using Meta-characters in E-mail Headers to Inject Malicious Payloads

CAPEC-81: Web Server Logs Tampering

CAPEC-93: Log Injection-Tampering-Forging

1. Null Byte Injection (`\x00`)