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.

153 vulnerabilities reference this CWE, most recent first.

GHSA-C2P2-HGJG-9R3F

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

Summary

Crayfish Allows Remote Code Execution via hypercube X-Islandora-Args Header

Details

Impact

What kind of vulnerability is it? Who is impacted?

Remote code execution is possible in web-accessible installations of hypercube.

Patches

Has the problem been patched? What versions should users upgrade to?

Not yet, though no patch is neccessary if your installation of the microservices is behind a firewall. See below.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

The exploit requires making a request against Hypercube's endpoints; therefore, the ability to make use of the exploit is much reduced if the microservice is not directly accessible from the Internet, so: Prevent general access from the Internet from hitting Hypercube. Furthermore, if you've used any of the official installation methods, your Crayfish will be behind a firewall and there is no work neccessary.

The webserver might be made to validate the structure of headers passed, but that would only be neccessary if you publicly exposed the endpoint. Standard security practices should be applied.

References

Are there any links users can visit to find out more?

XBOW-024-074

Severity

9.5 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "islandora/crayfish"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-150",
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-12T21:05:47Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nRemote code execution is possible in web-accessible installations of hypercube. \n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nNot yet, though no patch is neccessary if your installation of the microservices is behind a firewall.  See below.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThe exploit requires making a request against Hypercube\u0027s endpoints; therefore, the ability to make use of the exploit is much reduced if the microservice is not directly accessible from the Internet, so: Prevent general access from the Internet from hitting Hypercube.  Furthermore, if you\u0027ve used any of the official installation methods, your Crayfish will be behind a firewall and there is no work neccessary.\n\nThe webserver might be made to validate the structure of headers passed, but that would only be neccessary if you publicly exposed the endpoint. Standard security practices should be applied.\n\n### References\n_Are there any links users can visit to find out more?_\n\n- XBOW-024-074",
  "id": "GHSA-c2p2-hgjg-9r3f",
  "modified": "2025-02-12T21:05:47Z",
  "published": "2025-02-12T21:05:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Islandora/Crayfish/security/advisories/GHSA-c2p2-hgjg-9r3f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Islandora/Crayfish"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Crayfish Allows Remote Code Execution via hypercube X-Islandora-Args Header"
}

GHSA-CHQW-C679-9RG5

Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2025-08-22 18:31

Details

An information disclosure and remote code execution vulnerability in the slinger web server of the BlackBerry QNX Software Development Platform versions 6.4.0 to 6.6.0 could allow an attacker to potentially read arbitrary files and run arbitrary executables in the context of the web server.

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-2020-6932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150",
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-12T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "An information disclosure and remote code execution vulnerability in the slinger web server of the BlackBerry QNX Software Development Platform versions 6.4.0 to 6.6.0 could allow an attacker to potentially read arbitrary files and run arbitrary executables in the context of the web server.",
  "id": "GHSA-chqw-c679-9rg5",
  "modified": "2025-08-22T18:31:10Z",
  "published": "2022-05-24T17:25:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6932"
    },
    {
      "type": "WEB",
      "url": "http://support.blackberry.com/kb/articleDetail?articleNumber=000061411"
    }
  ],
  "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-CRC3-H8V6-QH57

Vulnerability from github – Published: 2026-05-19 19:37 – Updated: 2026-05-19 19:37

Summary

GitHub CLI: GitHub Actions log output in `gh run view` allows terminal escape sequence injection

Details

Summary

A security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using gh run view --log or gh run view --log-failed.

Details

The vulnerability stems from the way GitHub CLI handles raw Actions log output. The gh run view --log and gh run view --log-failed commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user's terminal when they inspect the run.

Depending on the victim's terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as screen) potentially execute arbitrary commands.

In 2.92.0, GitHub CLI sanitizes terminal control sequences in Actions log output before writing to the terminal.

PoC

Create a workflow that emits terminal escape sequences in its log output:

name: Escape Sequence PoC

on:
  workflow_dispatch:

