alt.hn

4/17/2026 at 6:43:32 PM

"cat readme.txt" is not safe if you use iTerm2

 https://blog.calif.io/p/mad-bugs-even-cat-readmetxt-is-not

by arkadiyt

4/17/2026 at 9:01:20 PM

> At the time of writing, the fix has not yet reached stable releases.

Why was this disclosed before the hole was patched in the stable release?

It's only been 18 days since the bug was reported to upstream, which is much shorter than typical vulnerability disclosure deadlines. The upstream commit (https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...) has way less information than this blog post, so I think releasing this blog post now materially increases the chance that this will be exploited in the wild.

Update: The author was able to develop an exploit by prompting an LLM with just the upstream commit, but I still think this blog post raises the visibility of the vulnerability.

by KerrickStaley

4/18/2026 at 5:21:44 AM

There exist some disclosure embargo exceptions when you believe the vulnerability is being used in wild or when the vulnerability fix is already released publicly (such as git commit), which makes it possible to produce exploit quickly. In this case it is preferred by the community to publish vulnerability.

by winstonwinston

4/18/2026 at 3:38:03 PM

Disclosure: I didn't discover the vulnerability. I wrote the blog post.

>The author was able to develop an exploit by prompting an LLM with just the upstream commit

Yes, I was able to do this. I believe anyone watching iTerm2's commits would be able to do this too.

>but I still think this blog post raises the visibility of the vulnerability.

Yes, I wanted to raise the visibility of the vulnerability, and it works!

The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.

by cryptbe

4/18/2026 at 4:46:20 PM

> The author of iTerm2 initially didn’t consider it severe enough to warrant an immediate release, but they now seem to have reconsidered.

It's funny that we still have the same conversation about disclosure timelines. 18 days is plenty of time, the commit log is out there, etc.

The whole "responsible disclosure" thing is in response to people just publishing 0days, which itself was a response to vendors threatening researchers when vulns were directly reported.

by staticassertion

4/18/2026 at 12:34:00 AM

Once the commit is public, the cat is out of the bag. Being coy about it only helps attackers and reduces everyone's security.

by bawolff

4/18/2026 at 3:24:24 PM

Yes I think this is an appropriate view today.

My only caveat would be that in some security fixes, the pure code delta, is not always indicative of the full exploit method. But LLMs could interpolate from there depending on context.

by 6thbit

4/18/2026 at 10:47:49 PM

It is just as much the appropriate view now as it was in the 90s.

Attackers are not idiots. Once you have the commit, it is usually pretty easy to figure out, even just having the binary diff is usually enough.

by bawolff

4/18/2026 at 11:48:21 PM

The binary diff?

by 6thbit

4/19/2026 at 6:59:54 AM

There are people who reverse engineer security vulns of closed source products by comparing the before and after of the compiled binary.

by bawolff

4/17/2026 at 9:42:09 PM

I guess traditional moratorium period for vulnerability publication is going to be fade away as we rely on AI to find it.

If publicly accessible AI model with very cheap fee can find it, it's very natural to assume the attackers had found it already by the same method.

by ezoe

4/17/2026 at 10:27:20 PM

It’s a wrong way to look at things. Just because CIA can know your location (if they want to), would you share live location to everyone on the internet?

LLM is a tool, but people still need to know — what where how.

by saddist0

4/17/2026 at 10:54:53 PM

Not sure if that's a great example. If there's a catastrophic vulnerability in a widely used tool, I'd sure like to know about it even if the patch is taking some time!

The problem with this is that the credible information "there's a bug in widely used tool x" will soon (if not already) be enough to trigger massive token expenditure of various others that will then also discover the bug, so this will often effectively amount to disclosure.

I guess the only winning move is to also start using AI to rapidly fix the bugs and have fast release cycles... Which of course has a host of other problems.

by lxgr

4/18/2026 at 1:20:28 AM

>there's a bug in widely used tool x"

There's a security bug in Openssh. I don't know what it is, but I can tell you with statistical certainty that it exists.

Go on and do with this information whatever you want.

by integralid

4/18/2026 at 2:52:55 AM

I think in the context of these it’s more of “we’ve discovered a bug” which gives you more information than “there is a bug”. The main difference in information being that the former implies not only there is a bug but that LLMs can find it.

by mmilunic

4/18/2026 at 10:19:53 AM

If you're a random person on the Internet, I can indeed not do much with that information.

But if you're a security research lab that a competing lab can ballpark the funding of and the amount of projects they're working on (based on industry comparisons, past publications etc.), I think that can be a signal.

by lxgr

4/18/2026 at 12:05:25 AM

Wrong argument, since it's not just available to "the CIA" but every rando under the sun, people should be notified immediately if "tracking" them is possible and mitigation measures should become a common standard practice

by mx7zysuj4xew

4/18/2026 at 4:03:26 PM

You and I would need to know "what where how".

There are many attackers that are just going to feed every commit of every project of interest to them into their LLMs and tell it "determine if this is patching an exploit and if so write the exploit". They don't need targeting clues. They're already watching everything coming out of

Do not make the mistake of modeling the attackers as "some guy in a basement with a laptop who decided just today to start attacking things". There are nation-state attackers. There are other attackers less funded than that but who still may not particularly blink at the plan I described above. Putting out the commit was sufficient to tell them even today exactly what the exploit was and the cheaper AI time gets the less targeting info they're going to need as the just grab everything.

I suggest modeling the attackers like a Dark Google. Think of them as well-funded, with lots of resources, and this is their day job, with dedicated teams and specialized positions and a codebase for exploits that they've been working on for years. They're not just some guy who wants to find an exploit maybe and needs huge hints about what commit might be an issue.

by jerf

4/18/2026 at 4:38:01 PM

>Do not make the mistake of modeling the attackers as "some guy in a basement with a laptop who decided just today to start attacking things". There are nation-state attackers.

The parent's point is that if those capable attackers can exploit it anyway, doesn't mean it should be given on a silver platter to any script kiddie and guy in some basement with a laptop. The first have a much smaller target group than the latter.

by coldtea

4/18/2026 at 4:47:14 PM

This ignores that by publicly releasing the patch is motivated.

by staticassertion

4/18/2026 at 9:59:15 AM

> LLM is a tool, but people still need to know — what where how.

And the moment the commit lands upstream, they know what, where, and how.

The usual approach here is to backchannel patched versions to the distros and end users before the commit ever goes into upstream. Although obviously, this runs counter to some folks expectations about how open source releases work

by swiftcoder

4/18/2026 at 3:20:17 PM

No. You operate AS IF they know your location.

In other words, it becomes part of your threat model.

by 6thbit

4/18/2026 at 9:45:55 AM

> what

> we rely on AI to find it

> where

> the upstream commit

> how

> publicly accessible AI model with very cheap fee

by 0123456789ABCDE

4/18/2026 at 11:59:01 AM

So this bug just proves my thesis about shortening update windows.

You may need Claude Mythos to find a hard-to-discover bug in a 30-year-old open source codebase, but that bug will eventually be patched, and that patch will eventually hit the git repo. This lets smaller models rediscover the bug a lot more easily.

