Back

Threat Actors Are Mass-Scanning for Telnet Auth Bypass - Here's What We Found

What happened?

While hunting exposed infrastructure, we caught a threat actor running internet-wide telnet exploitation at scale. Here's what we observed about their methodology, how they're doing it, and what you need to check.


The Hunt

On June 23, 2026, we discovered an open directory listing on a server hosted on Corbina Telecom IP address space (AS8402 - PJSC Vimpelcom/Beeline).

The following screenshot shows the exposed directory listing - a Linux home directory served over HTTP on port 8080:


The directory contained 35 files - bash history and SSH keys that told us exactly what a threat actor was doing in real time.


The operator was running masscan against the entire internet at 80,000 packets per second, filtering for port 23 (telnet), then automatically attempting to log in as root using an authentication bypass technique that exploits a vulnerability present in many telnet implementations - CVE-2026-24061.


The Vulnerability


CVE-2026-24061 is a critical authentication bypass (CVSS 9.8) in GNU Inetutils telnetd, affecting versions 1.9.3 through 2.7. The flaw sat undetected in the upstream codebase for approximately 11 years (since ~2015) before being discovered in January 2026.


How it works:

During the telnet handshake, the client can send environment variables via the NEW_ENVIRON telnet option. The vulnerable telnetd passes these directly to the system `login` binary without sanitization.

USER="-f root" telnet -a <target> 23


The `-f` flag tells `login` to skip authentication for an already-authenticated user. The telnetd dutifully passes this to login, which grants immediate root shell access - no password required.


This is argument injection at its most trivial. The telnet daemon trusts client-supplied environment variables and passes them as command-line arguments to a privileged binary.


  • Affected versions: GNU Inetutils telnetd 1.9.3-2.7 
  • CVSS: 9.8 (Critical) 
  • Authentication: None required 
  • Impact: Instant root shell


The Operator's Workflow

The exposed bash history revealed an observed exploitation workflow:


Phase 1: Reconnaissance

The following screenshot shows the operator's bash history with kernel tuning and masscan configuration:


The operator's bash history reveals a methodical setup process:

apt install masscan
sysctl -w net.core.somaxconn=65535
sysctl -w net.core.netdev_max_backlog=250000
# ... kernel tuning for high-speed scanning ...

masscan -p23 0.0.0.0/0 \
 --banners \
 --open \
 --rate=80000 \
 --source-ip 192.168.100.1 \
 --excludefile exclude.txt \
 --wait 3 \
 -oG telnet_live_grepable.txt \
 -oJ telnet_live.json


The operator tuned kernel parameters (`somaxconn`, `rmem_max`, `wmem_max`) to handle the throughput, then scanned the entire IPv4 space for telnet at 80,000 packets per second. The `exclude.txt` file filtered out RFC1918 and CGNAT ranges.


Phase 2: Exploitation


The following screenshot shows bash history entries revealing exploitation attempts across multiple IP ranges:


After identifying vulnerable telnet instances, the operator began testing the CVE-2026-24061 authentication bypass against targets across multiple countries. The bash history shows 24 exploitation attempts targeting at least 12 unique IPs across 7 countries.


Affected Countries:

  • 🇨🇳 China (4 IPs) - China Unicom
  • 🇪🇸 Spain (3 IPs) - Telefónica, Cogent Communications
  • 🇨🇦 Canada (1 IP) - Bell Canada
  • 🇩🇪 Germany (1 IP) - Hetzner Online
  • 🇮🇩 Indonesia (1 IP) - Amazon AWS
  • 🇭🇰 Hong Kong (1 IP) - HGC Global Communications
  • 🇨🇭 Switzerland (1 IP) - Amazon AWS

Additional attempts targeted other systems (IPs redacted to protect victims). The targets spanned residential ISPs, cloud providers, and hosting companies across multiple continents. Each command used the CVE-2026-24061 bypass in an attempt to gain root access.


Note: Bash history only shows commands that were executed, not their output. We cannot confirm whether these attempts succeeded. The operator may have been testing the exploit, but we have no visibility into whether they actually gained root access to these systems.


Operational Security Failure

The open directory also contained the operator's SSH private key (`id_rsa`). This means anyone with access to the directory listing could potentially use that key to authenticate to the SSH server the operator was using for their attacks.


The server itself appears to be a compromised system that the threat actor is using as an attack platform. The exposed directory, combined with the scanning infrastructure and SSH keys, suggests this is not the operator's own infrastructure but rather a hijacked system being used to launch attacks against other targets.

Exposing a private key is a critical operational security failure. It not only reveals the operator's infrastructure but also creates an opportunity for others to hijack their attack platform or pivot to other systems the operator may have accessed.


The Scale

According to Shadowserver data published in January 2026, there are approximately 800,000 telnet instances exposed globally. Not all run the vulnerable GNU Inetutils telnetd, but a significant portion do.


The operator we observed wasn't the first to target telnet - Mirai and its variants brute-forced default credentials on IoT devices in 2016. But CVE-2026-24061 is different: it doesn't require weak passwords. It bypasses authentication entirely.


Any device running GNU Inetutils telnetd 1.9.3-2.7 with telnet exposed to the internet is vulnerable. No brute force. No credential stuffing. Just a malformed environment variable.


Independent Verification


