A vulnerability buried in code that predates most of today’s working software engineers has resurfaced with devastating implications. CVE-2026-32746, a critical buffer overflow flaw in the BSD-derived telnetd daemon, carries a CVSS score of 9.8 and affects a startling range of Linux distributions still shipping the ancient remote-access service. The bug isn’t theoretical. It’s actively exploitable, requires no authentication, and hands attackers root-level access to compromised machines.
The flaw exists in inetutils-telnetd, the GNU implementation of the telnet server daemon that traces its lineage back to BSD networking code written in the early 1990s. According to The Hacker News, the vulnerability stems from improper bounds checking in the daemon’s handling of environment variable options during the initial Telnet negotiation phase. Specifically, when a client sends a specially crafted NEW-ENVIRON or ENV subnegotiation payload with an oversized variable name or value, the daemon copies the data into a fixed-size stack buffer without verifying length. The result is a classic stack-based buffer overflow — the kind of vulnerability that computer science professors have been warning about since the Clinton administration.
And yet, here we are.
The affected package ships by default or is readily available in Debian, Ubuntu, Fedora, RHEL-derived distributions, SUSE, and Arch Linux. While telnet as a protocol has been widely deprecated in favor of SSH for interactive remote administration, telnetd persists in environments where legacy applications, embedded systems, or specific compliance configurations demand it. Industrial control systems, older network equipment management planes, university computing labs, and certain government networks still run telnet services — sometimes knowingly, sometimes not.
The mechanics of exploitation are alarmingly straightforward. An attacker connects to port 23, initiates the standard Telnet option negotiation, and injects a malformed environment variable subnegotiation sequence. No username. No password. No prior access of any kind. The overflow overwrites the return address on the stack, redirecting execution to attacker-controlled shellcode or a ROP chain. Because telnetd typically runs as root — it needs elevated privileges to spawn login sessions and allocate pseudo-terminals — successful exploitation yields immediate root access.
Security researcher Jeffrey Bencteux, who discovered and reported the vulnerability, published a proof-of-concept demonstrating reliable remote code execution against default configurations of inetutils-telnetd version 1.9.4, the version shipped in Debian 11 (Bullseye) and Ubuntu 22.04 LTS. The PoC bypasses ASLR on 32-bit builds and works against 64-bit systems where the daemon was compiled without stack canaries — a configuration that turns out to be more common than anyone would like to admit.
Why Ancient Code Still Draws Blood
The deeper story here isn’t just one vulnerability. It’s the persistence of software that should have been retired years ago.
Telnet transmits everything — credentials included — in plaintext. The protocol offers zero encryption, zero integrity verification, and zero modern authentication mechanisms. SSH replaced it for good reason, and most security hardening guides have recommended disabling telnet since at least the early 2000s. But recommendations and reality diverge. The inetutils package, maintained by the GNU Project, bundles telnetd alongside other classic Unix networking utilities like ftp, rlogin, and talk. Distribution maintainers continue to package it. System administrators continue to install it. And the codebase, largely untouched for decades, has received minimal modern security auditing.
This isn’t the first time legacy Unix networking daemons have produced critical vulnerabilities. In 2020, a heap overflow in telnetd on FreeBSD (CVE-2020-7458) allowed similar unauthenticated remote code execution. The pattern repeats because the underlying code was written in an era when buffer safety was an afterthought and network inputs were implicitly trusted. Functions like strcpy, sprintf, and manual pointer arithmetic litter the telnetd source. The code was never designed to withstand adversarial input from a modern threat actor armed with automated fuzzing tools.
Bencteux reportedly discovered CVE-2026-32746 using a combination of manual source code review and targeted fuzzing of the Telnet option negotiation state machine. The vulnerable code path had been present, unmodified, for over 25 years.
Patches are now available from major distribution maintainers. Debian released an updated inetutils-telnetd package for Bullseye and Bookworm within 48 hours of the coordinated disclosure. Ubuntu followed with patches for 22.04 LTS and 24.04 LTS. Red Hat issued an advisory noting that telnetd is not installed by default on RHEL 8 or 9, but recommended immediate patching for systems where it had been manually enabled. SUSE and Arch Linux have also pushed updates.
But patching alone doesn’t address the root cause. Security teams should be asking a harder question: why is this service running at all?
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has long recommended disabling telnet across all federal networks, a position reinforced in its Binding Operational Directives. The National Institute of Standards and Technology’s SP 800-123 guide on server security explicitly calls out telnet as a protocol that should be replaced wherever possible. And yet exposure data tells a different story. Shodan queries consistently show tens of thousands of telnet services reachable on the public internet, many running on Linux hosts.
The vulnerability arrives at a moment when the software supply chain is under intense scrutiny. The XZ Utils backdoor incident in 2024 highlighted how thinly maintained open-source infrastructure packages can become vectors for compromise. inetutils fits the same profile: critical network infrastructure code maintained by a small group of volunteers, rarely audited, and carried forward by distributions out of inertia more than necessity. The GNU Project’s inetutils repository on Savannah shows sporadic commit activity, with long gaps between releases.
So what should organizations do right now?
First, the obvious: patch immediately if inetutils-telnetd is installed. Second, audit systems for the presence of telnet services, including those that may have been enabled temporarily and forgotten. Third — and most important — disable and remove telnetd unless there is a documented, justified business requirement with compensating controls in place. If telnet must remain, it should be restricted to isolated network segments with strict firewall rules, monitored for anomalous connection patterns, and wrapped in a VPN or other encrypted transport.
For organizations running industrial control systems or embedded devices where telnet is baked into firmware, the calculus is more complicated. These environments often can’t be patched quickly or easily, and the devices may not receive vendor updates at all. Network segmentation and intrusion detection become the primary defenses. Monitoring for the specific malformed NEW-ENVIRON subnegotiation patterns associated with CVE-2026-32746 exploitation is possible and should be implemented in IDS/IPS rulesets. Snort and Suricata signatures for the vulnerability are expected from the open-source community shortly, if not already available.
There’s a broader lesson. Legacy code doesn’t become safe simply because it’s old and familiar. The opposite is often true. Code written before modern compiler protections, before widespread adoption of memory-safe languages, before threat modeling was standard practice — that code carries risk that compounds over time. Every year it remains in production without audit is another year an attacker might find what the original developers never imagined anyone would look for.
CVE-2026-32746 is a 9.8-severity reminder. Telnet should have been dead long ago. The fact that it can still hand over root access to an anonymous attacker, in 2026, on current Linux distributions, is an indictment of how the industry manages technical debt. The vulnerability is fixed. The question is whether the conditions that created it will be.
WebProNews is an iEntry Publication