Three Decades for a 3-Line Fix: The Critical telnetd Bug Hiding in Plain Sight (CVE-2026-32746)
Overview
The SonicWall Capture Labs threat research team became aware of an out-of-bounds write vulnerability in the Telnet server shipped with GNU Inetutils, assessed its impact and developed mitigation measures. Telnetd hardly needs an introduction. It is one of the oldest and most widely distributed network utilities on Linux systems.
The issue, tracked as CVE-2026-32746, affects all telnetd versions up to 2.7. This vulnerability, classified as a classic buffer overflow (CWE-120), allows an unauthenticated remote attacker to crash the server and potentially execute arbitrary commands. It carries a critical CVSS score of 9.8. Contrary to popular belief that Telnet is dead, it remains hidden within the vital infrastructure that runs the world. Hence, users are strongly encouraged to apply the vendor-provided patch or restrict/disable the telnet access without delay.
Technical Overview
Telnet is a legacy protocol that operates on port 23 and provides a command-line interface to remote systems such as servers, routers, and embedded devices. While it may seem outdated, Telnet is still widely used in legacy environments, including industrial control systems, networking equipment, and IoT devices.
When a client connects to a Telnet server, the session does not immediately proceed to authentication. Instead, the client and server first perform a negotiation phase known as option negotiation. One of the key options involved is LINEMODE, which controls how keyboard input is handled.
Within LINEMODE, there is a sub-feature called SLC (Set Local Characters). This mechanism allows both sides to agree on special control characters such as interrupt, erase, or end-of-file. SLC data is exchanged as a suboption consisting of a sequence of triplets, each containing three bytes: [function_code, flags, value].
The Telnet standard (RFC 1184) defines 30 SLC function codes, covering various operations such as interrupt handling, cursor movement, and editing behavior. However, GNU Inetutils only supports the first 18 functions(legacy/standard functions defined in RFC 1116) and sets NSLC = 18. Function codes beyond this range (19-30, aka cursor motion characters) are treated as unsupported and anything above 30 is undefined entirely.
Root Cause
The vulnerability is located in the add_slc() function within the telnetd/slc.c source file. Its job is to take a triplet (function, flags, value) and append it to a response buffer called slcbuf.
As shown in Figure 1, the buffer is 108 bytes in total. The first 4 bytes are reserved for protocol headers, leaving 104 bytes for actual data. It is vital to bear in mind that each triplet can expand beyond its original size due to IAC byte doubling. In the Telnet protocol, the byte 0xFF is special and means “Interpret As Command - IAC”. If it appears in data, it must be escaped by doubling it, as seen in Figure 2. As a result, a 3-byte triplet can expand to as much as 6 bytes.
The problem lies in the fact that add_slc() does not verify whether the write pointer slcptr remains within the bounds of slcbuf. As shown in Figure 2, there is no boundary check before writing data into the buffer.
Triggering the Vulnerability
When the server receives a triplet with a function code greater than 18, the process_slc() function generates a “not supported” response, as illustrated in Figure 3. There is no limit on how many such responses can be queued.
The client can send up to approximately 170 triplets in a single request, since the suboption buffer is 512 bytes (512 / 3 ≈ 170). Each "not supported" response consumes at least 3 bytes and may consume up to 6 bytes when byte doubling occurs.
Hence, mathematically after roughly 35 unsupported triplets with func > 18, the 104-byte buffer is exhausted. Any additional writes result in overflow into adjacent memory. Since slcbuf is a global variable stored in the BSS segment, this overflow corrupts nearby variables, including slcptr itself. This creates a classic out-of-bounds write condition that can potentially be leveraged for remote code execution.
The Fix: 3 Lines That Save the World
The patch is remarkably elegant, as seen in Figure 4. Where,
slcbuf + sizeof slcbuf = end of the buffer (byte 108)
slcptr + 6 = worst-case position after this write
Before writing data, the code checks whether there is enough space in the buffer for the worst-case scenario: 6-byte write after IAC doubling. If the write would exceed the buffer boundary, the function safely exits and drops the triplet.
Why is dropping safe?
SLC negotiation is a best effort. The server isn't required to respond to every function code. Dropping a "not supported" reply for some obscure unsupported function code has zero practical impact. The supported 18 SLC functions always fit within the buffer.
Exploitation
Successful exploitation allows a remote, unauthenticated attacker to crash the telnetd service and potentially execute arbitrary code, at least in theory. An example attack flow is shown in Figure 5, demonstrating how repeated malformed SLC triplets trigger the overflow.
Additionally, a publicly available detection script can also be used to identify vulnerable systems, as shown in Figure 6.
Figure 6 Detecting Vulnerable Instance
SonicWall Protections
To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:
- IPS: 22059 GNU Inetutils telnetd LINEMODE SLC Out-of-Bounds Write
Remediation Recommendations
Considering the fact that telnetd is still widely used even in this modern world of SSH and TLS, users must consider the following workarounds until the patch is deployed.
- Disable telnetd if it is not strictly required and replace it with SSH.
- Deploy IPS signature #22059 to detect and block exploitation attempts.
- Block port 23 at both the network perimeter and host firewall if Telnet usage is not anticipated.
Relevant Links
Share This Article
An Article By
An Article By
Security News
Security News
