TL;DR
Security researchers from Dream Security disclosed CVE-2026-32746 on March 11, 2026, a critical vulnerability affecting all versions of GNU InetUtils telnetd through 2.7. The flaw carries a CVSS score of 9.8 out of 10, enabling unauthenticated remote attackers to execute arbitrary code with root privileges. The vulnerability exists in the LINEMODE Set Local Ch3aracters suboption handler, where an out-of-bounds write triggers a buffer overflow during the initial connection handshake.
The critical distinction: This attack succeeds before the login prompt appears. No credentials are required. No authentication challenge must be passed. An attacker simply connects to port 23 and sends a specially crafted message during protocol negotiation. Because telnetd typically runs as root under inetd or xinetd, successful exploitation delivers complete system control.
The timeline: A patch is expected by April 1, 2026, creating a two-week window where organizations remain vulnerable. During this period, attackers will develop exploits, scan for vulnerable systems, and attempt mass compromise. External threat intelligence that detects when exploit code surfaces in underground markets provides the only early warning before attacks reach organizational networks.
A security audit discovered telnetd running on a legacy Linux server supporting an industrial control system. The system had operated for years without incident. Network documentation contained no reference to Telnet being enabled. The original system administrators had left the organization. No one remembered why the service was active.
The audit team flagged telnetd as a security concern due to its unencrypted nature and recommended migration to SSH. Before the recommendation could be implemented, CVE-2026-32746 was disclosed publicly. The team realized their exposure was far more severe than initially thought.
The vulnerability did not require attackers to crack passwords or bypass authentication. Simply connecting to port 23 and sending malformed data during the handshake would trigger the buffer overflow. The telnetd process ran as root. Successful exploitation would grant attackers complete control over the industrial control system.
The organization immediately disabled the service. But the discovery raised uncomfortable questions. How many other forgotten services ran on legacy systems? How many organizations remained unaware of their telnetd exposure? When exploit code for CVE-2026-32746 appeared on underground markets, would external threat intelligence provide warning before attackers arrived?
This scenario illustrates why pre-authentication vulnerabilities create existential risk. Understanding the technical details of CVE-2026-32746 and why it differs from typical security flaws has become critical for enterprise defenders.
The Technical Mechanics of Pre-Authentication Exploitation
CVE-2026-32746 demonstrates how vulnerabilities in protocol implementation can bypass every security control organizations deploy.
The Telnet protocol includes LINEMODE as an option for negotiating how data is processed between client and server. Within LINEMODE, the Set Local Characters suboption allows configuration of special characters like interrupt, quit, and erase.
The vulnerability exists in the add_slc function within GNU InetUtils telnetd. This function processes SLC suboptions during the initial connection handshake. The code fails to validate buffer boundaries when receiving triplet data. Triplets define character mappings and their flags.
An attacker sends a malformed SLC suboption containing an excessive number of triplets. The add_slc function writes this data beyond allocated buffer space. The out-of-bounds write corrupts adjacent memory. With careful manipulation, attackers transform memory corruption into arbitrary code execution.
The critical aspect is timing. This vulnerability triggers during option negotiation, which happens immediately after connection establishment and before any authentication occurs. The attack succeeds while the login prompt is still being prepared.
Most vulnerabilities require some level of access or authentication. SQL injection needs the ability to submit queries. Cross-site scripting requires user interaction. Even many buffer overflows assume the attacker has already authenticated.
CVE-2026-32746 requires nothing. The attack surface is completely exposed to anyone who can reach port 23. No valid credentials exist that need to be stolen. No phishing campaign is necessary to gain initial access. No social engineering prepares the target.
The attack sequence is brutally simple:
This simplicity makes mass exploitation inevitable once proof-of-concept code circulates. Automated scanning tools can test millions of IP addresses in hours. Every exposed telnetd instance becomes a potential victim.
The severity of CVE-2026-32746 stems not just from the pre-authentication access but from the privileges telnetd typically possesses.
The inetd and xinetd Architecture
Traditional Unix systems use inetd or xinetd as super-servers that listen on multiple network ports and spawn appropriate service daemons when connections arrive. When a client connects to port 23, inetd launches telnetd to handle the session.
The problem is that inetd runs as root. When it spawns telnetd, the daemon inherits root privileges. This design allows telnetd to later drop privileges after successful authentication and switch to the connecting user’s identity.
CVE-2026-32746 exploits the window between process creation and privilege dropping. The vulnerability triggers before telnetd has any opportunity to reduce its permissions. Successful exploitation occurs while the process still operates as root, granting attackers complete system control.
What Root Access Enables
Root privileges on Linux and Unix systems provide unrestricted capabilities:
Organizations cannot contain the damage from root-level compromise. Every security boundary disappears. Every protection can be disabled. Every secret can be extracted.
CVE-2026-32746 exposes a broader challenge organizations face: legacy protocols persist in modern environments despite security recommendations to eliminate them.
Why Telnet Still Exists
Security guidance has uniformly recommended SSH over Telnet for decades. Every compliance framework mandates encrypted protocols. Yet telnetd remains active across enterprise networks for several reasons.
Common scenarios where Telnet persists:
Organizations often lack comprehensive inventories of where these legacy protocols operate. Discovery happens only during security audits or after incidents occur.
Dream Security announced that a patch for CVE-2026-32746 is expected no later than April 1, 2026. Organizations face approximately two weeks of exposure between public disclosure and patch availability.
What Happens During the Patch Gap
The period between vulnerability disclosure and patch deployment creates predictable attacker activity:
Days 1-3: Security researchers analyze the vulnerability and develop proof-of-concept exploits for verification purposes. These PoCs begin circulating in security communities.
Days 4-7: Proof-of-concept code leaks to underground forums and dark web marketplaces. Attackers modify the code for operational use. Mass scanning for vulnerable systems begins.
Days 8-14: Automated exploitation tools integrate the vulnerability. Large-scale attack campaigns target exposed telnetd instances. Organizations with external threat intelligence receive early warning as exploit code surfaces.
Traditional security approaches provide limited defense during this window. Intrusion detection systems cannot distinguish malicious SLC suboptions from legitimate traffic. Endpoint protection focuses on post-exploitation activity rather than protocol-level attacks. The only early warning comes from monitoring where exploits are developed and shared.
Q1: How can organizations determine if they have exposed telnetd instances?
Scan internal networks for systems listening on TCP port 23. Check inetd and xinetd configurations for telnet service definitions. Query package managers for installed GNU InetUtils versions. Review firewall rules to identify whether port 23 is accessible externally. Many organizations discover forgotten telnetd instances only during comprehensive audits.
Q2: Can web application firewalls or intrusion prevention systems block this attack?
Traditional WAFs operate at HTTP/HTTPS layer and provide no protection for Telnet traffic. Network-based IPS can theoretically detect malformed SLC suboptions if signatures exist. However, the attack occurs during initial protocol negotiation, making reliable detection challenging. The most effective mitigation is disabling telnetd entirely or blocking port 23 at network perimeter.
Q3: What about IoT and embedded devices that cannot be easily patched?
IoT and embedded devices present the greatest challenge. Many run customized firmware where vendor patches arrive slowly or never. Network segmentation becomes critical. Place vulnerable devices on isolated VLANs with restricted access. Implement strict firewall rules blocking external access to port 23. Monitor for unusual outbound traffic indicating compromise. External threat intelligence provides early warning when specific device models become exploitation targets.
Q4: Is this vulnerability being actively exploited in the wild?
As of March 19, 2026, no confirmed exploitation has been publicly reported. However, technical details have circulated widely since disclosure on March 11. The vulnerability’s simplicity and severity make exploitation inevitable. Organizations should assume active exploitation attempts are occurring or imminent, particularly given that a similar vulnerability (CVE-2026-24061) is confirmed under active attack.
Q5: How does this relate to the previous telnetd vulnerability CVE-2026-24061?
CVE-2026-24061 was disclosed in January 2026 with the same CVSS 9.8 score and is confirmed under active exploitation by CISA. Both vulnerabilities affect GNU InetUtils telnetd and enable unauthenticated root access. The pattern suggests telnetd contains multiple critical flaws that attackers are systematically exploiting. Organizations still running telnetd face compounding risk from multiple severe vulnerabilities.
You may also find this insight helpful: NIST CSF 2.0: Why Governance Now Requires Dark Web Monitoring