Terminal Injection: Why Your Logs Are a Remote Code Execution Vector

TLDR: ANSI escape sequences allow attackers to inject malicious payloads into log files that, when viewed by an administrator or security tool, can execute arbitrary commands or exfiltrate data. This research demonstrates that modern terminal emulators and log-viewing utilities are often vulnerable to these sequences, turning a simple log entry into a high-impact RCE vector. Security teams must prioritize input sanitization and output escaping to prevent terminal-based exploitation.

Terminal emulators are the primary interface for every security professional, yet we treat the data they display as inherently benign. We assume that a log file, once written to disk, is just static text. This assumption is dangerous. As demonstrated in recent research, ANSI escape sequences—the same codes used to colorize your terminal output—can be weaponized to manipulate the terminal environment itself. When an attacker injects these sequences into an application that later logs them, they aren't just writing text; they are sending instructions to the terminal emulator of whoever views those logs.

The Mechanics of Terminal Manipulation

ANSI escape sequences are standard control characters that tell a terminal to perform actions like moving the cursor, changing colors, or clearing the screen. The vulnerability arises when an application fails to neutralize these sequences before writing them to a log file. If an attacker can influence the input that gets logged, they can inject sequences that trigger unintended behavior in the terminal emulator used by an incident responder or a system administrator.

Consider a basic injection scenario. An attacker sends a request to a web application containing a payload designed to change the terminal text color to green. While this seems harmless, the same mechanism can be used to execute commands. By leveraging sequences like those documented in the XTerm control sequences, an attacker can manipulate the terminal state. The real danger appears when these sequences are combined with features like OSC 8, which allows for the creation of hyperlinks in the terminal. An attacker can craft a link that appears to point to a legitimate internal documentation site but actually executes a command or points to a malicious resource.

From Log Injection to RCE

The jump from simple log injection to arbitrary command execution is often mediated by the terminal emulator's features. Tools like iTerm2, Windows Terminal, and even the terminal integrated into VS Code have implemented advanced features to improve user experience. These features, such as file transfer over TTY or clipboard manipulation, provide the primitives an attacker needs to bridge the gap between the log file and the host system.

For instance, CVE-2022-45872 highlighted how specific terminal emulators could be tricked into executing commands via these sequences. The attack flow typically involves:

1. Injecting a payload into an application input field that gets written to a log file.
2. Waiting for an administrator to view the log file using a vulnerable terminal emulator or utility.
3. The terminal emulator interprets the injected ANSI sequences, triggering the malicious action.

This is a classic OWASP A03:2021-Injection scenario. The application is not properly neutralizing the input, and the terminal emulator is blindly trusting the instructions contained within the data stream.

Testing for Terminal Injection

During a penetration test or bug bounty engagement, you should treat any field that is eventually reflected in a log file as a potential injection point. This includes user agents, usernames, error messages, and API request parameters. To test for this, inject a simple sequence that changes the terminal color or triggers a bell sound. If you can change the color of the text in your own terminal by viewing the log, you have confirmed the vulnerability.

For more advanced testing, use tools like Nuclei to automate the discovery of these injection points. Create templates that inject various ANSI sequences and monitor for the expected terminal behavior. If you are working with a client, demonstrate the impact by showing how an attacker could potentially exfiltrate data or force the terminal to open a malicious URL. The goal is to show that the terminal is not just a passive viewer, but an active participant in the execution chain.

Defensive Strategies

Defending against terminal injection requires a two-pronged approach. First, applications must sanitize all user-supplied input before it is written to any log file. This means stripping or encoding non-printable characters and known ANSI escape sequences. Second, terminal emulators and log-viewing utilities should be configured to disable or strictly limit the interpretation of control sequences.

If you are a developer, ensure your logging libraries are configured to escape output by default. If you are an administrator, audit your terminal configurations. Many modern terminals allow you to disable specific features like OSC 8 or mouse tracking, which significantly reduces the attack surface.

The era of trusting our logs is over. As we continue to add features to our development tools, we inadvertently create new ways for attackers to reach our local machines. The next time you cat a log file, remember that you might be executing more than just text. Keep your tools updated, be skeptical of the data you view, and always look for the hidden control sequences that might be waiting to trigger a payload.