Glonce

CVE-2026-32746 exposes a 32-year-old pre-auth bug in GNU Telnetd

securityThe Glonce editorsHacker News🔥46Glonce rating46Impact60Novelty45Relevance70Surprise50Players15Credibility80
CVE-2026-32746 exposes a 32-year-old pre-auth bug in GNU Telnetd

watchtowr Labs published a detailed technical analysis of CVE-2026-32746, a pre-authentication buffer overflow in GNU inetutils Telnetd that the company says has existed in the code since 1994. The bug was discovered by the DREAM Security Research Team and was recently patched; watchtowr says it wrote up the analysis because almost a week had passed after disclosure with no public deep dive of the issue. The flaw sits in the LINEMODE SLC (Set Linemode Characters) negotiation handler of the Telnet protocol. During connection setup, a Telnet server and client negotiate optional features such as LINEMODE using in-band signaling built around the IAC ('Interpret As Command') byte, 0xFF. Once LINEMODE is enabled, the server sends the client a list of three-byte triplets, each describing a special character (such as backspace), its support level, and its value; the client can reply with its own triplets to override them. watchtowr found that the server stores every incoming triplet into a fixed-size global array without any bounds checking, which is the root cause: an attacker who sends enough triplets can corrupt roughly 400 bytes of adjacent variables in memory. Because the vulnerable code originated in GNU inetutils, and many Telnetd implementations were forked from or based on that same codebase over the years, watchtowr says the blast radius is large and hard to fully map; it states it confirmed the bug is present in all major Linux distributions it checked, and lists it as identified in at least inetutils-telnetd itself, Ubuntu, Debian, FreeBSD 13, the FreeBSD 15 port, NetBSD 10.1, Citrix NetScaler, Apple Mac Tahoe, Haiku, TrueNAS Core, uCLinux, libmtev, and DragonFlyBSD. watchtowr also points out a near-identical historical twin: CVE-2005-0469, discovered in 2005, was the same kind of missing bounds check, but in the Telnet client's slc_add_reply function rather than the server, and it took two decades for anyone to check the server-side code for the equivalent flaw; the fix applied for CVE-2026-32746 is described as an identical bounds-check patch to the one used in 2005. The available text goes on to walk through how much control an attacker actually has over the corrupted bytes: the triplet's function byte is discarded by the server's process_slc routine if it exceeds the NSLC constant (0x1e) or equals zero, and a further routine, change_slc, mutates the flag and value bytes based on the server's own declared capabilities before they are stored; any 0xFF byte in a triplet also gets doubled to 0xFF 0xFF, which can expand a three-byte triplet to four, five, or even six bytes on the wire. The provided text cuts off mid-sentence in the middle of this exploitation walkthrough, so the piece's final conclusions about how far an attacker can push the overflow, and whether a working proof of concept exists, are not covered here.

Key facts

  • CVE-2026-32746 is a pre-authentication buffer overflow in the LINEMODE SLC negotiation handler of GNU inetutils Telnetd, present in the code since 1994.
  • The DREAM Security Research Team discovered the bug; watchtowr Labs published its own technical analysis after almost a week passed with no public deep dive.
  • The flaw lets an attacker corrupt roughly 400 bytes of adjacent BSS memory by sending unchecked SLC triplets; watchtowr says it confirmed the bug in all major Linux distributions it checked, plus specific products including Ubuntu, Debian, FreeBSD, NetBSD, Citrix NetScaler, Apple Mac Tahoe, Haiku, TrueNAS Core, uCLinux, libmtev, and DragonFlyBSD.
  • It mirrors CVE-2005-0469, a nearly identical missing-bounds-check bug found in 2005 in the Telnet client's slc_add_reply function, fixed with the same kind of patch used here.
  • Exploitability is constrained by protocol-level filtering: the server's process_slc and change_slc routines discard or mutate triplet bytes, and any 0xFF byte gets doubled, before the data reaches the vulnerable buffer, limiting how precisely an attacker can control the corruption.

Why it matters

A bug that has sat unnoticed in widely forked, decades-old network code since 1994 illustrates how legacy protocol implementations propagate silently across an entire ecosystem. Because so many Telnetd variants trace back to the same GNU inetutils code, one buffer overflow in a single negotiation handler ended up embedded in Linux distributions, multiple BSDs, a commercial network appliance, and even Apple's and Haiku's operating systems, without anyone having checked the server side for two decades despite an identical client-side bug being fixed back in 2005.

Who it affects

Anyone still running a Telnetd built on or derived from GNU inetutils. watchtowr's own list of confirmed-affected systems includes inetutils-telnetd itself, Ubuntu, Debian, FreeBSD 13, the FreeBSD 15 port, NetBSD 10.1, Citrix NetScaler, Apple Mac Tahoe, Haiku, TrueNAS Core, uCLinux, libmtev, and DragonFlyBSD. Telnet is largely obsolete for interactive login and has mostly been replaced by SSH, but the protocol persists on production systems for reasons ranging from vendor-only support on constrained hardware to environments where migrating away simply has not happened.

How to use it

The fix is a bounds-check patch already applied upstream to inetutils-telnetd, mirroring the fix used for the client-side CVE-2005-0469 twenty years earlier. Operators of any of the affected systems need that patch to reach them through their own distribution or vendor, since each fork carries the vulnerable code independently. Where Telnet access cannot be removed outright, restricting network exposure to the Telnetd service is the practical mitigation the writeup's own framing points toward.

How solid is it

This is a first-party technical writeup from watchtowr Labs, the same team that traced the root cause down to specific lines in process_slc and change_slc and cross-checked the bug against major Linux distributions itself. The historical parallel to CVE-2005-0469, fixed with an equivalent patch, adds independent corroboration that this class of bug is real and previously exploitable on the client side. That said, the text available here is cut off mid-sentence during the exploitation walkthrough, so the article's own final assessment of how far the overflow can be pushed, and whether a working proof of concept was built, is not captured in what could be reviewed.

Risks and caveats

watchtowr is explicit that exploitation is not straightforward: the SLC triplet's function byte is discarded outright if it exceeds the NSLC constant (0x1e) or is zero, and the flag and value bytes are further modified by the server's change_slc routine based on its own declared capabilities before anything reaches the vulnerable global array. Any 0xFF byte in a triplet also gets doubled on the wire, which can stretch a three-byte triplet to four, five, or even six bytes and affects how much of the roughly 400 bytes of adjacent memory an attacker can actually shape. The piece does not cite a numeric CVSS score, joking instead about 'a CVSS three squillion,' and it does not state that the bug has been exploited in the wild; it reads as a vulnerability research writeup, not an incident report.

“While in Linemode with editing enabled for the local side, network traffic is reduced to a couple of packets per command line, rather than a couple of packets per character typed.”

— RFC 1184