VirusTotal community reports confirm the mass scanning activity. Multiple security vendors flagged the server's IP as malicious and provided detailed analysis:

  • Defensium classified it as MITRE ATT&CK T1190 (Exploit Public-Facing Application), noting "a focused scan on Telnet (23), commonly associated with identifying legacy or weakly secured remote-access services for exploitation attempts."
  • Pure7 flagged it under the same T1190 classification with identical language about telnet scanning for exploitation.
  • CheckTheSum reported "Port Scanning" activity.


These reports were filed on June 22, 2026 - the day before we discovered the open directory listing. The independent detection confirms this is not a one-off observation but active, widespread scanning that multiple security vendors have flagged.


The following screenshot shows the VirusTotal community comments confirming the telnet scanning activity:


What We Found on the Server

Beyond the bash history, the exposed directory contained:

  • SSH private key (`id_rsa`) for `root@rootdebian-pm` - full 2048-bit RSA key, exposed in plaintext
  • HTTP server - `nohup python3 -m http.server 8080 &` - serving the directory for file sharing


The SSH key and Directory Listing is a critical operational security failure. Anyone with access to the directory listing can potentially use that key to gain access to the infrastructure the operator controls.


Attribution

We are not attributing the operator at this time.


The infrastructure sits on Corbina Telecom IP address space (AS8402), a provider that has been a known target of Russian cyber operations. The operator registered a free `.pp.ua` domain that matches the SSH key and hostname - but free Ukrainian domains require no identity verification and can be registered by anyone.


Language indicators: The bash history contains comments in Russian, suggesting the operator may be Russian-speaking.


The following screenshot shows bash history entries with Russian-language comments:


The comments translate to investigative commands: "Check when the user was created," "Check if he is added to sudoers," "Successful and unsuccessful SSH logins," and "Check if sshd_config was changed."


What we can say:

  • The operator demonstrates knowledge of kernel tuning and masscan configuration.
  • They're systematic and methodical (exclude lists, iterative script development).
  • They're conducting internet-wide scanning and exploitation.
  • They exposed their own infrastructure via an open directory.
  • The infrastructure is hosted on Corbina Telecom IP address space (AS8402).
  • The operator controls `rootdebian-pm` (hostname), and `root@rootdebian-pm` (SSH key) - all using the same naming convention.
  • The operator appears to be Russian-speaking based on bash history comments.

What we cannot determine:

  • Whether the operator is a Corbina employee, an external attacker, or a state-aligned actor.
  • Whether the scanning is authorized security research or malicious activity (though unlikely given the uncontrolled targeting).
  • The operator's true identity or exact location.


Recommendations

For Defenders

  • Disable telnet. In most cases, there is no legitimate reason to run telnet in 2026. SSH has been the standard for two decades. If you have telnet exposed, you've already lost.
  • Patch GNU Inetutils. If you must run telnet (legacy systems, industrial control), upgrade to a version that patches CVE-2026-24061. Check your version:
  telnetd --version

 If it reports 1.9.3 through 2.7, you're vulnerable.

  • Network segmentation. Telnet should never be internet-facing. If it's internal-only, ensure it's behind a firewall with strict access controls.
  • Monitor for the indicator. The exploit leaves a trace: the `USER` environment variable set to `-f root` during telnet negotiation. If you have telnet traffic logs, search for this pattern.

For Threat Hunters

  • Scan your own infrastructure. Use masscan or nmap to identify telnet instances in your environment. If you find any, assume they may be vulnerable and check the version.
  • Hunt for the tooling. Monitor for masscan + telnet combinations in your network telemetry.
  • Check for pivot infrastructure. The exposed SSH key (`root@rootdebian-pm`) is a pivot point. If you see this key in your logs or similar wording added to your authorized_keys, investigate immediately.


The Bigger Picture

This isn't just one operator. The 800,000 exposed telnet instances represent a massive attack surface that threat actors are actively probing. CVE-2026-24061 - an 11-year-old flaw that sat undetected until January 2026 - is now fueling exploitation campaigns at internet scale.


The operator we observed is using off-the-shelf tools (masscan, telnet) and a known exploit. But they're systematic, they're scaling, and they're building infrastructure that may be used for further attacks.


The question isn't whether threat actors are scanning for this. They are. The question is how many of those 800,000 exposed telnet instances are vulnerable, and whether yours is one of them.


If you have telnet exposed to the internet, you're not just vulnerable - you're likely already being targeted.


IOCs

ASN	AS8402 (Corbina Telecom)
Operator Domain	*.pp.ua (free Ukrainian domain - redacted as the server is still live)
SSH Key Comment	`root@rootdebian-pm`
Exploit Pattern	`USER="-f root" telnet -a <target> 23`
Scanning Tool	masscan at 80,000 pps targeting port 23
MITRE ATT&CK	T1190 (Exploit Public-Facing Application)


References

  • https://nvd.nist.gov/vuln/detail/CVE-2026-24061
  • https://www.offsec.com/blog/cve-2026-24061/
  • https://www.penligent.ai/hackinglabs/the-ghost-in-the-shell-dissecting-cve-2026-24061-and-the-global-crisis-of-exposed-telnet-assets/
  • https://www.sonicwall.com/blog/gnu-inetutils-telnetd-rce-cve-2026-24061
  • https://www.bleepingcomputer.com/news/security/nearly-800-000-telnet-servers-exposed-to-remote-attacks/