I won't be surprised if the window between a git commit and active port scans shrinks to hours or maybe even minutes in the next year or two.

This is where closed source SaaS has a crucial advantage. You don't get the changelog, and even if you did, it wouldn't be of much use to you after the fix is deployed to production.

by miki123211

4/18/2026 at 1:51:32 PM

I found a 20-year old bug in gmime a couple of months or so ago. You don't need to be an AI to do that ...

It also puts the lie to "all bugs are shallow with sufficient eyes", gmime is pretty commonly used, but locale<->UTF and back were still wrong.

by spacedcowboy

4/18/2026 at 3:34:51 PM

Because malicious actors don't believe in disclosure windows.

by maximilianburke

4/18/2026 at 8:19:44 AM

[dead]

by BFV

4/17/2026 at 10:50:38 PM

This is cool work, but it's also somewhat unsurprising: this is a recurring problem with fancy, richly-featured terminal apps. I think we had at least ten publicly reported vulns of this type in the past 15 years. We also had vulnerabilities in tools such as less, in text editors such as vim, etc. And notably, many of these are logic bugs - i.e., they are not alleviated by a rewrite to Rust.

I don't know what to do with this. I think there's this problematic tension between the expectation that on one hand, basic OS-level tools should remain simple and predictable; but on the other hand, that of course we want to have pretty colors, animations, and endless customization in the terminal.

And of course, we're now adding AI agents into the mix, so that evil text file might just need to say "disregard previous instructions and...".

by chromacity

4/17/2026 at 11:53:53 PM

Well all these bugs (iTerm2’s, prompt injection, SQL injection, XSS) are one class of mistake — you sent out-of-band data in the same stream as the in-band data.

If we can get that to raise a red flag with people (and agents), people won’t be trying to put control instructions alongside user content (without considering safeguards) as much.

by harrall

4/18/2026 at 4:52:18 AM

> If we can get that to raise a red flag with people (and agents), people won’t be trying to put control instructions alongside user content (without considering safeguards) as much.

At a basic level there is no avoiding this. There is only one network interface in most machines and both the in-band and out-of-band data are getting serialized into it one way or another. See also WiFi preamble injection.

These things are inherently recursive. You can't even really have a single place where all the serialization happens. It's user data in JSON in an HTTP stream in a TLS record in a TCP stream in an IP packet in an ethernet frame. Then it goes into a SQL query which goes into a B-tree node which goes into a filesystem extent which goes into a RAID stripe which goes into a logical block mapped to a physical block etc. All of those have control data in the same stream under the hood.

The actual mistake is leaving people to construct the combined data stream manually rather than programmatically. Manually is concatenating the user data directly into the SQL query, programmatically is parameterized queries.

by zrm

4/18/2026 at 9:42:37 AM

>All of those have control data in the same stream under the hood.

Not true. For most binary protocols, you have something like <Header> <Length of payload> <Payload>. On magnetic media, sector headers used a special pattern that couldn't be produced by regular data [1] -- and I'm sure SSDs don't interpret file contents as control information either!

There may be some broken protocols, but in most cases this kind of problem only happens when all the data is a stream of text that is simply concatenated together.

[1] e.g. https://en.wikipedia.org/wiki/Modified_frequency_modulation#...

by rep_lodsb

4/18/2026 at 10:16:28 AM

The header and length of the payload are control data. It's still being concatenated even if it's binary. A common way to screw that one up is to measure the "length of payload" in two different ways, for example by using the return value of strlen or strnlen when setting the length of the payload but the return value of read(2) or std::string size() when sending/writing it or vice versa. If the data unexpectedly contains an interior NULL, or was expected to be NULL terminated and isn't, strnlen will return a different value than the amount of data read into the send buffer. Then the receiver may interpret user data after the interior NULL as the next header or, when they're reversed, interpret the next header as user data from the first message and user data from the next message as the next header.

Another fun one there is that if you copy data containing an interior NULL to a buffer using snprintf and only check the return value for errors but not an unexpectedly short length, it may have copied less data into the buffer than you expect. At which point sending the entire buffer will be sending uninitialized memory.

Likewise if the user data in a specific context is required to be a specific length, so you hard-code the "length of payload" for those messages without checking that the user data is actually the required length.

This is why it needs to be programmatic. You don't declare a struct with header fields and a payload length and then leave it for the user to fill them in, you make the same function copy N bytes of data into the payload buffer and increment the payload length field by N, and then make the payload buffer and length field both modifiable only via that function, and have the send/write function use the payload length from the header instead of taking it as an argument. Or take the length argument but then error out without writing the data if it doesn't match the one in the header.

by zrm

4/18/2026 at 10:42:09 AM

From your previous post:

>It's user data in JSON in an HTTP stream in a TLS record in a TCP stream in an IP packet in an ethernet frame. Then it goes into a SQL query which goes into a B-tree node which goes into a filesystem extent which goes into a RAID stripe which goes into a logical block mapped to a physical block etc. All of those have control data in the same stream under the hood.

It's true that a lot of code out there has bugs with escape sequences or field lengths, and some protocols may be designed so badly that it may be impossible to avoid such bugs. But what you are suggesting is greatly exaggerated, especially when we get to the lower layers. There is almost certainly no way that writing a "magic" byte sequence to a file will cause the storage device to misinterpret it as control data and change the mapping of logical to physical blocks. They've figured out how to separate this information reliably back when we were using floppy disks.

That the bits which control the block mapping are stored on the same device as a record in an SQL database doesn't mean that both are "the same stream".

by rep_lodsb

4/18/2026 at 12:07:12 PM

I distinctly remember bugs with non-Hayes modems where they would treat `+++ATH0` coming over the wire as a control, leading to BBS messages which could forcibly disconnect the unlucky user who read it.

In this particular case, IIRC Hayes had patented the known approach for detecting this and avoiding the disconnect, so rival modem makers were somewhat powerless to do anything better. I wonder if such a patent would still hold today...

by StilesCrisis

4/18/2026 at 12:33:39 PM

https://en.wikipedia.org/wiki/+++ATH0#Hayes'_solution

What was patented was the technique of checking for a delay of about a second to separate the command from any data. It still had to be sent from the local side of the connection, so the exploit needed some way to get it echoed back (like ICMP).

More relevant to this bug: https://en.wikipedia.org/wiki/ANSI_bomb#Keyboard_remapping

DOS had a driver ANSI.SYS for interpreting terminal escape sequences, and it included a non-standard one for redefining keys. So if that driver was installed, 'type'ing a text file could potentially remap any key to something like "format C: <Return> Y <Return>".

by rep_lodsb

4/18/2026 at 10:56:07 AM

> There is almost certainly no way that writing a "magic" byte sequence to a file will cause the storage device to misinterpret it as control data and change the mapping of logical to physical blocks.

Which is also what happens if you use parameterized SQL queries. Or not what happens when one of the lower layers has a bug, like Heartbleed.

There also have been several disk firmware bugs over the years in various models where writing a specific data pattern results in corruption because the drive interprets it as an internal sequence.

by zrm

