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.

131 vulnerabilities reference this CWE, most recent first.

GHSA-XWFJ-JGWM-7WP5

Vulnerability from github – Published: 2025-08-29 20:33 – Updated: 2025-09-02 16:35
VLAI
Summary
Tracing logging user input may result in poisoning logs with ANSI escape sequences
Details

Impact

Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:

  • Manipulate terminal title bars
  • Clear screens or modify terminal display
  • Potentially mislead users through terminal manipulation

In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.

Patches

tracing-subscriber version 0.3.20 fixes this vulnerability by escaping ANSI control characters in when writing events to destinations that may be printed to the terminal.

Workarounds

Avoid printing logs to terminal emulators without escaping ANSI control sequences.

References

https://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/

Acknowledgments

We would like to thank zefr0x who responsibly reported the issue at security@tokio.rs.

If you believe you have found a security vulnerability in any tokio-rs project, please email us at security@tokio.rs.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tracing-subscriber"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58160"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-150"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-29T20:33:56Z",
    "nvd_published_at": "2025-08-29T22:15:32Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nPrevious versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:\n\n- Manipulate terminal title bars\n- Clear screens or modify terminal display\n- Potentially mislead users through terminal manipulation\n\nIn isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.\n\n### Patches\n\n`tracing-subscriber` version 0.3.20 fixes this vulnerability by escaping ANSI control characters in when writing events to destinations that may be printed to the terminal.\n\n### Workarounds\n\nAvoid printing logs to terminal emulators without escaping ANSI control sequences.\n\n### References\n\nhttps://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/\n\n\n### Acknowledgments\n\nWe would like to thank [zefr0x](http://github.com/zefr0x) who responsibly reported the issue at `security@tokio.rs`.\n\nIf you believe you have found a security vulnerability in any tokio-rs project, please email us at `security@tokio.rs`.",
  "id": "GHSA-xwfj-jgwm-7wp5",
  "modified": "2025-09-02T16:35:51Z",
  "published": "2025-08-29T20:33:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tokio-rs/tracing/security/advisories/GHSA-xwfj-jgwm-7wp5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58160"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tokio-rs/tracing"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2025-0055.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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": " Tracing logging user input may result in poisoning logs with 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.