jobs:
  emit-escape-sequences:
    runs-on: ubuntu-latest
    steps:
      - name: Emit terminal escape sequences
        run: |
          # OSC title set
          printf 'ESCAPE_MARKER_START \033]0;HIJACKED_TITLE\007 ESCAPE_MARKER_END\n'
          # CSI color
          printf 'ESCAPE_MARKER_START \033[31mRED_TEXT\033[0m ESCAPE_MARKER_END\n'
          # Screen title set (enables command execution in screen terminal)
          printf 'ESCAPE_MARKER_START \033k;malicious command;\033\\ ESCAPE_MARKER_END\n'

Then trigger the workflow and view its logs:

gh workflow run 'Escape Sequence PoC'
gh run view <run_id> --log

On vulnerable versions, the raw ESC bytes (0x1b) are passed through to the terminal unsanitized. On 2.92.0 and later, escape sequences are stripped and only the safe visible text is displayed.

Impact

An attacker who can control GitHub Actions workflow output can inject terminal escape sequences into a maintainer's terminal session when they inspect the run with gh run view --log or gh run view --log-failed. The practical impact depends on the victim's terminal emulator.

Remediation and Mitigation

Upgrade gh to 2.92.0
Pipe log output through a sanitizer (e.g., gh run view --log | cat -v) as a workaround on older versions
Exercise caution when viewing logs from untrusted workflow runs

Severity

3.5 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cli/cli/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.92.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cli/cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "last_affected": "1.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T19:37:01Z",
    "nvd_published_at": "2026-05-15T16:16:15Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nA security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using `gh run view --log` or `gh run view --log-failed`.\n\n### Details\n\nThe vulnerability stems from the way GitHub CLI handles raw Actions log output. The `gh run view --log` and `gh run view --log-failed` commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user\u0027s terminal when they inspect the run.\n\nDepending on the victim\u0027s terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as `screen`) potentially execute arbitrary commands.\n\nIn `2.92.0`, GitHub CLI sanitizes terminal control sequences in Actions log output before writing to the terminal.\n\n### PoC\n\nCreate a workflow that emits terminal escape sequences in its log output:\n\n```yaml\nname: Escape Sequence PoC\n\non:\n  workflow_dispatch:\n\njobs:\n  emit-escape-sequences:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Emit terminal escape sequences\n        run: |\n          # OSC title set\n          printf \u0027ESCAPE_MARKER_START \\033]0;HIJACKED_TITLE\\007 ESCAPE_MARKER_END\\n\u0027\n          # CSI color\n          printf \u0027ESCAPE_MARKER_START \\033[31mRED_TEXT\\033[0m ESCAPE_MARKER_END\\n\u0027\n          # Screen title set (enables command execution in screen terminal)\n          printf \u0027ESCAPE_MARKER_START \\033k;malicious command;\\033\\\\ ESCAPE_MARKER_END\\n\u0027\n```\n\nThen trigger the workflow and view its logs:\n\n```bash\ngh workflow run \u0027Escape Sequence PoC\u0027\ngh run view \u003crun_id\u003e --log\n```\n\nOn vulnerable versions, the raw ESC bytes (0x1b) are passed through to the terminal unsanitized. On `2.92.0` and later, escape sequences are stripped and only the safe visible text is displayed.\n\n### Impact\n\nAn attacker who can control GitHub Actions workflow output can inject terminal escape sequences into a maintainer\u0027s terminal session when they inspect the run with `gh run view --log` or `gh run view --log-failed`. The practical impact depends on the victim\u0027s terminal emulator.\n\n### Remediation and Mitigation\n\n1. Upgrade `gh` to `2.92.0`\n2. Pipe log output through a sanitizer (e.g., `gh run view --log | cat -v`) as a workaround on older versions\n3. Exercise caution when viewing logs from untrusted workflow runs",
  "id": "GHSA-crc3-h8v6-qh57",
  "modified": "2026-05-19T19:37:01Z",
  "published": "2026-05-19T19:37:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cli/cli/security/advisories/GHSA-crc3-h8v6-qh57"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45803"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cli/cli"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GitHub CLI: GitHub Actions log output in `gh run view` allows terminal escape sequence injection"
}

GHSA-CXF4-7MRP-VVPR

Vulnerability from github – Published: 2026-09-29 18:10 – Updated: 2026-09-30 21:26

Summary

Flysystem: WhitespacePathNormalizer's control-character (CorruptedPathDetected) check is bypassed by malformed UTF-8 in the path, affecting every adapter

