CVE-2026-32746 GNU telnetd Buffer Overflow PoC

CVE-2026-32746 GNU telnetd Buffer Overflow PoC Skip to content On this page Next tutorial 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 detect.py 127.0.0.1 2323 Copy The script connects, performs basic option negotiation, and checks whether the server accepts the LINEMODE option — a prerequisite for exploiting this vulnerability. If it reports that LINEMODE is accepted, the target is likely vulnerable. Running the Exploit PoC Warning: This exploit crashes the telnetd process. Only run it against your Docker lab or systems you own and have explicit written permission to test. Basic usage (sends 60 triplets by default — well past the overflow threshold of ~35): python3 exploit.py 127.0.0.1 2323 Copy Custom triplet count using the -n flag: # Send exactly 40 triplets (just past the overflow boundary) python3 exploit.py 127.0.0.1 2323 -n 40 # Send 80 triplets for a more aggressive overflow python3 exploit.py 127.0.0.1 2323 -n 80 Copy Adjust socket timeout for slow networks: python3 exploit.py 127.0.0.1 2323 -t 15 Copy Expected Output When the exploit successfully triggers the overflow, you should see output similar to this: ============================================================ CVE-2026-32746 - telnetd SLC Buffer Overflow PoC ============================================================ Target: 127.0.0.1:2323 Triplets: 60 (overflow at ~35) ============================================================ [+] Connected to 127.0.0.1:2323 [*] Phase 1: Reading server negotiation... Received XX bytes of negotiation Sent XX bytes (negotiation + WILL LINEMODE) [*] Phase 2: Waiting for LINEMODE activation... [+] Server accepted LINEMODE (DO LINEMODE received) [*] Phase 3: Sending malicious SLC suboption Payload size: XX bytes SLC triplets: 60 Buffer size: 104 bytes (usable) Data written: 180 bytes Overflow: 76 bytes past buffer end [+] Payload sent [*] Phase 4: Checking server state... [+] Connection error: [Errno 104] Connection reset by peer [+] Buffer overflow triggered - telnetd crashed! [+] VULNERABLE - CVE-2026-32746 confirmed The confirmation comes in Phase 4 — either a "Connection reset by peer" error or a socket timeout means telnetd crashed because end_slc() dereferenced the corrupted slcptr . Understanding the Exploit Code The PoC operates in four phases that map directly to the Telnet protocol exchange. Phase 1 — Negotiation. The script reads the server's initial DO / WILL option offers and accepts everything. It also proactively sends WILL LINEMODE to trigger the server's SLC handler, along with required suboption responses for terminal type ( xterm ) and speed ( 38400,38400 ) to prevent the server from stalling. Phase 2 — LINEMODE activation. The script waits for the server to reply with DO LINEMODE , confirming that LINEMODE negotiation is active and SLC processing is available. Phase 3 — Payload delivery. The script builds a malicious SLC suboption with the configured number of triplets (default 60). Each triplet uses a function code greater than NSLC (18), forcing the server to call add_slc() for a "not supported" reply — 3 bytes written per triplet. With 60 triplets, that's 180 bytes into a 104-byte buffer, overflowing by 76 bytes. Phase 4 — Crash detection. After a brief delay, the script tries to read from the socket. A connection reset or timeout confirms the daemon crashed from the corrupted slcptr dereference. PoC Files File Purpose exploit.py Crash/DoS proof-of-concept exploit detect.py Non-destructive LINEMODE vulnerability scanner Dockerfile Builds the vulnerable telnetd lab image docker-compose.yml One-command lab setup and teardown xinetd-telnet.conf xinetd service configuration for telnetd Going Further: From DoS to RCE This PoC only demonstrates a crash (denial of service). Developing a full remote code execution chain would require mapping the BSS layout to find the exact offset from slcbuf to slcptr , controlling the value end_slc() writes through the corrupted pointer, overwriting a GOT entry or function pointer to redirect execution, and building a ROP chain or shellcode payload. This is non-trivial but feasible — which is exactly why the vulnerability received a CVSS score of 9.8. Cleanup When you're finished testing, tear down the Docker lab: docker compose down Copy This stops and removes the container completely. Nothing persists on your host. Mitigation If you're running GNU InetUtils telnetd in production, you should take immediate action. The strongest mitigation is to disable the telnet service entirely and switch to SSH, which provides encrypted and authenticated remote access. If telnet is absolutely required, restrict access to trusted IP ranges using firewall rules and monitor the GNU InetUtils project for an official patch. References PoC Repository — jeffaf/cve-2026-32746 DREAM Security Advisory GNU bug-inetutils Disclosure NVD — CVE-2026-32746 Continue with Buffer Overflow Explained Quick Information 4 Critical Next up Buffer Overflow Explained Keep your momentum going with the next recommended tutorial. Open next tutorial Continue Learning Recommended next steps to keep building momentum. Buffer Overflow Explained What is it, how it works, examples. April 5, 2024 Free Mimikatz Use Tutorial How to use Mimikatz to perform various attacks on Windows. March 26, 2024 Free Bypassing Antivirus Software Learn techniques to bypass antivirus software and evade detection. May 31, 2024 pwn.guide+ Exploiting a new Linux LPE Critical Vulnerability How to exploit a new Linux LPE vulnerability with a PoC. November 27, 2024 pwn.guide+