cat-astrophic ZMODEM Auto-Confirmation.
Tabby auto-confirmed ZMODEM traffic detected in terminal output leading to remote code execution.
Credit
This post covers GHSA-qr3x-j8g9-xhf6.
Finding
We found that Tabby enabled ZMODEM handling on terminal sessions by default, inspected raw terminal output for transfer headers, auto-confirmed detections, and wrote ZMODEM response bytes back into the active PTY.
That crossed an important boundary. Terminal output is data the user sees. PTY input is data the shell consumes. In affected versions, attacker-controlled output could cause Tabby to inject predictable input into the user’s shell without a prompt.
The resulting impact was local shell command execution when a user displayed crafted content in Tabby. A representative trigger was:
cat banner.txt
After the foreground process exited, the shell consumed the queued bytes as input.
For The Impatient
- Product: Tabby
- Affected versions: before 1.0.233
- Fixed version: 1.0.233
- Advisory: GHSA-qr3x-j8g9-xhf6
- Impact: shell command execution from attacker-controlled terminal output
- User interaction: displaying malicious content in a Tabby terminal session
- Confirmed shells: fish, bash, and zsh under the conditions documented in the advisory
- Researcher: Joey Tang
Background
ZMODEM is a file-transfer protocol commonly associated with rz and sz. Terminal emulators can improve that workflow by detecting ZMODEM traffic and starting a transfer UI.
The issue was not ZMODEM support. The issue was passive auto-detection on every session, followed by automatic confirmation and PTY write-back.
The Bug
The vulnerable data flow was:
session output
-> ZMODEM detector sees a valid init header
-> detector auto-confirms the transfer
-> ZMODEM session emits response bytes
-> Tabby writes those bytes back into the active PTY
-> shell reads them as input after the foreground program exits
Any source that can print attacker-controlled bytes into a Tabby terminal can reach the detector: a local file, an SSH peer, a serial device, a build script, or another process writing to the session. Once detection fired, Tabby emitted a predictable response into the same PTY.
The advisory documents shell-specific ways those bytes can become an executable command line under fish, bash, and zsh. The short version is that the queued protocol feedback can combine with shell expansion behavior and attacker-controlled filesystem state. The exploit does not require the current directory to be in PATH.
Delivery
One practical delivery path is a repository that asks the user to display a file:
git clone https://example.invalid/some/project
cd project
cat banner.txt
The repository contains the crafted display file and the executable path needed by the shell expansion step. Git preserves executable bits on POSIX systems, and unusual nested filenames can blend in with generated artifacts or test fixtures.
The user does not directly run the payload. They display a file.
Boundary
Terminal integrations need a clear boundary between displayed bytes and user input. A safer ZMODEM flow would require explicit consent before confirming a detected transfer, or would only enable protocol handling after a deliberate user action.
In affected Tabby versions, detection ran over raw session output, confirmation happened automatically, and response bytes went back into the active PTY.
Impact
The confirmed impact was local code execution in Tabby when a user displayed attacker-controlled content under the documented shell and filesystem conditions.
Delivery is not limited to cat on a local file. The vulnerable boundary is terminal output flowing through Tabby’s ZMODEM detector. That includes output from local programs, remote SSH sessions, serial devices, Telnet sessions, and anything else capable of printing controlled bytes into a Tabby terminal.
Remediation
Upgrade Tabby to 1.0.233 or later.
The direct fix is to remove automatic ZMODEM confirmation. A safer design requires explicit user consent before accepting a detected transfer and before writing protocol bytes back into the PTY.
Operators should review workflows where users display untrusted files or connect Tabby to untrusted interactive peers. This is especially relevant for teams that regularly clone public repositories, inspect challenge files, open vendor diagnostics, or work with serial consoles.
For detection, look for repositories or archives that combine:
- instructions to display a file in the terminal
- unusual terminal-control-heavy content
- nested executable files with generated-looking names
- path components that resemble color-query output or protocol residue
Timeline
- Report submitted: 2026-04-25 20:03:35 UTC
- GHSA published: 2026-05-07 22:18:48 UTC
Closing
The bug was not that Tabby supported ZMODEM. The bug was that a protocol helper treated terminal output as permission to write terminal input. Displayed bytes should not become shell input without an explicit user decision.
References
Advisory / GHSA-qr3x-j8g9-xhf6