Details

Related public issue (context, not a duplicate)

Closed issue #1429 ("Handle non-UTF-8 paths", 2024-03-24) raised exactly this general concern and even suggested detection via preg_match('//u', $path) !== 1 -- note the reporter's suggested check explicitly compares !== 1, which would correctly treat PCRE's false return as "reject." The maintainer's reply pointed to the PathNormalizer interface as the place to implement this. The control-character check that ended up shipping in WhitespacePathNormalizer (if (preg_match('#\p{C}+#u', $unixPath))) addresses the general concern but does not use the !== 1-style comparison the original issue suggested -- it uses a bare truthy check, which is exactly the gap this report demonstrates. So this is not a duplicate of #1429; it's a concrete bypass surviving in the fix that issue's concern led to.

Vulnerability Details

File: src/WhitespacePathNormalizer.php, lines 22-28 (normalizePath()) -- the default PathNormalizer used by Filesystem for every adapter (Local, FTP, SFTP, S3, AsyncAwsS3, Azure, GCS, ZipArchive, GridFS, InMemory) unless the application supplies a custom one.

Root Cause

public function normalizePath(string $path): string
{
    $unixPath = str_replace('\\', '/', $path);

    if (preg_match('#\p{C}+#u', $unixPath)) {
        throw CorruptedPathDetected::forPath($path);
    }
    ...

preg_match() returns false (a PHP engine error) rather than 0 when the subject string is not valid UTF-8 and the pattern uses the /u modifier -- PCRE can't even attempt the match. false and 0 are both falsy in PHP, and if (preg_match(...)) does not distinguish them. So a path containing any single invalid UTF-8 byte anywhere in the string makes preg_match() fail with a "Malformed UTF-8 characters" engine error, the if evaluates false, and CorruptedPathDetected is silently not thrown -- even when the same string also contains literal control characters this exact check exists to catch.

the identical payload IS correctly rejected once it's valid UTF-8:

$n->normalizePath("foo\x1bbar");         // valid UTF-8, contains ESC -> throws CorruptedPathDetected (correct)
$n->normalizePath("foo\x80\x1bbar");    // 0x80 = invalid lone UTF-8 continuation byte -> NOT thrown (bypass)

The path-traversal protection is unaffected -- it's exact byte-string comparison on /-delimited segments, independent of UTF-8 validity:

$n->normalizePath("\x80/../../etc/passwd");   // still throws PathTraversalDetected

Recommended Fix

public function normalizePath(string $path): string
{
    $unixPath = str_replace('\\', '/', $path);
    $matched = preg_match('#\p{C}+#u', $unixPath);

    if ($matched !== 0) {
        // $matched === false means malformed UTF-8 -- must also be treated as corrupted,
        // not silently allowed through.
        throw CorruptedPathDetected::forPath($path);
    }
    ...

Verification

Dynamically confirmed on league/flysystem HEAD 6837e1d / tag 3.35.2, PHP 8.4.22 CLI, end-to-end through LocalFilesystemAdapter: `` [1] write() succeeded -- normalizer did NOT reject the path. [2] Actual bytes on disk: ...801b5b386d6e6f726d616c2d6c6f6f6b696e672d66696c652e7478741b5b306d... [3] Filesystem::listContents() path contains raw ESC (0x1b): YES [4] Raw terminal output (viacat -v`): M-^@^[[8mnormal-looking-file.txt^[[0m^[[2K^[[1Aurgent-invoice.pdf

Severity

3.5 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:R/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= 3.35.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "league/flysystem"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.35.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102601"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T18:10:14Z",
    "nvd_published_at": "2026-09-29T16:17:06Z",
    "severity": "LOW"
  },
  "details": "## Related public issue (context, not a duplicate)\n\nClosed issue #1429 (\"Handle non-UTF-8 paths\", 2024-03-24) raised exactly this general concern and\neven suggested detection via `preg_match(\u0027//u\u0027, $path) !== 1` -- note the reporter\u0027s suggested check\nexplicitly compares `!== 1`, which *would* correctly treat PCRE\u0027s `false` return as \"reject.\" The\nmaintainer\u0027s reply pointed to the `PathNormalizer` interface as the place to implement this. The\ncontrol-character check that ended up shipping in `WhitespacePathNormalizer`\n(`if (preg_match(\u0027#\\p{C}+#u\u0027, $unixPath))`) addresses the general concern but does **not** use the\n`!== 1`-style comparison the original issue suggested -- it uses a bare truthy check, which is exactly\nthe gap this report demonstrates. So this is not a duplicate of #1429; it\u0027s a concrete bypass\nsurviving in the fix that issue\u0027s concern led to.\n\n## Vulnerability Details\n\n**File**: `src/WhitespacePathNormalizer.php`, lines 22-28 (`normalizePath()`) -- the **default**\n`PathNormalizer` used by `Filesystem` for every adapter (Local, FTP, SFTP, S3, AsyncAwsS3, Azure, GCS,\nZipArchive, GridFS, InMemory) unless the application supplies a custom one.\n\n### Root Cause\n\n```php\npublic function normalizePath(string $path): string\n{\n    $unixPath = str_replace(\u0027\\\\\u0027, \u0027/\u0027, $path);\n\n    if (preg_match(\u0027#\\p{C}+#u\u0027, $unixPath)) {\n        throw CorruptedPathDetected::forPath($path);\n    }\n    ...\n```\n\n`preg_match()` returns `false` (a PHP engine error) rather than `0` when the subject string is not\nvalid UTF-8 and the pattern uses the `/u` modifier -- PCRE can\u0027t even attempt the match. `false` and\n`0` are both falsy in PHP, and `if (preg_match(...))` does not distinguish them. So a path containing\n**any single invalid UTF-8 byte anywhere in the string** makes `preg_match()` fail with a \"Malformed\nUTF-8 characters\" engine error, the `if` evaluates false, and `CorruptedPathDetected` is silently **not**\nthrown -- even when the same string also contains literal control characters this exact check exists\nto catch.\n\nthe identical payload IS correctly rejected once it\u0027s valid UTF-8:\n```php\n$n-\u003enormalizePath(\"foo\\x1bbar\");         // valid UTF-8, contains ESC -\u003e throws CorruptedPathDetected (correct)\n$n-\u003enormalizePath(\"foo\\x80\\x1bbar\");    // 0x80 = invalid lone UTF-8 continuation byte -\u003e NOT thrown (bypass)\n```\n\nThe path-traversal protection is **unaffected** -- it\u0027s exact byte-string comparison on\n`/`-delimited segments, independent of UTF-8 validity:\n```php\n$n-\u003enormalizePath(\"\\x80/../../etc/passwd\");   // still throws PathTraversalDetected\n```\n\n### Recommended Fix\n```php\npublic function normalizePath(string $path): string\n{\n    $unixPath = str_replace(\u0027\\\\\u0027, \u0027/\u0027, $path);\n    $matched = preg_match(\u0027#\\p{C}+#u\u0027, $unixPath);\n\n    if ($matched !== 0) {\n        // $matched === false means malformed UTF-8 -- must also be treated as corrupted,\n        // not silently allowed through.\n        throw CorruptedPathDetected::forPath($path);\n    }\n    ...\n```\n\n### Verification\nDynamically confirmed on `league/flysystem` HEAD `6837e1d` / tag `3.35.2`, PHP 8.4.22 CLI, end-to-end\nthrough `LocalFilesystemAdapter`:\n```\n[1] write() succeeded -- normalizer did NOT reject the path.\n[2] Actual bytes on disk: ...801b5b386d6e6f726d616c2d6c6f6f6b696e672d66696c652e7478741b5b306d...\n[3] Filesystem::listContents() path contains raw ESC (0x1b): YES\n[4] Raw terminal output (via `cat -v`): M-^@^[[8mnormal-looking-file.txt^[[0m^[[2K^[[1Aurgent-invoice.pdf",
  "id": "GHSA-cxf4-7mrp-vvpr",
  "modified": "2026-09-30T21:26:45Z",
  "published": "2026-09-29T18:10:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/flysystem/security/advisories/GHSA-cxf4-7mrp-vvpr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102601"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/flysystem/commit/ef4a9a557d769b5d472c403125716706a0d9cc77"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thephpleague/flysystem"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/flysystem/releases/tag/3.35.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flysystem: WhitespacePathNormalizer\u0027s control-character (CorruptedPathDetected) check is bypassed by malformed UTF-8 in the path, affecting every adapter"
}

GHSA-F378-WF84-8J5H

Vulnerability from github – Published: 2026-05-18 21:31 – Updated: 2026-05-18 21:31

Details

Claude HUD through 0.0.12, patched in commit 234d9aa, constructs OSC 8 terminal hyperlink escape sequences using raw cwd and branchUrl values without stripping control characters or encoding embedded values, allowing attackers to inject arbitrary ANSI codes into terminal sessions. Attackers can embed ESC+backslash sequences in the current working directory or branch URL to execute malicious ANSI codes including text color changes, forged prompts, and OSC 52 clipboard writes, or trigger outbound HTTP requests to attacker-controlled remotes when hyperlinks are clicked.

Severity

4.6 (Medium)


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

2.4 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-47090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-18T20:16:39Z",
    "severity": "LOW"
  },
  "details": "Claude HUD through 0.0.12, patched in commit 234d9aa, constructs OSC 8 terminal hyperlink escape sequences using raw cwd and branchUrl values without stripping control characters or encoding embedded values, allowing attackers to inject arbitrary ANSI codes into terminal sessions. Attackers can embed ESC+backslash sequences in the current working directory or branch URL to execute malicious ANSI codes including text color changes, forged prompts, and OSC 52 clipboard writes, or trigger outbound HTTP requests to attacker-controlled remotes when hyperlinks are clicked.",
  "id": "GHSA-f378-wf84-8j5h",
  "modified": "2026-05-18T21:31:51Z",
  "published": "2026-05-18T21:31:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47090"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jarrodwatts/claude-hud/issues/485"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jarrodwatts/claude-hud/pull/487"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jarrodwatts/claude-hud/commit/234d9aad919b51326a43bcf90b45ae35c23afc30"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/claude-hud-terminal-injection-via-osc-8-hyperlinks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/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-F9JG-8P32-2F55

Vulnerability from github – Published: 2022-01-08 00:00 – Updated: 2023-10-02 15:53

Summary

kubectl ANSI escape characters not filtered

Details

kubectl (k8s.io/kubernetes/pkg/kubectl) does not neutralize escape, meta or control sequences contained in the raw data it outputs to a terminal. This includes but is not limited to the unstructured string fields in objects such as Events.

Severity

3.0 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "k8s.io/kubernetes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.0-alpha.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-25743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-07T23:58:59Z",
    "nvd_published_at": "2022-01-07T00:15:00Z",
    "severity": "LOW"
  },
  "details": "kubectl (k8s.io/kubernetes/pkg/kubectl) does not neutralize escape, meta or control sequences contained in the raw data it outputs to a terminal. This includes but is not limited to the unstructured string fields in objects such as Events.",
  "id": "GHSA-f9jg-8p32-2f55",
  "modified": "2023-10-02T15:53:13Z",
  "published": "2022-01-08T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25743"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/issues/101695"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/pull/112553"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes/kubernetes/commit/dad0e937c0f76344363eb691b2668490ffef8537"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kubernetes/kubernetes"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220217-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kubectl ANSI escape characters not filtered"
}

