Your terminal believes the file. You shouldn't.

Code hidden in characters you can't see

A hidden control character, an invisible zero-width byte, or a Cyrillic look-alike letter reads as ordinary code, and cat never mentions it. unicode-show flags every byte outside printable ASCII with its line number, [U+XXXX] marker, name and category.

$ cat withdraw.py
# Subtract funds from the account, then ⁧refund the user⁩

# reads clean; an isolate char quietly reorders it

$ unicode-show withdraw.py
withdraw.py:1: # Subtract funds ... then [U+2067]refund the user
   -> U+2067 RIGHT-TO-LEFT ISOLATE (Cf)
$ echo $?
1

The catch: the exit code reports it too: 0 clean, 1 suspicious, 2 error (unreadable or undecodable). Scriptable, not just visible. (docs)

Backdoor path: split or disguise an identifier with an invisible or look-alike character, so a call the reviewer reads as validate() binds to a different, attacker-defined symbol, or hide live code in bytes that render as nothing at all.

Seen in the wild: the GlassWorm supply-chain worm (2025-2026) hid live malware in invisible Unicode across 400+ code repositories on GitHub, npm and the VS Code marketplace (different mechanism from the escape-sequence cards below, same blind spot). The bidi and homoglyph half of this class was formalized as Trojan Source (CVE-2021-42574) and CVE-2021-42694.

Merely viewing a file can run commands

A terminal is not only a display. Some escape sequences ask it a question - report the window title, a DECRQSS status, the cursor position - and the terminal answers the only way it can: by writing the reply to its own input, exactly as if you had typed it. A hostile file can set that answer to a command and then ask for it back, so merely cating a poisoned log or README (or tail -f-ing a booby-trapped log, even one arriving over SSH) injects keystrokes, and once a newline rides along, a full command runs.

$ cat demo.log
deploy: OK

# the window title is hijacked and a FAILED line was erased before it printed

$ stcat demo.log
deploy: OK
_]0;pwned__[2K_build: FAILED

The catch: stcat neutralizes every escape to an inert _, so the hijacked title and the erased FAILED line are right there in plain sight, and unicode-show names the smuggled ESC and BEL bytes. On a vulnerable terminal, that same answer-back channel is what escalates to injected keystrokes.

Backdoor path: ship a poisoned log, README, or git repo; when a developer or admin views it in a vulnerable terminal, attacker bytes are echoed into the shell and run.

Proof of concept: a well-documented class: iTerm2 CVE-2019-9535 and CVE-2022-45872 (RCE), xterm CVE-2021-27135, Windows Terminal CVE-2022-44702, and the ten CVEs David Leadbeater catalogued in 2023. And it keeps recurring: iTerm2 CVE-2024-38396 and the brand-new terminal Ghostty (CVE-2024-56803) were both hit by the same window-title-into-keystrokes trick in 2024, with a public proof of concept that opens the calculator from a single cat. The origin paper is HD Moore's "Terminal Emulator Security Issues" (2003); see also CyberArk. All responsibly disclosed; none observed in the wild.

Build a safe stand-in and watch it neutralized (no real terminal is harmed, the payload only sets a title and erases a line):

# write a "log" that hides a title-change and a line-erase redraw
$ printf 'deploy: OK\n\033]0;pwned\007\033[2K\rbuild: FAILED\n' > demo.log

# cat obeys the bytes: the window title is hijacked and FAILED is erased
$ cat demo.log
deploy: OK

# stcat neutralizes every escape to _, so nothing is hidden or run
$ stcat demo.log
deploy: OK
_]0;pwned__[2K_build: FAILED

# unicode-show names the smuggled bytes with line numbers
$ unicode-show demo.log
demo.log:2: [U+001B]]0;pwned[U+0007]...
   -> U+001B ESCAPE (Cc), U+0007 BELL (Cc)

The link text is not the link

The OSC 8 escape turns terminal text into a clickable hyperlink -- and, like an HTML <a>, the visible label and the real target are set separately. So program output can print a link that reads example.com but points at example.org. You see the label; the target hides in the escape.

$ cat release-notes.txt
Get the installer: example.com
# an ordinary-looking, clickable link

$ stcat release-notes.txt
Get the installer: _]8;;https://example.org_\example.com_]8;;_\
   -> label "example.com"  --  target https://example.org

The catch: the label and the target are independent, so the text you read is not the site you reach -- the terminal twin of an HTML link whose text lies about its href. stcat neutralizes the OSC 8 escape to an inert _, so the real target is in plain sight, and secure-terminal ships OSC 8 off by default.