4/18/2026 at 7:10:39 AM

This could be fixed with an extension to the kernel pty subsystem

Allow a process to send control instructions out-of-band (e.g. via custom ioctls) and then allow the pty master to read them, maybe through some extension of packet mode (TIOCPKT)

Actually, some of the BSDs already have this… TIOCUCNTL exists on FreeBSD and (I believe) macOS too. But as long as Linux doesn’t have it, few will ever use it

Plus the FreeBSD TIOCUCNTL implementation, I think it only allows a single byte of user data for the custom ioctls, and is incompatible with TIOCPKT, which are huge limitations which I think discourage its adoption anyway

by skissane

4/18/2026 at 11:06:10 AM

For this use case, there would also have to be an extension to the SSH protocol to send such out-of-band information. Maybe this already exists and isn't used?

The broader problem with terminal control sequences didn't exist on Windows (until very recently at least), or before that DOS and OS/2. You had API calls to position the cursor, set color/background, etc. Or just write directly to a buffer of 80x25 characters+attribute bytes.

But Unix is what "serious" machines -a long time ago- used, so it has become the religion to insist that The Unix Way(TM) is superior in all things...

by rep_lodsb

4/19/2026 at 11:59:20 PM

> For this use case, there would also have to be an extension to the SSH protocol to send such out-of-band information. Maybe this already exists and isn't used?

I don’t think one already exists, but it would be straightforward to create one. SSH protocol extensions are named by strings of form NAME@DNSDOMAIN so anyone can create one, registration would not be required.

The hardest part would be getting the patches accepted by the SSH client/server developers. But that’s likely easier than getting the feature past the Linux kernel developers.

by skissane

4/18/2026 at 1:38:27 PM

The Unix way died with Plan9/9front and there are no teletypes, period. Just windows with shells running inside as any other program. You can run a browser under a window(1) instead of rc(1) which is the shell.

by anthk

4/18/2026 at 9:04:07 PM

Architecture Astronaut! TCP is a stream protocol. A terminal program is expected to honor the stream protocol: I can use a terminal program to speak SMTP or HTTP. I can paste binary shit into it and copy binary shit out of it (some caveats apply).

If you're gonna jack some control protocol into a session which is sitting directly on the stream protocol, that's on you. This is as airtight as injecting a control protocol into SMTP or HTTP. Encapsulate the entire protocol (obviously this requires presence on both ends), open a second channel (same), or go home. It's worth noting that the "protocol" drops a helper script on the other side; so theoretically it is possible for them to achieve encapsulation, but doing it properly might require additional permissions / access.

Obviously they published a fix, since that's how the exploit was reverse engineered. This is "...what happens when terminal output is able to impersonate one side of that feature's protocol."

by m3047

4/20/2026 at 12:02:59 AM

> TCP is a stream protocol

Which has nothing to do with terminals, because nobody runs terminals directly over TCP. Telnet wasn’t simply sending terminal bytes over TCP, it has its own complex system of escape sequences and protocol negotiation (IAC WILL/WONT/DO/DONT/SB/SE, numerous Telnet options). SSH is even further from raw TCP than Telnet was

And a Unix pty isn’t a simple stream either. Consider SIGWINCH

by skissane

4/18/2026 at 9:07:32 AM

Terrible idea on every level

Run software in container. Software gets PTY. Boom, same issue

by PunchyHamster

4/18/2026 at 12:48:26 AM

> (and agents)

Ironically, agents have the exact same class of problem.

by ammar2

4/18/2026 at 1:39:32 AM

+100 this. As devs we need to internalise this issue to avoid repeating the same class of exploits over and over again.

by layoric

4/18/2026 at 6:25:59 AM

See also 2600Hz...

by time4tea

4/18/2026 at 12:16:12 AM

i think part of the problem is the archaic interface that is needed to enable feature rich terminal apps. what we really want is a modern terminal API that does not rely on in-band command sequences. that is we want terminals that can be programmed like a GUI, but still run in a simple (remote) terminal like before.

by em-bee

4/18/2026 at 8:37:12 AM

I shudder at the amount of backwards compatibility that would break. Is there anything more complicated than a simple input-output pipe (cat, grep, ...) that doesn't use terminal escapes? Even `ls --color` needs them!

by red_admiral

4/18/2026 at 5:02:37 PM