GHSA-FF77-26X5-69CR

Vulnerability from github – Published: 2025-04-28 21:30 – Updated: 2025-11-03 22:56

Summary

Apache Tomcat Rewrite rule bypass

Details

Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat. For a subset of unlikely rewrite rule configurations, it was possible for a specially crafted request to bypass some rewrite rules. If those rewrite rules effectively enforced security constraints, those constraints could be bypassed.

This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.

Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6, which fix the issue.

Severity

2.7 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.102"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.76"
            },
            {
              "fixed": "9.0.104"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.10"
            },
            {
              "fixed": "10.1.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M2"
            },
            {
              "fixed": "11.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.102"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.76"
            },
            {
              "fixed": "9.0.104"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.1.10"
            },
            {
              "fixed": "10.1.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-M2"
            },
            {
              "fixed": "11.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat-catalina"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "last_affected": "8.5.100"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat.embed:tomcat-embed-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.5.0"
            },
            {
              "last_affected": "8.5.100"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-31651"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-29T15:03:25Z",
    "nvd_published_at": "2025-04-28T20:15:20Z",
    "severity": "LOW"
  },
  "details": "Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat.\u00a0For a subset of unlikely rewrite rule configurations, it was possible for a specially crafted request to bypass some rewrite rules. If those rewrite rules effectively enforced security constraints, those constraints could be bypassed.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.\n\nUsers are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6, which fix the issue.",
  "id": "GHSA-ff77-26x5-69cr",
  "modified": "2025-11-03T22:56:57Z",
  "published": "2025-04-28T21:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31651"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/066bf6b6a15a4e7e0941d4acf096841165b97098"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/175dc75fc428930034a6c93fb52f830d955d8e64"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/ee3ab548e92345eca0cbd1f01649eb36c6f29454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/fbecc915a10c5a3d634c5e2c6ced4ff479ce9953"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/list.html?announce@tomcat.apache.org"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/07/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-10.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-11.html"
    },
    {
      "type": "WEB",
      "url": "https://tomcat.apache.org/security-9.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/04/28/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Tomcat Rewrite rule bypass"
}

