One Command. Root Access. Almost 800,000 Servers Exposed.
CVE-2026-24061 is a wake-up call for anyone still running telnet. One command bypasses authentication completely. Almost 800,000 servers exposed globally. Exploitation started within 24 hours. If you have legacy systems that require telnet, here's how to keep access without the risk...
A bug hiding in plain sight for over 11 years just gave attackers the "keys to the kingdom".
Last week, I read an article entitled "Nearly 800,000 Telnet servers exposed to remote attacks" by Sergiu Gatlan on Bleeping Computer about the prevelent use of telnet an old protocol that is not secure due to its architecture.
Sergiu mentioned CVE-2026-24061 and shared a proof of concept demonstrating how a user could gain root access without using credentials, no passwords, no brute force attack, just by setting the USER environment variable to -f root and the user would be logged in as root.
USER=-f rootThis bug was known since 2015.
Almost 800k
Internet security watchdog Shadowserver tracked close to 800,000 IP addresses with exposed Telnet services worldwide:
- 380,000+ in Asia
- 170,000+ in South America
- 100,000+ in Europe
Within 24 hours of disclosure, attackers were already exploiting it in the wild. GreyNoise observed 18 unique attacker IPs targeting the root user in 83% of attempts.
"Why So Many Still Use Telnet?"
The use of telnet still persists because of the following:
- Legacy industrial/OT systems that "can't" be upgraded
- Embedded devices and IoT equipment
- Network appliances with ancient firmware
- That one server nobody wants to touch because "it works"
Many of these devices will never be patched. They'll remain vulnerable until they're physically decommissioned which could be years or decades.
How to Reduce the Risks
If you are in a situation where you must still use telnet here are some recommendations:
1. Never Expose Port 23 to the Internet
This should be obvious, but clearly it isn't for 800,000 administrators. Block it at your perimeter firewall. No exceptions.
2. SSH Tunneling
Wrap your telnet traffic in an encrypted SSH tunnel:
ssh -L 2323:legacy-device:23 user@servername
telnet localhost 2323The telnet session travels through encrypted SSH. Simple and effective.
3. VPN Segmentation
Isolate legacy devices on their own VLAN, accessible only through VPN:
- Require MFA for VPN access
- Firewall rules: deny all inbound to port 23 except from VPN subnet
- Log everything
4. Zero Trust Solutions
Modern tools like Tailscale, Cloudflare Access, or Teleport can wrap legacy protocols in identity verified, encrypted tunnels. No port exposure, no VPN client headaches.
This Reminds Me...
This reminds me of an article I shared where I mentioned using a customized script to easily and quickly deploy servers and harden them. Telnet is by default disabled. As the article points out this helps in situations where an Administator may miss few things for whatever reasons so automating critical areas can help reduce situations like these. You may read more about that article here I referenced the MOVEit vulnerability to explain this: https://www.masadaoffensive.com/the-moveit-vulnerability-and-why-automating-server-deployment-makes-sense/
What We can learn
This isn't really about telnet. It's about technical debt and the assumption that "old = safe because nobody's looking."
Attackers are absolutely looking. They're scanning for exactly these forgotten services. And when a trivial exploit like this drops, they move fast exploitation began within 24 hours of disclosure.
Your Checklist:
- Audit your network for exposed telnet (and other legacy protocols)
- If you find any: isolate, tunnel, or decommission
- Don't assume age equals obscurity
The attackers have scripts. They have Shodan. They have patience.
Do you have visibility into what's actually running on your network?
What legacy protocols have you found in environments you've audited? Maybe there is a forgotten old server that is still online on your network.
