As the person who wrote the fix for this issue (and not the original code), I will just mention that I find this paragraph makes the author sound incredibly entitled:

    Shamefully, the inetutils project hasn’t actually released a fixed version of their software (at least at the time of publishing).

The bug was reported on a public mailing list, which is sadly common nowadays [1]. After my workday, during which I was not able to review the report, I wrote a script to confirm the bug was real, since I was seeing way too many slop reports at the time. Then I sent a patch before going to bed [2]. A third party then graciously shared the patch on oss-security [3], which all distributions follow. There is no need to make a new release, which is harder for the distributions than simply applying a small patch.

Perhaps I am just unlucky in my interactions, but I feel like this entitlement is too common among software security people. Note that I see zero return in spending time working on Inetutils, and I find other projects I work on more interesting.

[1] https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg... [2] https://lists.gnu.org/archive/html/bug-inetutils/2026-03/msg... [3] https://www.openwall.com/lists/oss-security/2026/03/12/4

> In fact, this vulnerability was born so long ago (way back in 1994)

> That was so long ago that RISC was still a distant dream.

Yeah ARM would like to have a word with you. I'd been using RISC on the desktop for about five years by then and I was not an early adopter.

Wow, how did this not get discovered and fixed at the time of:

https://www.cve.org/CVERecord?id=CVE-2007-0882

Might be a 32 year old bug, but it's practically also a 19 years old exploit?

Ed: I'm confusing TFA with

https://nvd.nist.gov/vuln/detail/cve-2026-24061

Which seems pretty much identical with the 2007 cve.

> "1994" > "RISC was a distant dream"

Ahem

Needs a (March 19) (I know HN only does this for years, but this being about vulnerabilities…)

A lot of people have already made almost all of the same observations that I was going to make.

Except for: There is no bug that originates in a GNU version of an old networking program and magically makes its way into the NetBSD, FreeBSD, DragonFlyBSD, and OpenBSD (Yes; I checked.) versions of that program.

History simply didn't happen that way.

This bug goes as far back at least as far as the Jolitz-released 386BSD source for libexec/telnetd , where it can be found and which is credited in the GNU versions of the file. GNU just took the 386BSD code. But BSD had a telnetd before 386BSD. In BSD, telnetd itself goes back to 1983. Although its code to do line mode did not pre-date RFC 1116, which was published in August 1989.

The code to do line mode was written the month after that RFC, by Paul Borman, and the bug is in the very first version of that code:

* https://github.com/dspinellis/unix-history-repo/blob/dc8d504...

This bug is not 32 years old.

I really dislike articles that blow out of proportion the technical details. TLDR; bounds checking was missing leading to potential memory corruption.

The server asks the bug "Why the long face?".

The bug, being a bug, proceeds to overflow the buffer

If you're going to rip off xkcd pictures, I feel it'd be polite at least credit and/or link the original.

Something tells me the NSA is none too pleased about the advent of LLMs.

Or is there a tradeoff?

Fewer ancient holes like this for their hackers but wide open access to anyone who installs codex or claude code?

FYI all signalling is in-band signalling

undefined

RISC was not a distant dream in 1994 LMAO.

A surprisingly long article for a one-line fix the authors didn’t send.

CVE-2026-32746

undefined

And this is why serious enterprises use telnetd exclusively instead of your childish ssh toy. See why? Because it's got ONE CVE in 3 decades as compared to a never-ending flow of security vulnerabilities in ssh. Security!

/s