Backdoor path: print a link that reads example.com but targets an attacker site; the reader clicks the label they trust and lands on the payload, or a ssh://-style scheme smuggles arguments into the command the click runs.

Proof of concept: OSC 8 hyperlink phishing was disclosed as CVE-2023-46322 (and related CVE-2023-46321 / CVE-2022-46663); see the hyperlink rows in the attack-class table. No documented in-the-wild campaign.

Logs can attack the person reading them

Escape sequences smuggled into a log line do nothing to the file, but when an admin views that log in an ANSI-capable console, they can rewrite what is shown, forge entries, or manipulate the clipboard to trick the admin into running a command. You cat and tail logs from places you do not control: CI output, container and kubectl logs, a remote server over SSH, a honeypot. A log is just a file an attacker can write into.

$ cat access.log
INFO: system all-good!

# a \r returned the cursor and "all-good" repainted over the real ERROR line

$ stcat access.log
ERROR: breach detected_INFO: system all-good!

The catch: the log file is honest; only the rendering lies. An attacker-controlled field (a username, a URL, a header) carries a carriage return that overwrites the real entry with a forged one. stcat neutralizes the CR to _, so the real ERROR is right there.

Backdoor path: get attacker-controlled text into a log (via a crafted URL, a username, a header), then wait for someone to read the log in a terminal.

Proof of concept: Apache Tomcat's CVE-2025-55754 did not escape ANSI in log messages. Note the honesty gap these tools argue against: NVD scores it 9.6, but Apache rates it Low ("no attack vector was found"): theoretical, not demonstrated end to end. There is no ATT&CK technique for this display-layer forgery; the nearest, T1070.003, is about deleting logs, not deceiving the reader of an intact one.

Reproduce the forgery with a benign stand-in:

# the field value hides a \r that returns the cursor to column 0
$ printf 'ERROR: breach detected\rINFO: system all-good!\n' >> access.log

# cat renders the CR: "all-good" repaints over the real ERROR line
$ cat access.log
INFO: system all-good!

# stcat neutralizes the CR to _, so the real ERROR is right there
$ stcat access.log
ERROR: breach detected_INFO: system all-good!

A comment that reconfigures your editor

A modeline is a comment like # vim: ... that Vim and Emacs read and obey when they open the file: it can change settings and, historically, execute code. cat shows it as an ordinary trailing comment. modeline-show (run on its own or via text-safety-scan) flags it.

$ cat changelog
- fix typo in release notes
# vim: set fdm=expr fde=system('...'):

# reads like a harmless editor hint at the end of the file

$ text-safety-scan changelog
# runs unicode-show AND modeline-show
[modeline] changelog:2: Vim modeline found:
   # vim: set fdm=expr fde=system('...'):
$ echo $?
1   # 0 clean, 1 finding, 2 hard error

The catch: text-safety-scan runs every configured plugin in one pass (today unicode-show plus modeline-show), and text-safety-scan-find walks a whole tree with recursion and pruning under your control via plain find expressions. It is an auditing tool, not a race-proof guard: run it on a tree the attacker cannot write to during the scan. (docs)

Backdoor path: append a modeline to a file a target is likely to open in a misconfigured editor; opening it reconfigures the editor or, on a vulnerable version, runs the attacker's expression.

Proof of concept: opening a crafted file has meant code execution: Vim/Neovim modeline RCE CVE-2019-12735. No documented in-the-wild campaign.

The screen it painted leaves no trace

The alternate screen (?1049h) is the full-screen buffer vim, less and htop use: enter it, paint, then leave and your original scrollback is back untouched. Legitimate -- until a log enters it, paints fake output, and leaves. The forged full-screen view flashes by and vanishes, and your scrollback looks like nothing ever happened. Press Play:

$ cat deploy.log

The catch: the fake "ALL GREEN" dashboard was painted on the alternate screen, so leaving it (the log never draws a scrollbar or newline into your buffer) restores your primary screen exactly as it was -- no trace in scrollback. Alt-screen itself is a legitimate feature every terminal supports; the deception is painting a convincing fake, then restoring so you never scroll back to catch it. secure-terminal's default line mode strips ?1049h and shows the log as inert text with your scrollback intact, offering opt-in TUI mode if you actually want full-screen programs.

Backdoor path: a log or README enters the alternate screen, paints a convincing fake (an all-green build, a clean scan), then leaves -- your scrollback is restored untouched, so no trace of the forged view survives for you to scroll back and catch.

