CVE-2026-32746 is a critical pre-authentication buffer overflow vulnerability in GNU InetUtils telnetd , affecting all versions through 2.7. The vulnerability exists in the LINEMODE SLC (Set Local Characters) handler, where the add_slc() function in telnetd/slc.c writes 3 bytes per SLC triplet into a fixed 108-byte buffer without any bounds checking. An unauthenticated attacker can send a crafted SLC suboption with 40+ triplets during option negotiation — before any login prompt — to overflow the buffer, corrupt the slcptr pointer in BSS, and trigger an arbitrary write when end_slc() uses the corrupted pointer. Affected Versions The following versions of GNU InetUtils telnetd are vulnerable: GNU InetUtils telnetd through 2.7 (all versions) Any telnetd implementation derived from the BSD SLC codebase Vulnerability Details Detail Value CVE ID CVE-2026-32746 CVSS 3.1 9.8 (Critical) CWE CWE-120 (Buffer Overflow), CWE-787 (Out-of-Bounds Write) Type Pre-authentication Remote Code Execution Vector Network (no authentication required) Discovered by DREAM Security Research Team How the Vulnerability Works To understand this bug, you first need to know a bit about how the Telnet protocol negotiates features. When a client and server agree to use LINEMODE, the server sends SLC triplets — small 3-byte messages that define how special characters like interrupt, erase, and kill should be handled. The server queues its SLC replies in a static buffer called slcbuf . The core issue is that add_slc() never validates whether slcbuf has enough room before writing into it. The buffer is 108 bytes total, and the suboption header takes 4 bytes, leaving 104 usable bytes. Each reply triplet consumes 3 bytes, so the buffer can safely hold about 34 triplets (104 ÷ 3 ≈ 34). Starting at triplet 35, every subsequent write lands outside the buffer. What makes this especially dangerous is the behavior for unrecognized function codes. GNU InetUtils defines 18 valid SLC function codes (the constant NSLC = 18 ). When the server receives a triplet with a function code above 18, it doesn't recognize it — but it still calls add_slc() to queue a "not supported" reply. An attacker simply sends dozens of high function codes, and the server faithfully tries to respond to every one, writing further and further past the end of the buffer with each triplet. Because both slcbuf and the slcptr write-position pointer live in the BSS segment, the overflow corrupts slcptr itself. When end_slc() later writes the suboption end marker through this now-corrupted pointer, it performs an arbitrary write to an attacker-influenced memory address. This crashes telnetd at minimum, and with careful control of the overflow data, could redirect execution entirely. The entire attack happens during option negotiation, which means the attacker never needs to authenticate. No username, no password — just a raw TCP connection. The Attack Flow The exploitation follows a clear sequence. The attacker connects to telnetd , receives the server's initial option negotiation offers, and accepts them all. The attacker then proactively sends WILL LINEMODE to trigger the server's LINEMODE handler. The server responds with DO LINEMODE and begins SLC suboption processing. At this point, the attacker sends a crafted SLC suboption containing 40–60 triplets with function codes above 18. Each triplet forces add_slc() to write 3 bytes, and after about 35 triplets, the 104-byte buffer overflows. The corrupted slcptr is then used by end_slc() , causing either a crash or an arbitrary write depending on the overflow content. Prerequisites Before following this tutorial, make sure you have the following installed on your machine: Docker and Docker Compose — used to build an isolated vulnerable lab environment Python 3 — needed to run both the detection script and the exploit PoC A basic understanding of the Telnet protocol and binary exploitation concepts Setting Up the Lab Environment The PoC repository provides a complete Docker-based lab running a vulnerable version of inetutils-telnetd (version 2.4) inside a Debian container, managed by xinetd and exposed on port 2323. Everything stays isolated from your host. Clone the repository: git clone https://github.com/jeffaf/cve-2026-32746.git cd cve-2026-32746 Copy Build and start the vulnerable container: docker compose up -d Copy This builds the Docker image with inetutils-telnetd and xinetd installed, configures the telnet service using the included xinetd-telnet.conf , and exposes it on localhost:2323 . Verify it's running with: docker compose ps Copy Test connectivity before exploiting: telnet 127.0.0.1 2323 Copy You should see a login prompt. Press Ctrl+] and type quit to disconnect. Running the Detection Script The repository includes detect.py , a non-destructive scanner that checks if a target is running a vulnerable telnetd without crashing it. This is ideal for safely identifying vulnerable hosts during authorized assessments. python3 det...