A 32-year-old bug walks into a Telnet server
labs.watchtowr.com
labs.watchtowr.com
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
But this is probably forgiven as just sensationalism in writing, which is all too common. Not to excuse the author, but these types of writeups tend to drift into name calling and finger pointing a little too soon.
"Shamefully" is definitely the wrong word here, for sure.
Why should we forgive sensationalism in writing at all?
Thanks to all of our heroes, op included.
We know that the entirety of the AI movement is built on top of open-source projects like Linux and all the terminal and command line utilities. And runs inside projects doing god's work (say to contain the agents) like QEMU etc.
AI lives inside the work of our open-source heroes and would be absolutely nowhere without the work of all those people.
> Thanks to all of our heroes, op included.
Definitely, thanks GP and thanks to all our heroes.
i have not seen a decent writeup in one of these clickbait things these ppl push out.
just ignore these types of ppl. its fine to fix the bugs ofc but what i mean is, ignore their attitudes. its a kids' attitude to life they keep
The bug was reported on a public mailing list, which is sadly common nowadays
In defence of the reporter, your Readme only says "Send bug reports to bug-inetutils@gnu.org.", there is no distinction for vulnerabilities. [1]There is a 3 months old pull request to advertise a private reporting email address but it's unmerged, maybe you could use this renewed interest as a nudge to set it up and merge: https://codeberg.org/inetutils/inetutils/pulls/26
One other thing the reporter could have done to make your life easier is to write a repro script rather than just explain the steps in prose.
[1]: https://codeberg.org/inetutils/inetutils/src/commit/40f19d84...
And then all governments and corporations demand immediate support as if they have paid Tier 3 SLA with the unpaid maintainers lol.
> 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.
Ahem
Clunky from the author, I think.
"Tell that to the ARM based Acorn Archimedes I was using at 6th Form College in 1991."
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.
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.
... if you hold it just right, and let the light of the full moon shine through it on a particular day, while you send a carefully-crafted packet through the right brand of NIC over cables forged by long-forgotten smiths.
The bug, being a bug, proceeds to overflow the buffer
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?
However, from my point of view most targets are able to be compromised by poor configs, hygiene, well known and patchable vulns, or the more likely avenue: the humans operating the system.
Of course if you count the 6502 as a RISC chip (if you squint a bit, Page Zero RAM sure does look like 256 8-bit registers to me!) then UK schools had RISC desktops for over a decade before then!
/s