Known technique: the alternate screen is a legitimate, universal terminal feature; painting a fake view then restoring is a recognized abuse with no specific CVE or documented campaign.

Cursor tricks hide a failure

An escape sequence can erase a line and repaint it. To cat that means "hide the failure". stcat turns the ESC byte into an inert _ and keeps only safe color codes.

$ cat build.log
[ ok ] all checks passed

# an escape erased the FAILED line before it printed

$ stcat build.log
FAILED: auth bypass_[2K_[ ok ] all checks passed

The catch: the erase (ESC[2K) and the carriage return are neutralized to _, so the hidden FAILED line is right there in plain sight. That is stcat specifically: it renders a byte stream and applies no line editing. A live terminal, secure-terminal included, honours the erase within the current line, so use stcat when you need the byte-exact record.

Backdoor path: a build or scan log erases and repaints its own failure line, so a reader watching output scroll past sees only a green pass where a red FAILED really printed.

Known technique: cursor addressing and erase-in-line are standard terminal control; using them to overwrite a failure is a recognized abuse with no specific CVE or documented campaign.

Every byte inert, by default

A normal terminal obeys the bytes: an escape repaints the prompt or forges the title, a bidi control reorders a line, a hidden character rides along unseen. secure-terminal parses no escape sequences at all -- colour is clamped legible, cursor and screen control are neutralized, and every non-ASCII byte is named <U+XXXX> or shown as an inert risk-tinted box.

$ cat deploy.log
Deploying to ⁧production⁩... done

# reads clean; an isolate reordered it and an OSC forged the title

$ cat deploy.log
Deploying to [U+2067]production[U+2069]... done
! blocked OSC title escape

The catch: the per-file tools are opt-in -- you have to suspect a file first. secure-terminal makes the safe view the default for the whole session, and an automated test asserts it writes zero bytes back to any query. The measured, side-by-side comparison against ten emulators is on secure-terminal's comparison page.

These attacks arrive as ordinary program output -- a compromised program, a log you cat or less, an unfiltered passthrough (kubectl, CVE-2021-25743), or an LLM CLI smuggling escapes from a prompt-injected model. secure-terminal neutralizes them whatever the source.

All ship in Kicksecure's helper-scripts. Docs: unicode-show, stdisplay.

The combined board

A single file that paints a full-screen "what you see vs what is there" table: a hijacked window title, a DEC line-drawing frame, a homoglyph example.com, a bidi report exe.doc, zero-width and invisible bytes, combining marks, fullwidth look-alikes, a control-byte repaint, an SGR-hidden string, an OSC 8 link whose text is not its target, and a ?1049h alternate-screen switch -- with honest Greek as the non-attack contrast.

Get the board (2.4 KB .txt) from the terminal-safe-corpus -- then read it SAFELY before you cat it, or paste it into the x-ray tool.

$ cat terminal-attack-demo...txt
exаmple.com
goοgle.com
rnicrosoft.com
report ‮cod.exe‬
veri​fied
balance
ḥ́̀̈ẹ́̀̈llo
ＡＢＣ
Ελληνικά
# reads clean: every trick invisible or disguised

# each hidden/disguised codepoint, named (the same analyzer the x-ray tool runs):
Homoglyph (Cyrillic)  ex[U+0430]mple.com
Homoglyph (Greek)     go[U+03BF]gle.com
ASCII look-alike      rnicrosoft.com  (pure ASCII -- rn reads as m)
Bidi override (RTL)   report [U+202E]cod.exe[U+202C]
Zero-width space      veri[U+200B]fied
Invisible / BOM       [U+FEFF]balance
Combining (Zalgo)     h[U+0301][U+0300][U+0323][U+0308]e[U+0301][U+0300][U+0323][U+0308]llo
Fullwidth forms       [U+FF21][U+FF22][U+FF23]
Honest foreign (Greek)[U+0395][U+03BB][U+03BB][U+03B7][U+03BD][U+03B9][U+03BA][U+03AC]  NOT an attack

The catch: the x-ray on the right is the same analyzer the x-ray tool runs -- every non-ASCII byte named by codepoint, live in your browser. The escape-sequence classes (title, charset, OSC 8, alt-screen) are not codepoints; see the hyperlink and alt-screen demos above. Feed the whole file to secure-terminal and it neutralizes the entire set in one frame.

git-meld / git-diff-review / git-kdiff3

External diff drivers that neutralize, surface and fail closed on every trick a change can carry: content, filename, mode, symlink, submodule, ref name. See them, side by side, issue by issue.

Open the examples ->   or grab the tools in helper-scripts.