GHSA-FP7Q-M5XH-3GGJ

Vulnerability from github – Published: 2026-09-27 15:31 – Updated: 2026-09-27 15:31

Details

onefetch through 2.28.1 writes repository information field values to the terminal without removing control characters, allowing terminal escape sequence injection. Attackers can embed ANSI/OSC escape sequences in project manifest version and name fields to manipulate terminal output, rewrite window titles, hide text, or trigger emulator-specific behavior when victims run onefetch.

Severity

3.3 (Low)


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

4.8 (Medium)


                  
                    CVSS:4.0/AV:L/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": [],
  "aliases": [
    "CVE-2026-100866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T13:16:36Z",
    "severity": "MODERATE"
  },
  "details": "onefetch through 2.28.1 writes repository information field values to the terminal without removing control characters, allowing terminal escape sequence injection. Attackers can embed ANSI/OSC escape sequences in project manifest version and name fields to manipulate terminal output, rewrite window titles, hide text, or trigger emulator-specific behavior when victims run onefetch.",
  "id": "GHSA-fp7q-m5xh-3ggj",
  "modified": "2026-09-27T15:31:07Z",
  "published": "2026-09-27T15:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100866"
    },
    {
      "type": "WEB",
      "url": "https://github.com/o2sh/onefetch/issues/1828"
    },
    {
      "type": "WEB",
      "url": "https://github.com/o2sh/onefetch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/o2sh/onefetch/blob/9beb80329cf2e5bd784270f668139f0bafb48e2b/src/info/utils/info_field.rs#L43-L55"
    },
    {
      "type": "WEB",
      "url": "https://github.com/o2sh/onefetch/blob/9beb80329cf2e5bd784270f668139f0bafb48e2b/src/info/version.rs#L33-L35"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/onefetch-through-2.28.1-terminal-escape-sequence-injection"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/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-FV2R-R8MP-PG48

Vulnerability from github – Published: 2025-11-06 23:48 – Updated: 2025-11-17 21:49

Summary

Soft Serve does not sanitize ANSI escape sequences in user input

Details

Impact

In several places where the user can insert data (e.g. names), ANSI escape sequences are not being removed, which can then be used, for example, to show fake alerts.

In the same token, git messages, when printed, are also not being sanitized.

Places in which this was found:

Repository Description (pkg/backend/repo.go - SetDescription)
Repository Project Name (pkg/backend/repo.go - SetProjectName)
Git Commit Author Names (pkg/ssh/cmd/commit.go:69)
Git Commit Messages (pkg/ssh/cmd/commit.go:71)
Access Token Names (pkg/ssh/cmd/token.go:107)
Webhook URLs (pkg/ssh/cmd/webhooks.go:72)

Patches

v0.11.0

Workarounds

No.

References

n/a

Severity

4.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.10.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/soft-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T23:48:12Z",
    "nvd_published_at": "2025-11-08T02:15:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nIn several places where the user can insert data (e.g. names), ANSI escape sequences are not being removed, which can then be used, for example, to show fake alerts.\n\nIn the same token, git messages, when printed, are also not being sanitized.\n\nPlaces in which this was found:\n\n1. Repository Description (pkg/backend/repo.go - SetDescription)\n2. Repository Project Name (pkg/backend/repo.go - SetProjectName)\n3. Git Commit Author Names (pkg/ssh/cmd/commit.go:69)\n4. Git Commit Messages (pkg/ssh/cmd/commit.go:71)\n5. Access Token Names (pkg/ssh/cmd/token.go:107)\n6. Webhook URLs (pkg/ssh/cmd/webhooks.go:72)\n\n### Patches\nv0.11.0\n\n### Workarounds\nNo.\n\n### References\nn/a",
  "id": "GHSA-fv2r-r8mp-pg48",
  "modified": "2025-11-17T21:49:09Z",
  "published": "2025-11-06T23:48:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-fv2r-r8mp-pg48"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/commit/d9639320b8d0ccd76fe6836a042c042b0ebde549"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/soft-serve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Soft Serve does not sanitize ANSI escape sequences in user input"
}

