For example, openssh has both a client and server. There’s been vulnerabilities in openssh, in the client. Those vulnerabilities aren’t reachable unless you’re connecting to a server attempting to exploit you, so the risk is quite low because you know and trust most servers you’re connecting to with ssh.
To sum it up: Connecting to this server is probably fine, but in doing so most people are doing something significantly riskier without realizing it.
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).
Of course the other abouts that you whatted (such as random curl install scripts, binaries, etc.) are still more dangerous.
> 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.
has there ever been an example of such a vulnerability in openssh?
And what are you basing this statement on?
https://www.cve.org/CVERecord?id=CVE-2026-60002
As I understood this, a malicious server can change its host key somewhere during key exchange and trigger a use-after-free in the client, which might be exploitable for code execution.