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?
I really dislike articles that blow out of proportion the technical details. TLDR; bounds checking was missing leading to potential memory corruption.
Needs a (March 19) (I know HN only does this for years, but this being about vulnerabilities…)
> 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.
FYI all signalling is in-band signalling
A surprisingly long article for a one-line fix the authors didn’t send.
If you're going to rip off xkcd pictures, I feel it'd be polite at least credit and/or link the original.
RISC was not a distant dream in 1994 LMAO.
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:
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