News for hackers. Stuff that matters.
Re:Show HN: ssh ssh.place by applfanboysbgon on Monday August 03, 2026 @02:10AM (#49151800)
There has never been a real-world OpenSSH exploit that allows a server to RCE a client that connected to it without a bunch of dubious qualifiers. Connecting to a random SSH server is much, much less dangerous than running a random binary or executing a random curl install script, both of which people do all the time, and is probably about on par with the likelihood of a random website escaping your browser's sandbox and RCEing you.
Re:Show HN: ssh ssh.place by lxgr on Monday August 03, 2026 @04:13AM (#49152704)
Agreed, bugs in the terminal emulator are probably more concerning. The attack surface of those is much larger (there are some pretty wild ANSI escape sequences, and terminal emulators are often granted pretty wide disk access permissions on systems that have them if they're also used for local development).
Re:Show HN: ssh ssh.place by Oxodao on Monday August 03, 2026 @02:54AM (#49152101)
If you properly set up your ssh client (No agent forwarding or X11 forwarding)
Re:Show HN: ssh ssh.place by LoganDark on Monday August 03, 2026 @03:56AM (#49152587)
Terminal, too; some escape sequences are able to perform attacks in old or buggy terminal emulators.
Re:Show HN: ssh ssh.place by tyingq on Monday August 03, 2026 @09:51AM (#49155816)
Even newer ones. Iterm2 had CVE-2026-41253 recently. Or things like Tmux.
Re:Show HN: ssh ssh.place by LoganDark on Monday August 03, 2026 @11:20AM (#49156968)
Yes, I was thinking of iTerm2. "Older" means not the latest release and "buggy" includes well-intentioned vulnerabilities.
Re:Show HN: ssh ssh.place by tyingq on Monday August 03, 2026 @12:19PM (#49157825)
Sure. 3.6.9 (which was affected) was the most recent iTerm2 when that CVE came out.
Re:Show HN: ssh ssh.place by LoganDark on Monday August 03, 2026 @12:50PM (#49158270)
Hence "or"
Re:Show HN: ssh ssh.place by FooBarWidget on Monday August 03, 2026 @04:28AM (#49152832)
Malicious servers can send malicious terminal escape codes. For example https://www.sentinelone.com/vulnerability-database/cve-2026-...
Re:Show HN: ssh ssh.place by dinkelberg on Monday August 03, 2026 @07:05AM (#49154120)
Web browsers are generally built with security in mind. Terminal emulators surely much less so. The OpenSSH client probably sits somewhat in between, generally developed with security in mind, but not necessarily consistently expecting malicious servers.
Re:Show HN: ssh ssh.place by nativeit on Tuesday August 04, 2026 @01:51AM (#49164743)
At least for the more prominent terminal emulators i expect they probably devote a great deal of attention to security. They are developing the most commonly used interfaces for linking the most numerous, varied, and/or critical systems on the planet.
Re:Show HN: ssh ssh.place by dinkelberg on Tuesday August 04, 2026 @06:02AM (#49166402)
Went to the kitty website. No mentions of security.

Went to Alacritty. No mentions of security.

Went to Ghostty. No mentions of security, except for "secure keyboard entry".

None have a "security policy" on GitHub.

All written in memory unsafe languages (C, Zig).

Re:Show HN: ssh ssh.place by soblemprolver on Monday August 03, 2026 @08:06AM (#49154655)
I believe the recent cve-2026-55200 in libssh2 (client-side library) was allowing exactly this. https://nvd.nist.gov/vuln/detail/cve-2026-55200 ("Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution.")

Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.

Re:Show HN: ssh ssh.place by fulafel on Monday August 03, 2026 @09:49AM (#49155793)
OpenSSH doesn't use this library.
Re:Show HN: ssh ssh.place by soblemprolver on Monday August 03, 2026 @10:01AM (#49155928)
Good to know, but OpenSSH is not the scope here.
Re:Show HN: ssh ssh.place by fulafel on Tuesday August 04, 2026 @01:50AM (#49164740)
It seems to me you were replying to refute a claim about OpenSSH.
Re:Show HN: ssh ssh.place by applfanboysbgon on Monday August 03, 2026 @11:53AM (#49157436)
Per Red Hat:

> The integer overflow provides uncontrolled access to the heap, which reliably crashes the client process but is unlikely to achieve remote code execution in practice. Weaponizing the overflow for code execution would require a separate information disclosure vulnerability to defeat ASLR, along with a specific heap layout to place exploitable structures adjacent to the undersized allocation.

---

> abouts that you whatted

"Whataboutism" is perhaps the most infuriating and wildly misused word in the English language. Pointing out that somebody is scaremongering about an action that is significantly less dangerous than other everyday actions people take on their computers is not a fallacy. It is directly relevant to evaluating risk. Yes, technically there could be some critical bug that allows the posited thing to happen, but in reality it just doesn't happen. If it did happen, nobody would blow their once-in-decades exploit on pranking some people on a forum.