GHSA-FWJX-9P69-H25H

Vulnerability from github – Published: 2026-07-24 22:35 – Updated: 2026-08-13 14:23

Summary

Oh My Posh: Terminal escape sequence injection via unsanitized prompt segment data

Details

Summary

Oh My Posh renders dynamic, potentially attacker-controlled strings (the current directory name, Git commit metadata, environment variable values, command output) into the prompt without neutralizing raw terminal control characters. An attacker who controls one of these values can inject ANSI/OSC escape sequences that the victim's terminal executes on every prompt render. (This is separate from the path-segment command-execution report; it has a different root cause and fix.)

Details

src/terminal/writer.go, write(s rune): the literal characters of rendered segment content are emitted to the output buffer, and the only neutralization is a lookup in formats.EscapeSequences, which per shell contains only the shell's prompt-length markers (\ for bash, % for zsh, nothing for fish/pwsh/cmd/nu). Raw C0/C1 control bytes (ESC 0x1b, BEL 0x07, CSI, OSC) are written verbatim.

Oh My Posh's own styling is emitted through separate paths (writeEscapedAnsiString, writeColorise, builder.WriteString(formats.Hyperlink...)), so any control rune reaching write(s rune) originates from rendered data. trimAnsi is already applied to the console title (FormatTitle) but not to the prompt body.

