CVE-2026-24061

What it actually does

GNU Inetutils telnetd through version 2.7 improperly handles the USER environment variable during remote Telnet authentication. A remote, unauthenticated network attacker can supply a crafted USER value such as "-f root" that is interpreted as an argument rather than a username, allowing authentication to be bypassed and a privileged login context to be reached. Because the flaw is network reachable, requires no credentials, no user interaction, and can result in root-level access, it has full confidentiality, integrity, and availability impact.

Why it matters to the business

Exposed Telnet services using vulnerable GNU Inetutils can be taken over remotely without valid credentials, creating immediate risk of server compromise, data theft, malware deployment, lateral movement, service disruption, and persistence. The issue is listed in CISA KEV with a remediation deadline of 2026-02-16, has active in-the-wild exploitation and a very high EPSS score, so internet-facing or broadly reachable Telnet services should be treated as an emergency remediation priority even though ransomware use is not currently indicated.

How an attack unfolds

An attacker scans for systems exposing Telnet, typically TCP port 23, and identifies GNU Inetutils telnetd instances or downstream packages/images that include the vulnerable daemon. During the Telnet session, the attacker sends a crafted USER environment variable containing an option-like value such as "-f root". Vulnerable telnetd passes or interprets this value in a way that alters the authentication flow, allowing the attacker to bypass normal credential checks and obtain an interactive shell, potentially as root. After access, the attacker can enumerate the host, add credentials or SSH keys, deploy tooling, pivot to adjacent systems, exfiltrate data, or disable services and logs.

How to fix it

Upgrade all affected GNU Inetutils telnetd deployments to a vendor-fixed release, or remove/disable Telnet entirely. For Chainguard and Wolfi packages listed in the advisory, upgrade to at least: ruby-3.2, ruby-3.2-dev, and ruby-3.2-doc version 3.2.9-r3; jruby-9.4-default-ruby version 9.4.14.0-r0; graalvm-23, graalvm-23-ce, graalvm-23-ce-dbg, graalvm-23-ce-default-jdk, graalvm-23-ce-jmods, graalvm-23-ce-nodejs, graalvm-23-ce-nodejs-dbg, graalvm-23-ce-nodejs-default-jdk, graalvm-23-ce-nodejs-jmods, graalvm-23-graalpy, and graalvm-23-graalpy-venv version 23.0.2-r8; and graalvm-24, graalvm-24-ce, graalvm-24-ce-dbg, graalvm-24-ce-default-jdk, graalvm-24-ce-jmods, and graalvm-24-ce-nodejs version 24.0.2-r7. If Telnet is not explicitly required, uninstall inetutils-telnetd, disable the telnetd/xinetd/inetd service, and block TCP/23 at host and network firewalls. If Telnet must remain temporarily, restrict access to a tightly controlled management network, require compensating authentication at a jump host, and monitor all Telnet activity until the vulnerable service is removed or patched.

How to confirm the fix worked

Confirm that no vulnerable GNU Inetutils telnetd version through 2.7 remains installed in base images, containers, appliances, or hosts. Validate package versions against the fixed versions for the relevant distribution or image. Check service exposure with host and network controls, including whether TCP/23 is listening and whether telnetd, in.telnetd, inetd, or xinetd is configured to launch Telnet. Confirm firewall policy blocks untrusted access to TCP/23. After patching or removal, restart affected services or rebuild/redeploy images so the running daemon is no longer the vulnerable binary. Review SBOMs and container image scan results for GNU Inetutils and listed downstream packages, and verify that vulnerability scanners no longer report the vulnerable telnetd component.

Typical attack path

1. Scan external and internal address ranges for open Telnet services, especially TCP/23.
2. Connect to the Telnet service and fingerprint the daemon behavior to identify GNU Inetutils telnetd or compatible vulnerable packaging.
3. Initiate a Telnet session that supplies a crafted USER environment variable with an option-like value such as "-f root".
4. Bypass normal authentication and obtain an interactive privileged session.
5. Run discovery commands to identify users, network routes, secrets, and installed security controls.
6. Establish persistence through new accounts, SSH keys, startup scripts, cron jobs, or modified service configuration.
7. Move laterally or stage follow-on payloads, data collection, credential theft, or service disruption.

How to detect it

Search network telemetry for inbound Telnet connections on TCP/23, especially from external or previously unseen sources, followed by successful root or privileged interactive sessions. Review syslog, auth.log, secure, daemon.log, messages, inetd/xinetd logs, and any Telnet session capture for USER environment values containing option-like strings, especially "-f root". Examine /var/log/wtmp, /var/log/btmp, /var/log/lastlog, process accounting, EDR telemetry, and shell histories for root logins over pts/tty sessions that lack a corresponding normal authentication event. Look for telnetd or in.telnetd child processes spawning shells, unusual commands shortly after Telnet connections, new local users, modified sudoers files, added authorized_keys files, new cron/systemd persistence, or outbound connections to unfamiliar infrastructure. If the vulnerability was exposed before remediation, perform credential rotation and lateral movement review because successful exploitation can provide privileged access without leaving a conventional failed-password trail.

• USER=-f root
• USER="-f root"
• USER=-f%20root
• USER=-f\ root
• NEW-ENVIRON USER -f root
• telnetd
• in.telnetd
• /usr/sbin/in.telnetd
• /usr/libexec/telnetd
• /etc/inetd.conf
• /etc/xinetd.d/telnet
• /var/log/auth.log
• /var/log/secure
• /var/log/daemon.log
• /var/log/wtmp
• /var/log/btmp
• tcp/23

What your security team should do

• Immediately identify all assets, images, containers, and appliances exposing Telnet or containing GNU Inetutils telnetd through 2.7.
• Prioritize internet-facing, partner-facing, and flat-network Telnet services for same-day isolation or shutdown because exploitation is active and the EPSS score is very high.
• Disable Telnet wherever possible and replace it with SSH or another encrypted, centrally authenticated management channel.
• Patch or rebuild affected Chainguard and Wolfi packages to the fixed versions listed by the vendor, then redeploy workloads from clean images.
• Block TCP/23 from untrusted networks and alert on any new Telnet listener appearing in production or management networks.
• Hunt for prior exploitation by reviewing Telnet logs, authentication logs, process accounting, shell history, persistence locations, and network telemetry for suspicious USER environment values and unexpected root sessions.
• Treat confirmed exploitation as full host compromise: isolate the host, preserve forensic evidence, rotate credentials, review lateral movement, and rebuild from trusted media.
• Track the CISA KEV deadline of 2026-02-16 as the latest acceptable remediation date, not the operational target for exposed systems.