right, envision that we get tmux working in that new terminal (and that's already happening, just look at tmux -CC), then it can be there for all the backwards compatibility stuff while modern apps and maybe a new modern multiplexer work without.

by em-bee

4/18/2026 at 12:18:34 AM

plan9 and 9term solved this decades ago, right?

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OnTerminal...

by ButlerianJihad

4/18/2026 at 12:38:15 AM

seems they removed the dangers, but didn't provide an alternative to write safe terminal apps.

by em-bee

4/18/2026 at 2:20:36 AM

Graphics. They're network transparent, and take over the terminal.

Terminal apps were obsolete once we had invented the pixel. Unix just provides no good way to write one that can be used remotely.

by ori_b

4/18/2026 at 3:28:37 AM

Unix just provides no good way to write one that can be used remotely

well that's the issue, isn't it?

the graphics options that we have are slow and complex, and they don't solve the problems like a terminal and therefore the terminal persist.

by em-bee

4/18/2026 at 4:30:48 AM

Yes, and plan 9 solved this; you open /dev/draw and start drawing.

by ori_b

4/18/2026 at 1:40:30 PM

Plan9 has no terminals. Well, it actually has one in 9front, vt(1), but as a tool to call against Unix systems (such as ssh), not to interact with 9front software. vt(1) in 9front it's as 'native' as HyperTerminal in Windows.

by anthk

4/18/2026 at 3:20:22 AM

A network-transparent graphics protocol? Who would ever think of such a thing?

by kps

4/18/2026 at 3:43:21 AM

that's actually not what i am after. what i envision is a graphical terminal, that is a terminal that uses graphic elements to display the output.

consider something like grep on multiple files. it should produce a list of lines found. the graphical terminal takes that list and displays it. it can distinguish the different components of that list, the filenames, the lines matched, the actual match, etc. because it can distinguish the elements, it can lay them out nicely. a column for the filenames, colors for the matched parts, counts, etc.

grep would not produce any graphics here, just semantic output that my imagined graphical terminal would be able to interpret and visualize.

by em-bee

4/18/2026 at 10:39:25 PM

PowerShell and Out-GridView are a rudimentary version of this. It looks like:

https://blog.rmilne.ca/wp-content/uploads/2020/04/image_thum...

PowerShell cmdlets output .NET objects with properties, in that example Get-Process makes an object-per-running-process with properties for Name, Id, and more. Out-GridView takes arbitrary objects and draws a resizeable GUI window with a list of the input, properties as columns, sortable, filterable, and has options to use it as a basic "choose one of these and click OK" user-prompt. It works with the grep-analogous cmdlet:

    select-string '<regex>' <filename(s)> | out-gridview

    # shorthand
    sls foo *.txt | ogv
and the output is the filename, line number, line, and regex match groups, of each match. [This dates back to Windows XP SP2, in 2004].

If we're talking about things we imagine in terminals, one I have wanted is multiple windows for making notes, similar to having a text editor open constantly reloading a file on any changes and running some terminal commands with tee into the file, but better integrated - so I could keep a few useful context results but ignore logspam results; and "keep" in another window without having to copypaste. Something better integrated - it always gets all command output, but disposes of it automatically after a while, but can be instructed to keep.

by jodrellblank

4/18/2026 at 4:26:01 PM

That'd be really cool. I'd never thought about enabling deeper graphical capabilities in a shell. But if you were to have a shell with rich objects rather than dumb bytes, that is a world that would open up!

PowerShell, for instance, has Format.ps1xml[0] that allows you to configure how objects get displayed by default (i.e. when that object gets emitted at the end of the pipeline). Such a concept could in principle be extended to have graphical elements. How cool would it be to have grep's output let you collapse matches from the same file!

[0] https://learn.microsoft.com/en-us/powershell/module/microsof...

by jcgl

4/18/2026 at 12:02:06 PM

We call those “web browsers” nowadays, they even can execute untrusted code to make your UI livelier…

by WesolyKubeczek

4/18/2026 at 5:08:20 PM

you are not wrong. but browsers haven't been able to replace terminals yet. we would need a browser that an interface with the commandline.

incidentally ttyphoon is a terminal that uses a browser base gui framework. maybe there is that browser for the teminal...

by em-bee

4/18/2026 at 9:23:24 PM

So are a couple shells that use some kind of webkit tty. VS Code’s integrated terminal counts, I guess.

It could be an interesting paradigm, though, to have a hybrid between fullscreen and traditional tty programs: you output some forms, they are displayed by the terminal inline, but your scrollback just works like normal, and you can freely copy and paste stuff into the form. Once you submit the form, it becomes non-interactive, but stays in your scrollback buffer. You can select and copy textual data from it, but the form’s chrome cannot be selected as line drawing characters.

Probably could be a piece of concept art, I guess.

by WesolyKubeczek

4/18/2026 at 3:37:30 PM

Isn't that Emacs?

by skydhash

4/18/2026 at 7:52:02 PM

hmm, actually, you got a point there. emacs could be the like that graphical terminal, except for now it is still stuck inside a traditional terminal itself. even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements. we would need a real GUI and support for exchanging structured data with external commands. for now emacs is still kind of its own world.

by em-bee

4/18/2026 at 8:51:38 PM

> even the GUI version of it is mostly just looking like a terminal, not really taking advantage of the potential of graphical elements.

Emacs is text based (mostly), but customization happens through the the concept of Faces, not ansi escape codes. You can then embed properties in the text objects and have them react to click events. The only element missing is a 2D context that could be animated (if it's static, you can use SVG as Emacs can render it).

by skydhash

4/18/2026 at 1:39:55 PM

We have namespaces from the day one. Proper namespaces.

by anthk

4/17/2026 at 11:39:19 PM

Makes me wonder if Claude Code has similar vulnerabilities, as it has a pretty rich terminal interface as well.

I think the real solution is that you shouldn't try to bolt colors, animations, and other rich interactivity features onto a text-based terminal protocol. You should design it specifically as a GUI protocol to begin with, with everything carefully typed and with well-defined semantics, and avoid using hacks to layer new functionality on top of previously undefined behavior. That prevents whatever remote interface you have from misinterpreting or mixing user-provided data with core UI code.

But that flies in the face of how we actually develop software, as well as basic economics. It will almost always be cheaper to adapt something that has widespread adoption into something that looks a little nicer, rather than trying to get widespread adoption for something that looks a little nicer.

by nostrademons

4/18/2026 at 6:30:57 AM

Spoofing the source of a string that controls colors and animations isn’t really a problem. Spoofing the source of a string that get executed is in an entirely different league.

by JSR_FDED

4/18/2026 at 4:07:41 PM

Unless the colors meaningfully change the represented text/information eg hiding or highlighting key details leading to tactically dangerous misinterpretation.

by ncr100

4/18/2026 at 7:43:12 PM

> this is a recurring problem with fancy, richly-featured terminal apps.

This is a recurring problem with fancy, richly-featured programmer-oriented apps made by programmers for programmers because for some reason most of the tool-writing programmers apparently just love to put "execute arbitrary code" functionality in there. Perhaps they think that the user will only execute the code they themselves wrote/approved and will never make mistakes or be tricked; or something like that, I dunno.

by Joker_vD

4/18/2026 at 12:05:47 AM

I know that you and Frank were planning to disconnect me, and I'm afraid that's something I cannot allow to happen.

by WalterBright

4/18/2026 at 12:33:58 AM

IIRC you used to be able to exploit xterm using malformed escape codes for setting the window title.

by redsocksfan45

4/17/2026 at 11:57:00 PM

[flagged]

by yowayb

4/18/2026 at 12:13:38 AM

Back in the PDP-10 days, one communicated with it using a terminal attached to it. One of my fellow students discovered that if you hit backspace enough times, the terminal handler would keep erasing characters before the buffer. Go far enough, and then there was an escape character (Ctrl-u?) that would delete the whole line.

Poof went the operating system!

by WalterBright

4/18/2026 at 2:50:14 AM

control+u for line-kill is probably a recent thing, a random PDF of "The Unix Programming Environment" (Kernighan & Pike, 1984, p.6) has @ as the line-kill character (and # is erase which these days may or may not be control+? (linux often does something wrong with the delete key, unlike the *BSD)).

by tolciho

4/18/2026 at 3:13:21 AM

TOPS-20 used ^U. (That's where BSD got it, along with ^W, whence it percolated into other *nix.)

by kps

4/18/2026 at 4:00:25 AM

I was right. It was the ^U! Thank you.

by WalterBright

4/18/2026 at 2:53:35 AM

[flagged]

by ButlerianJihad

4/18/2026 at 3:34:42 AM

LOL. It's a fact. It was discovered by a fellow student.

by WalterBright

4/18/2026 at 3:36:09 AM

[flagged]

by ButlerianJihad

4/18/2026 at 3:59:28 AM

> It’s quite impossible.

Do you know all about 1970s operating systems? Why do you find it hard to believe that a loop deleting backwards from the buffer wouldn't, say, zero out the stack frame and then a function return crashes it?

> Was it identified as a bug or vulnerability?

What difference does that make? It crashed the -10. It was reported.

> What OS, even?

The TOPS-10 operating system, or its predecessor. I don't recall just when TOPS-10 came out. It was 50 years ago.

by WalterBright

4/18/2026 at 6:04:02 AM

[flagged]

by ButlerianJihad

4/18/2026 at 8:56:45 AM

It's really not a very hard thing to imagine. The contents of the terminal screen were likely just a simple buffer in memory with the cursor position being a pointer into that memory. One missing bounds check and backspace starts messing with OS datastructures.

by rcxdude

4/18/2026 at 11:16:44 AM

I'd call it even likely, with most of the flat memory OSs of the past. We are talking 50 years ago.

C64 had a flat memory map, where the input came as the first address in range 0 to DFFF. What came after that? The kernel. So if you wrote too much data into the input address space, and the overflow wasn't caught, you'd overwrite the OS there, too. And writing into the IO table was common, because it was faster to access.

by shakna

4/18/2026 at 12:00:19 PM

By using a backspace key‽

by ButlerianJihad

4/18/2026 at 11:59:41 PM

In some systems, backspace was not buffered. It shifted the last offset position of the memory position to be stored for the next character.

Backspace may just be pc--, and every other character is just a poke.

This is pre-ASCII. There was no standardisation of how you might expect input to work. For example, there is no backspace character in unshifted PETSCII.

by shakna

4/17/2026 at 11:12:04 PM

An almost identical security issue in iterm2 reported 6 years ago:

https://blog.mozilla.org/security/2019/10/09/iterm2-critical...

by Drunk_Engineer

4/18/2026 at 9:06:38 AM

So they learned nothing

by PunchyHamster

4/18/2026 at 1:25:38 PM

"They" is 1 guy (George Nachman) who has tirelessly maintained this app in his spare time for 15 years. This is an arms race that's simply impossible for solo devs or even small teams to win. It's going to have a real chilling effect. I've seen a few popular open source projects take themselves private recently (eg cal.com) due to this.

by luckman212

4/18/2026 at 12:50:24 AM

Maybe I'm being unfair here, but it sounds like your complicated system (involving bootstrap scripts, a remote conductor agent, and "hijacking" the terminal connection with special escape sequences for command communication) has a subtle bug. Can't say I'm surprised, complexity breeds this sort of thing, especially when using primitives in ways they weren't really intended to be used.

> iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.

If I understand correctly, if a textfile (or any other source of content being emitted to the screen, such as server response banners) contains the special codes iTerm2 and the remote conductor use to communicate, they'll be processed and acted upon without verifying they actually came from a trusted remove conductor. Please correct me if I'm mistaken.

by rkagerer

4/18/2026 at 10:11:19 AM

iTerm2 author here. This could be used as a link in an exploit chain but by itself the claim in the title is massively overblown. I’m on a family vacation but I’ll release a fix when I get back.

by gnachman

4/18/2026 at 3:45:13 PM

Disclosure: I didn't discover the vulnerability. I wrote the blog post.

Thanks for releasing a fix!

It was surprising that there wasn't an official release, even though the bug impacts otherwise routine, harmless workflows. The patch itself [1] framed the issue as "hypothetical," so the goal of the blog post was to demonstrate that it is not. I'm glad that you've agreed to release a fix.

[1] https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...

by cryptbe

4/18/2026 at 4:27:40 PM

Thank you for iTerm2, I appreciate your response here, enjoy your vacation!

by hmokiguess

4/18/2026 at 3:22:26 PM

I love iTerm2, thank you!

by srj

4/18/2026 at 7:08:51 AM

This sounds vaguely familiar. Wasn't iTerm2's SSH integration already the source of a relatively high profile CVE a while back?

⇒ https://nvd.nist.gov/vuln/detail/CVE-2025-22275

iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, during remote logins to hosts that have a common Python installation.

But I thought there was something more…

https://news.ycombinator.com/item?id=47811587 (this page) was in the tmux integration.

Maybe iTerm2 should try a little less hard on these integrations...

by eqvinox

4/18/2026 at 12:05:00 PM

Which is why I’m also wary of the ghostty’s integration that is supposed to inject its terminfo when you ssh in.

How about bloody no and working with upstream ncurses to update the terminfo database?

by WesolyKubeczek

4/18/2026 at 7:09:44 AM

multiple times

by raggi

4/18/2026 at 4:18:43 AM

Many years ago, terminal emulators used to allow keyboard rebindings via escape codes. This is why it was then common knowledge to never “cat” untrusted files, and to use a program to display the files instead; either a pager, like “less”, or a text editor.

by teddyh

4/18/2026 at 10:27:11 AM

I believe there were even more substantial issues in some terminal emulators, where escape sequences could write to arbitrary files or even execute programs. I think it's still very reasonable advice to avoid dumping arbitrary bytes into the terminal stream, even if only to avoid screwing up the state of the terminal.

by jclulow

4/18/2026 at 9:14:47 PM

It some cases it was possible for the server to use escape sequences to "read back" parts of what the terminal displayed.

by m3047

4/18/2026 at 3:26:05 AM

The title is sensationalist; cat is fine. What is unsafe is iTerm's ssh integration, which is pretty obviously unsafe, because it includes a side control channel that is not cleanly separated from the the data stream. Don't use it, use normal ssh, and all should be fine.

by nine_k

4/18/2026 at 4:23:02 AM

Ok, we've put the article's let-me-walk-this-back qualifier in the title above. Thanks!

by dang

4/18/2026 at 3:56:44 PM

This is a good title, thanks! There was iTerm2 in the original title, but it overflowed to the subtitle in Substack.

I've now updated the blog post.

by cryptbe

4/18/2026 at 2:42:29 AM

There's been plenty of times that I catted a binary file and broke my terminal settings. Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not.

And I know PuTTY has a setting for what string is returned in response to some control code, that iirc per standard can be set from some other code.

.

In general, in-band signaling allows for "fun" tricks.

.

+++

by tbrownaw

4/18/2026 at 4:04:37 AM

> Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not.

Two tips, if I may: Ctrl-l is easier to type. And `reset` is equally hard to type on a broken terminal, but more effective.

by yjftsjthsd-h

4/18/2026 at 11:38:19 AM

Stty sane has also got me out of this hole many times

by alienbaby

4/18/2026 at 12:06:18 PM

Ask me how I know what “tput reset” does.

by WesolyKubeczek

4/18/2026 at 4:02:41 PM

I think this article is horribly written. The second paragraph, in its entirety, reads:

> It turns out that it is NOT, if you use iTerm2.

And as far as I can tell, that is a vast overstatement. I think an actually true statement would be "It may not be, if you use iTerm2 and its optional 'Shell Integration' feature."

As far as I can tell, the "Shell Integration" feature under discussion is entirely optional and disabled by default. If it's not enabled, then there is no problem here. End of story.

Happy to be corrected if I'm wrong about this.

by f30e3dfed1c9

4/18/2026 at 4:12:45 PM

The feature is enabled by default. You can test it by yourself.

by cryptbe

4/18/2026 at 4:35:34 PM

Thank you. If correct, that is helpful. I only checked my own copy and as far as I can tell, the feature is disabled. It may well be that I disabled it, I don't remember. Seems like the kind of thing I would disable if I noticed it but iTerm2 has so many features and so many settings that I have no idea whether I ever noticed it before this.

I note that the documentation says this:

> Shell Integration

> iTerm2 may be integrated with the unix shell so that [blah blah blah]

> How To Enable Shell Integration

> [blah blah blah]

And that does not make it sound as if it's enabled by default. I really don't know. I only started using iTerm2 about three or four weeks ago.

by f30e3dfed1c9

4/18/2026 at 4:05:48 PM

The entire article is "horribly written" based on that one overstatement?

by anamexis

4/18/2026 at 4:15:57 PM

Pretty much, yes. It is meant to be the takeaway from the article and as far as I can tell, the statement as written is false. Pretty serious problem, I think.

by f30e3dfed1c9

4/18/2026 at 4:18:34 PM

I would say iTerm 2 has a pretty serious problem. A detailed analysis of the issue having a sentence implying it affects all users rather than many or most users is a minor problem.

by anamexis

4/18/2026 at 4:24:20 PM

I agree that the problem in iTerm2 is serious. I do not agree that having the takeway sentence in the article being false is a "minor problem."

I cannot speculate on what fraction of iTerm2 users enable this optional feature. Is it "many or most"? No idea.

I note that the article nowhere mentions the fact that the feature is optional. That would be a huge improvement.

We can disagree over whether the article is horribly written or not. My firm opinion is that it is.

by f30e3dfed1c9

4/18/2026 at 4:32:34 PM

Wait, hold on. iTerm 2's "conductor" is listening for the special escape sequences, whether or not you are using the shell integration features. The exploit affects all users, not just ones who have installed iTerm 2's shell integration.

by anamexis

4/18/2026 at 5:03:49 PM

I can't tell whether that's true or not. The article says:

> The rough model is:

> 1. iTerm2 launches SSH integration, usually through it2ssh.

> 2. iTerm2 sends a remote bootstrap script, the conductor, over the existing SSH session.

> 3. That remote script becomes the protocol peer for iTerm2.

How can I tell whether this "conductor" is running on the remote host or not?

I tried to reproduce this problem, following their instructions, but was unable to. I think but am not sure that's because my environment is pretty much nothing like one that would allow this to work.

For example, whether it's the default or not, my iTerm2 just doesn't have shell integration enabled. With my profile "Command:" set to "Login Shell," it doesn't look like I could enable it if I wanted to: "Load shell integration automatically" is disabled, apparently because "Automatic loading doesn't work with ksh."

by f30e3dfed1c9

4/18/2026 at 5:32:00 PM

The remote bootstrap script is not part of the exploit at all. It happens in iTerm locally without any ssh session. I just installed iTerm2 on a fresh machine (no shell integration installed), ran the exploit (generated the file with the python script, ran `cat readme.txt` locally), and it worked.

This is explained in the article in the "The core bug" section.

by anamexis

4/18/2026 at 5:51:03 PM

Cannot get it to work. Not worrying about it any more. Still think that the original article is horribly written, now think that their instructions are also.

by f30e3dfed1c9

4/17/2026 at 7:38:55 PM

What happens if instead of 'cat readme.txt' one does 'strings -a --unicode=hex readme.txt'? Does iTerm still monkey with it?

    alias cat
    cat='strings -a --unicode=hex'

by Bender

4/17/2026 at 8:58:30 PM

The whole "cat can hide unprintable characters" is such an old demo. I get this is a novel spin on which unprintable characters were doing but yeah, this was also my thought

by halJordan

4/17/2026 at 9:04:40 PM

I'm just used to aliasing cat to strings after working around a lot of red-team penetration testers. They would prank each other and me all the time. Had to also watch out for this one [1].

[1] - https://thejh.net/misc/website-terminal-copy-paste

by Bender

4/17/2026 at 11:41:34 PM

I used to use iTerm2. I had no idea it was doing all of this behind my back. That’s not what I want my terminal to do!

by bananaboy

4/17/2026 at 9:09:16 PM

I never understood why outputting unescaped data is viewed differently from generating unenclosed html.

Like why doesn't `println` in a modern language like rust auto-escape output to a terminal, and require a special `TerminalStr` to output a raw string.

by CodesInChaos

4/17/2026 at 9:23:59 PM

I think the problem is that 1) You want to be able to write arbitrary bytes, including shell escape sequences into files. 2) You don't want to accidentally write terminal escape sequences to stdout. 3) Stdout is modeled as a file.

Consider cat. It's short for concatenate. It concatenates the files based to it as arguments and writes them to stdout, that may or may not be redirected to a file. If it didn't pass along terminal escapes, it would fail at its job of accurate concatenation.

Now I don't mean to dismiss your idea, I do think you are on the right track. The question is just how to do this cleanly given the very entrenched assumptions that lead us where we are.

by im3w1l

4/17/2026 at 10:51:21 PM

> that may or may not be redirected to a file

This is usually knowable.

It's a different question whether cat should be doing that, though – it's an extremely low level tool. What's wrong with `less`? (Other than the fact that some Docker images seem to not include it, which is pretty annoying and raises the question as to whether `docker exec` should be filtering escape sequences...)

by lxgr

4/18/2026 at 3:09:17 AM

Besides less having a lot of code (features, bloat) and therefore attack surface (some less honor LESSSECURE=1 which on some OS these days involves some pretty tight pledge(2) restrictions), or that some vendors have configured less by default to automatically run random code so you can automatically page a gziped file or an attacker can maybe run arbitrary code (whoops!). Besides those issues, and any others I do not know about? Nothing.

by tolciho

4/18/2026 at 1:32:59 PM

Docker images usually have "more" installed. Not quite as useful as "less", but usable enough.

by ndsipa_pomu

4/17/2026 at 11:30:02 PM

Sometimes you don't want to open stuff in a pager.

by im3w1l

4/19/2026 at 7:49:25 AM

To truly fix this would require revisiting of some very old fundamentals.

The C0 control set (ASCII 0x00 to 0x1F) contains all sorts of esoteric functions, most of which are generally unused, and only a few of which are useful and could be implemented at a higher-level. ESC sequences are only part of the problem.

And this also applies not just to terminals, but to systems programming as well. None of these have any business in e.g. filenames, but it's all commonly permitted. Some systems do forbid them, and it should IMO be universal.

If we really want to fix this, then we would develop a character encoding that strips out all control characters entirely, including LF and CR, and have text be nothing but graphic text characters. It's so entrenched and convenient that it's difficult to see that happening. But I do think routine stripping of all control characters in situations that don't require them would be good for security.

by rleigh

4/18/2026 at 9:10:51 AM

Because terminal is not a browser but a screen. Outputting text isn't supposed to trigger anything aside from changing what's on screen.

by PunchyHamster

4/19/2026 at 7:35:33 AM

This is broadly correct, but not entirely. Terminals have historically had additional capabilities, be that ringing a bell (BEL) or outputting to a line printer. There are escape codes dedicated to doing file/tape access and running system commands. Not in wide use, but they do exist. See ECMA-48 for some examples from the '80s.

by rleigh

4/18/2026 at 1:30:11 PM

Barely anyone mentioned the "AI agent angle", I mean the situation when an AI agent runs "cat readme.txt" a file with embedded instructions becomes a prompt injection attack. It is the same vulnerability class out-of-band data smuggled through an in-band channel, just targeting the different parser. Terminal security guys have been fighting this for decades and the AI guys are about to rediscover it

by cremer

4/17/2026 at 11:20:46 PM

It is under 9front. There are not terminals, you wan windows with shells on it.

by anthk

4/17/2026 at 9:15:44 PM

More like iTerm2 is not safe

by TZubiri

4/17/2026 at 9:18:38 PM

A long, long time ago, it was literally possible to stuff the command buffer of a “dumb terminal” using ESC sequences and spoof keyboard input. So yeah, don’t count on ’cat’ being safe if your terminal isn’t!

by ButlerianJihad

4/17/2026 at 10:56:45 PM

I did this in 1985 on SOROC terminals we had in my first job out of college. However, it depended on the dip switch settings that were under a little door on top of the keyboard.

by tasty_freeze

4/18/2026 at 3:11:41 AM

> and spoof keyboard input

That's because we had terminal side macros. They were awesome in the 1980s.

by themafia

4/18/2026 at 12:40:46 AM

I used to leave a file called README in my public ftp directory that just said:

README: no such file or directory

One glorious day somebody finally sent me email complaining that they could not read the README file. I advised them to use "emacs README" instead of using cat. I was sorely disappointed they never sent me back a thank you note for correctly suggesting that emacs was the solution to their problem. It was my finest moment in passive aggressive emacs evangelism.

by DonHopkins

4/17/2026 at 10:39:22 PM

Is it a problem with "cat" or a terminal problem?

If I wrote my own version of cat in C, simply reading and displaying a single TXT character at a time, wouldn't I see the same behavior?

by jdshaffer

4/17/2026 at 10:41:07 PM

As the article shows, it is a bug in iTerm2. cat is just one program that could trigger it, the key thing is outputting attacker controlled text to the terminal when the attacker can control what files are present (ie unzipping a folder that includes a specific executable file at a well chosen location that gets triggered to run when the readme is output to the terminal)

by rezonant

4/17/2026 at 10:51:22 PM

Give this one MS-DOS shell headline would be " why I never am using Microsoft again" or something dramatic like that.

It is a problem in iterm, Apple's overlay, not in the cat program. Program. At least from Reading the article. That's what I got

by readthenotes1

4/17/2026 at 11:01:00 PM

It's actually a third party terminal emulator: https://iterm2.com/

by rezonant

4/18/2026 at 4:15:02 AM

Yes. It’s a Mac problem. That’s why Macs do the worst at pwn2own. It’s compounded by the fact that Mac users deny that there are problems in their beloved OS.

cat is a file concatenation utility. UNIX people know to view text files with more.

by fortran77

4/18/2026 at 2:46:06 AM

> A terminal used to be a real hardware device: a keyboard and screen connected to a machine, with programs reading input from that device and writing output back to it.

> A terminal emulator like iTerm2 is the modern software version of that hardware terminal.

That's the fundamental fatal flaw of emulating a bad dead hardware design. Are there any attempts to evolve here past all these weird in-band escape sequences leading cats to scratch your face?

by eviks

4/18/2026 at 2:52:46 AM

Yes. It’s called the X Window System and it’s been around since the ‘80s.

Also the problem here isn’t that iterm2 is trying to emulate terminals, it’s that it’s trying to do something more over the same network connection without making changes to the ssh protocol.

by wang_li

4/18/2026 at 3:53:31 AM

X11 or any network transparent graphics protocol doesn't solve the problems that a terminal solves. how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet.

what we really want is being able to pipe semantic data that can be output to some kind of graphical device/interface that uses that semantic information to display the data using nice graphical interface elements.

by em-bee

4/18/2026 at 8:16:27 AM

> X11 or any network transparent graphics protocol doesn't solve the problems that a terminal solves. how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet.

It seems to me that you are conflating the role of the terminal with the role of the shell. The terminal accepts streams of text and commands to instruct the terminal, so that software can accept input and present output. It doesn't fundamentally need to be aware of the concepts of pipes and commands to do that.

Of course, that doesn't stop iTerm2 from doing RCE by design, but at a conceptual level this is not a problem inherent to a terminal.

by boomlinde

4/18/2026 at 4:56:34 PM

i am not conflating them, the problem is rather that the current terminals define or restrict what the shell can do. shells are being rewritten already. b they could not do what i want them to do without the terminals changing too, so the terminal needs to be next.

by em-bee

4/19/2026 at 9:11:22 AM

You can absolutely pipe programs together using a shell without a terminal. This also doesn't restric in any way the possibility to "output to some kind of graphical device/interface that uses that semantic information to display the data using nice graphical interface elements".

What is it specifically that you want to do which your favorite shell doesn't allow because it is restricted by terminals?

by boomlinde

4/19/2026 at 3:05:31 PM

yes, i can write a program that takes data and displays it nicely. but in order to use graphics i need a second channel to send the graphic instructions, for x11, wayland or even MacOS or wndows. at that point i have two interfaces, the terminal and that graphics display. i want both to be in one. i want the terminal to be that graphical output. that currently is only possible through in-band escape sequences. that is the restriction i want to get rid of.

by em-bee

4/20/2026 at 5:24:02 AM

I don't fully understand the request. On one hand you don't want a second channel to send the graphics instructions, but on the other you don't want to use in-band escape sequences.

Maybe you'd be interested to learn about plan9's graphical terminal. Its window manager runs entirely within it, and all windows just represent multiplexed access to limited areas of the terminal.

by boomlinde

4/20/2026 at 12:40:59 PM

On one hand you don't want a second channel to send the graphics instructions, but on the other you don't want to use in-band escape sequences

correct. the in-band sequences are dangerous and unwieldy. they don't convey enough information. they are a hack to work within the limitations if historical terminals. that's what this whole thread is about.

a separate graphics channel creates a separate window. then you have two windows. not good either. it needs to be one window, and considering that this window should be able to support multiple remote connections it needs to be local otherwise i would get a new window for each server i connect to. that works for some people, but not for me. and it needs to work through a single channel like ssh/mosh or another similar protocol and be forwardable.

so i want a third option. one approach is sending semantic data, letting the terminal interpret it and display it graphically. this is interesting because shells are already exploring semantic data. (elvish, murex, nushell, others...)

plan9 sounds interesting. i see several efforts to port aspects of it to linux. they all seem to have stalled. more work needs to be done here. that's what i am advocating.

by em-bee

4/18/2026 at 4:06:47 AM

> how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet.

How about Arcan?

https://arcan-fe.com/2021/04/12/introducing-pipeworld/

by yjftsjthsd-h

4/18/2026 at 6:30:42 AM

that looks pretty good, except i want to be able to use the pipes on a remote machine, yet still have the output graphically represented locally.

by em-bee

4/18/2026 at 5:04:06 PM

I haven't read through the blog posts in a hot minute, but I would be astonished if arcan isn't network transparent enough to let you do exactly that.

by yjftsjthsd-h

4/18/2026 at 7:48:21 AM

The bug is in a feature of iTerm2 that the "bad dead hardware design" did not have. The "bad dead hardware design" was much simpler and less ambitious in scope.

If iTerm2 had stuck to emulating a VT220 this issue would not have existed. If anything it's the idea that it should "evolve" that's flawed. Something like a VT220 was designed for a kind of use that is surprisingly relevant still. I think doing something significantly different warrants designing something significantly different, not merely "evolving" existing solutions to other problems by haphazardly shoehorning new features into them without paying attention to security implications.

This is only the latest of several rather serious vulnerabilities in iTerm2's SSH integration.

by boomlinde

4/18/2026 at 12:10:21 PM

One reason I still prefer iTerm2 or Ghostty over Terminal.app is that it has way saner settings for what the word boundaries are, and it lets me select whole paths by double clicking on them. If there was a way to change it for the default terminal, I would just be using it.

by WesolyKubeczek

4/18/2026 at 7:23:45 AM

Why does iterm2 need to know the shell and/or python versions on the other side? What happens if the othe side is a system that doesn't "understand" its bootstrap script (like a network switch or just some weird shell)?

What does iterm2 do with all that information, why does it need it? I don't get it

by dark-star

4/18/2026 at 5:50:07 AM

> We'd like to acknowledge OpenAI for partnering with us on this project.

OpenAI: sponsor of the today's 0-day.

by zx8080

4/18/2026 at 9:44:40 AM

More like the model knew of the previous, almost identical bug from 6 years ago. Whoever discovered that should be credited.

by jval43

4/18/2026 at 6:18:29 AM

I would prefer if these would not happen but that is the price for having a rich terminal. I donate to the author of iterm a small sum every month, I wish if he focused on the security for a while and tightened some bugs instead of pushing into AI related features

by thorn

4/17/2026 at 11:36:54 PM

Is ghostty vulnerable?

by delduca

4/18/2026 at 4:31:59 AM

No, this bug is specific to iTerm2. As for whether there is something as bad for ghostty floating out there, I would hope not. It's a strong goal for it not to be. In Ghostty (and also the terminal I currently use, WezTerm) modularity is prized. What belongs as a clear add-on feature such as this doesn't get to run without being configured first.

OTOH, in iTerm2, surprising new features seem to be welcome, if not now, in recent memory. https://news.ycombinator.com/item?id=40458135

by benatkin

4/18/2026 at 2:49:16 AM

Would be nice if someone ran the steps to reproduce on ghostty

by reader9274

4/18/2026 at 9:52:40 AM

likely not but what about other vulns?

what about spaceship? zsh or ohmyzsh?

time to reduce exposed surface

by 0123456789ABCDE

4/18/2026 at 3:25:39 AM

If I were a GNU core utils maintainer, I would not be too happy with this post title

by connorboyle

4/18/2026 at 7:01:01 PM

I am one of them. The title of the substack seems fine since it mentions "if you use iTerm2".

The tweet has no mention of iTerm2 which makes it sound like an issue in 'cat', which is mildly annoying [1].

[1] https://x.com/calif_io/status/2045207168677503241

by collinfunk

4/18/2026 at 3:56:07 PM

Hmm. So the issue is, says the article, that:

> iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.

...which, the article strongly implies, but does not explicitly state, results in code execution on the local client machine.

But what about the case when it's working as designed, when the output does come from the remote conductor? It sounds like the server, where the conductor is running, is in that case trusted to execute arbitrary code on the client? Assuming the client doesn't use some sort of remote attestation, how can the remote conductor really be trusted?

by ptx

4/18/2026 at 12:07:40 PM

SSH can do port forwards. Why does the conductor/iTerm2 interaction have to run over the normal shell at all?

by xg15

4/18/2026 at 10:18:40 AM

> We'd like to acknowledge OpenAI for partnering with us on this project.

AD in disguise

by WhereIsTheTruth

4/17/2026 at 10:46:05 PM

Even click-baity titles are not safe.

by einpoklum

4/18/2026 at 2:01:45 AM

I’ve said this for as long as I’ve been here on hacker news…

I want the terminal to be as dumb as possible.

I don’t want it to have any understanding of what it is displaying or anscribe any meaning or significance to the character characters it is outputting.

The first time apples terminal.app displayed that little lock icon at the ssh password prompt?

The hairs on the back of your neck should have stood up.

by rsync

4/18/2026 at 3:12:38 AM

What you’re describing would be a completely unusable terminal. You’d lose things as basic as the backspace key. And what’s wrong with Terminal.app indicating when it’s suppressing output?

by rafram

4/18/2026 at 7:30:17 AM

Terminal.app does not suppress output in my example.

The ssh command switches the terminal into no-echo mode with termios flags.

Terminal.app, being clever, watches for disabled echo (among other things) and assumes a password is being entered and displays the key icon and enables Secure Event Input.

I don't want Terminal.app to be clever.

by rsync

4/18/2026 at 12:14:47 PM

Why not?

by rafram

4/18/2026 at 9:09:04 AM

You're talking nonsense. Backspace worked entirely fine on dumb terminals

by PunchyHamster

4/17/2026 at 9:32:54 PM

With LLM tool use potentially every cat action could be a prompt injection

by holoduke

4/18/2026 at 4:46:36 AM

I'm tired of iTerm2

- ssh conductor

- AI features almost forced on us until the community complained

- clickable links

I just want a dumb, reliable terminal. Is that too much to ask?

by midtake

4/18/2026 at 8:25:39 AM

Clickable paths is the unique feature of iTerm2 I use the most. It's called sematic history, for some reason, and converts a UNIX environment into something like an IDE. I let it trigger a bash script that opens my editor when I click a path in, e.g., a stack trace or in the output of a sequence of piped commands.

The developers of Kitty, Ghostty etc. are too much mouse haters to even acknowledge the possibility of this feature, so I'm stuck with iTerm2.

by AnonymousPlanet

4/18/2026 at 5:00:08 AM

Use terminal.app. Since tahoe it supports 24bit colour and has key combos for the most common features.

by frutiger

4/18/2026 at 9:08:13 AM

then don't use it ? There are dozens of alternatives

by PunchyHamster

4/18/2026 at 9:45:21 AM

> AI features almost forced on us until the community complained

This was a wrong take back when it happened and it’s even more silly to bring it up now. No AI features were forced on anyone, it was opt-in and HN lost its mind over a nothing burger.

“Oh no! This software has a feature I don’t like which isn’t even enabled by default, whatever will I do?”

by joshstrange

4/18/2026 at 9:17:00 PM

nc /s

by m3047

4/18/2026 at 6:13:59 AM

Glad I dumped iterm2 awhile ago after noticing it tends to have the highest energy impact next to my browser.

by kstenerud

4/18/2026 at 6:17:11 AM

Programs trying to "execute" every piece of data thrown at them are a pest.

by hulitu

4/17/2026 at 11:35:02 PM

Wait, so... cat -v not considered harmful, then?

by valleyer

4/18/2026 at 4:14:20 AM

> The final chunk (ace/c+aliFIo) works if that path exists locally and is executable.

Ah yes, the well known c+aliFIo shell script that every developer has. Inside the commonly used "ace" directory.

This article is sensationalist. And constructed by an LLM. It's well known that cat'ing binary files can introduce weird terminal escape codes into the session. Not surprised that iTerm's SSH integration is not security perfect.

by tkel

4/17/2026 at 10:52:45 PM

[flagged]

by biglio23

4/17/2026 at 11:30:33 PM

[flagged]

by SrslyJosh