Attacker-controlled sources (both verified)

Current directory name (default config, Linux/macOS). Directory names may contain any byte except / and NUL, including 0x1b. The path segment renders the working directory in every theme.
Git commit subject / author / upstream URL (cross-platform, including Windows). Git.Commit() runs git log -1 --pretty=format:...su:%s... and exposes .Commit.Subject, .Commit.Author.Name/.Email and .RawUpstreamURL; Git imposes no restriction on these, so they can carry raw escape sequences.

PoC

Git commit-subject vector (config: a single git segment with template {{ .Commit.Subject }}):

printf 'feat: \033]0;HACKED\007\033]52;c;ZWNobyBQV05FRA==\007 update' > msg.txt
git commit --allow-empty -F msg.txt
oh-my-posh print primary --config poc.omp.json --shell fish | xxd

Output (excerpt) shows the attacker's OSC 0 (set title) and OSC 52 (clipboard write) passed through unmodified, wrapped only in Oh My Posh's colors:

...255m feat: 1b5d 303b 4841 434b 4544 07 1b5d 3532 3b63 3b5a 574e ... 07 ...
              ESC ] 0 ; H A C K E D  BEL  ESC ] 5 2 ; c ; <base64>  BEL

The directory-name vector reproduces identically via the path segment.

Impact

The terminal interprets the injected sequences on every render, enabling, per emulator: clipboard hijacking (OSC 52 write, so a command placed in the clipboard runs when the victim pastes), prompt/screen spoofing, window-title manipulation, and terminal denial of service. Delivery is remote (repo/archive/share); execution is local when the prompt renders after cd.

Suggested fix: neutralize C0/C1 control characters in untrusted segment data before it reaches the terminal, at minimum the path segment (folder names) and the git segment (Commit.Subject, Commit.Author.*, RawUpstreamURL). trimAnsi already exists and is applied to the title; extending equivalent handling to segment data closes the gap. Filtering control runes in write(s rune) would also work as defense in depth (Oh My Posh's own styling never flows through that function), optionally behind an opt-out for users who deliberately embed escapes in their own templates.

Severity

6.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 29.35.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/jandedobbeleer/oh-my-posh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "29.35.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T22:35:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nOh My Posh renders dynamic, potentially attacker-controlled strings (the current directory name, Git commit metadata, environment variable values, command output) into the prompt without neutralizing raw terminal control characters. An attacker who controls one of these values can inject ANSI/OSC escape sequences that the victim\u0027s terminal executes on every prompt render. (This is separate from the path-segment command-execution report; it has a different root cause and fix.)\n\n### Details\n`src/terminal/writer.go`, `write(s rune)`: the literal characters of rendered segment content are emitted to the output buffer, and the only neutralization is a lookup in `formats.EscapeSequences`, which per shell contains only the shell\u0027s prompt-length markers (`\\` for bash, `%` for zsh, nothing for fish/pwsh/cmd/nu). Raw C0/C1 control bytes (ESC `0x1b`, BEL `0x07`, CSI, OSC) are written verbatim.\n\nOh My Posh\u0027s own styling is emitted through separate paths (`writeEscapedAnsiString`, `writeColorise`, `builder.WriteString(formats.Hyperlink...)`), so any control rune reaching `write(s rune)` originates from rendered data. `trimAnsi` is already applied to the console title (`FormatTitle`) but not to the prompt body.\n\n### Attacker-controlled sources (both verified)\n1. Current directory name (default config, Linux/macOS). Directory names may contain any byte except `/` and NUL, including `0x1b`. The path segment renders the working directory in every theme.\n2. Git commit subject / author / upstream URL (cross-platform, including Windows). `Git.Commit()` runs `git log -1 --pretty=format:...su:%s...` and exposes `.Commit.Subject`, `.Commit.Author.Name`/`.Email` and `.RawUpstreamURL`; Git imposes no restriction on these, so they can carry raw escape sequences.\n\n### PoC\nGit commit-subject vector (config: a single git segment with template `{{ .Commit.Subject }}`):\n\n```\nprintf \u0027feat: \\033]0;HACKED\\007\\033]52;c;ZWNobyBQV05FRA==\\007 update\u0027 \u003e msg.txt\ngit commit --allow-empty -F msg.txt\noh-my-posh print primary --config poc.omp.json --shell fish | xxd\n```\n\nOutput (excerpt) shows the attacker\u0027s OSC 0 (set title) and OSC 52 (clipboard write) passed through unmodified, wrapped only in Oh My Posh\u0027s colors:\n\n```\n...255m feat: 1b5d 303b 4841 434b 4544 07 1b5d 3532 3b63 3b5a 574e ... 07 ...\n              ESC ] 0 ; H A C K E D  BEL  ESC ] 5 2 ; c ; \u003cbase64\u003e  BEL\n```\n\nThe directory-name vector reproduces identically via the path segment.\n\n### Impact\nThe terminal interprets the injected sequences on every render, enabling, per emulator: clipboard hijacking (OSC 52 write, so a command placed in the clipboard runs when the victim pastes), prompt/screen spoofing, window-title manipulation, and terminal denial of service. Delivery is remote (repo/archive/share); execution is local when the prompt renders after cd.\n\nSuggested fix: neutralize C0/C1 control characters in untrusted segment data before it reaches the terminal, at minimum the path segment (folder names) and the git segment (`Commit.Subject`, `Commit.Author.*`, `RawUpstreamURL`). `trimAnsi` already exists and is applied to the title; extending equivalent handling to segment data closes the gap. Filtering control runes in `write(s rune)` would also work as defense in depth (Oh My Posh\u0027s own styling never flows through that function), optionally behind an opt-out for users who deliberately embed escapes in their own templates.",
  "id": "GHSA-fwjx-9p69-h25h",
  "modified": "2026-08-13T14:23:11Z",
  "published": "2026-07-24T22:35:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/security/advisories/GHSA-fwjx-9p69-h25h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/commit/edcf3c88f3fb582e84358b385c49d33d04c04224"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/releases/tag/v29.35.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/releases/tag/v29.36.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Oh My Posh: Terminal escape sequence injection via unsanitized prompt segment data"
}

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