> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Vulnerability in telnetd - URL: https://f4n6.co.uk/security-feed/vulnerability-in-telnetd/ - Published: 2026-09-13T15:29:45.000Z - Updated: 2026-09-13T15:29:45.000Z - Author: Jeff Davies - Tags: #security-feed, CVE-2026-24061 ## 1\. Executive summary CVE-2026-24061 is an authentication-bypass flaw in `telnetd` (GNU InetUtils versions 1.9.3 through 2.7) that allows an unauthenticated attacker to log in to a vulnerable host as **root**. The verified reference data scores this **CVSS 9.8 CRITICAL (CWE-88)**, with **EPSS 98%**, and it was **added to CISA KEV on 2026-01-26** — i.e. it is confirmed exploited in the wild, not merely theoretical. Exploitation is described by CERT-FR as trivial, with public exploit code available, and CERT-FR observes many telnet services still reachable from the Internet. For EMEA financial services the exposure is concentrated in legacy/OT-adjacent estates and any internet-facing telnet daemon; a root-level bypass on such a host is a direct path to credential theft, lateral movement and regulatory-reportable impact. A vendor fix exists (GNU InetUtils 2.8, published 2026-04-29); the correct primary action remains decommissioning telnet. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 17 — ICT-related incident management process | A confirmed-exploited (CISA KEV) root-level authentication bypass in a network service; if any exposed telnetd is compromised, the incident must be handled under the firm's ICT incident management process. | Ensure the process covers detection-to-containment for legacy network services, not just modern application stacks. | | DORA Art. 19 — reporting of major ICT-related incidents to competent authorities | If exploitation of an internet-facing telnetd results in a major ICT-related incident, it is reportable to the competent authority. | Pre-stage the reporting decision path for a root-compromise scenario on legacy infrastructure. | | NIS2 Art. 21(2)(d) — supply chain security measures | The affected component is a third-party/open-source network daemon (GNU InetUtils) embedded in the estate; the flaw is in a supplied component, not bespoke code. | Inventory where GNU InetUtils telnetd is deployed and who maintains it; treat it as a supply-chain exposure to be tracked and remediated. | No other article in the regulatory reference is directly engaged by this item. DORA Art. 18, 24, 28, 29, 30, NIS2 Art. 23 and UK NIS 2018 are not triggered by the facts here. ## 3\. Technical analysis & attack chain ### Confirmed attack chain (from CERT-FR) 1. The attacker identifies a host running a vulnerable `telnetd` — GNU InetUtils versions **1.9.3 to 2.7** — reachable over the network (CERT-FR notes many such services are exposed to the Internet). 2. The attacker sends a crafted request that **bypasses authentication** (CWE-88, argument/command injection class per the verified data). 3. The attacker is logged in **as `root`** without valid credentials. 4. CERT-FR states exploitation is **trivial** and that **public exploit code is available**, so no bespoke capability is required. ### Technical specifics that matter to a defender - **Affected component:** `telnetd` in **GNU InetUtils**, versions **1.9.3 through 2.7**. - **Defect age:** introduced in **March 2015** — this is a long-lived flaw, so any host built from a distro or image carrying InetUtils in that range since 2015 is potentially in scope. - **Impact:** unauthenticated **root** login. This is a full host compromise primitive, not a partial-information or DoS issue. - **Fix:** **GNU InetUtils 2.8**, published **2026-04-29**, contains the patch. CERT-FR notes that at the time of the original 2026-01-21 advisory **no official fix was available**; the 2.8 fix is the later resolution. - **Exposure:** CERT-FR explicitly states that running telnet services is contrary to good practice and observes many internet-reachable telnet services. ### Caveats and discrepancies - The verified reference data records **CWE-88** for this CVE. The source text does not name a CWE; it describes the effect (authentication bypass to root). No classification conflict to reconcile — the verified CWE-88 stands. - The source does not describe post-exploitation behaviour, persistence, C2, lateral movement, or data access. **We do not assert any.** Once an attacker holds root on a telnetd host, the downstream tradecraft is attacker-dependent and is not evidenced in this material. - The source does not name a threat actor. **No attribution is made and none should be inferred** from this advisory. ## 4\. Mitigation & containment ### P1 — within 24 hours - **Decommission telnet.** CERT-FR's primary recommendation is to remove all telnet services. This is the only mitigation that fully closes the exposure and should be the default action. - **Remove internet exposure.** Where decommissioning is not immediately possible, take every telnetd off any Internet-facing interface. CERT-FR states telnet must at minimum not be directly exposed to the Internet. - **Restrict access.** Limit telnetd reachability to a minimum set of trusted IP addresses (host firewall / network ACL / security-group allow-list). - **Hunt for exploitation.** Because this is CISA KEV (confirmed exploited) with EPSS 98%, treat any internet-facing telnetd as a candidate compromise: review telnet authentication and session logs for successful `root` logins without a corresponding credential exchange, and for logins from unexpected source addresses. ### P2 — within 72 hours - **Patch to GNU InetUtils 2.8** (the version containing the fix, published 2026-04-29) on any host where telnetd must remain. Verify the installed InetUtils version before and after. - **Inventory** all hosts and images carrying GNU InetUtils in the 1.9.3–2.7 range, including container base images and appliance firmware, so the fix is applied everywhere the daemon exists — not only where it is currently running. ### P3 — within 7 days - **Eliminate the dependency** where telnetd is present but unused: remove the package/daemon from golden images so the flaw cannot be reintroduced by a rebuild. - **Replace the access path** with SSH (or an equivalent authenticated, encrypted protocol) for any legitimate administrative need that telnet was serving. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The source describes no hashes, domains, IPs, filenames, or other atomic indicators. It does describe exploitable behaviour, so the following behavioural indicators are provided for hunting; they are not machine-pivotable atomic IOCs and are therefore not placed in the copyable block. ### Behavioural indicators | Behaviour | Where to observe | Confidence | | ------------------------------------------------------------------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | Successful root login to telnetd without a preceding valid credential exchange | telnetd / auth / syslog on hosts running GNU InetUtils 1.9.3–2.7 | Medium — derived from the described authentication-bypass effect; single-sourced (CERT-FR) | | Telnet sessions from unexpected or untrusted source addresses | Network flow / firewall logs for TCP/23 | Medium — single-sourced; verify before enforcement | | Internet-reachable telnetd (TCP/23) on any host | External attack-surface scan / firewall policy review | High — CERT-FR states many such services are exposed | ## 6\. Detection The source provides no distinctive strings, filenames, command-line flags, mutexes, or registry keys belonging to the exploit itself. It provides only the affected component, version range, and CVE identifier — none of which are artefacts of the threat and none of which would make a valid detection rule. Per the quality bar, no YARA or Sigma rule is emitted on that basis. Insufficient indicators to author detection rules. ## CVE assessment 1 referenced CVE — **1 actively exploited (CISA KEV)**, 1 critical (CVSS ≥ 9.0) | CVE | CVSS | Exploited | EPSS | Summary | | -------------------------------------------------------------------------------- | ------------ | ---------------- | ---- | --------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-24061](https://nvd.nist.gov/vuln/detail/CVE-2026-24061?ref=f4n6.co.uk) | 9.8 Critical | ⚠ KEV 2026-01-26 | 98% | telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via a "-f root" value for the USER environment variable. | ## 7\. Sources - CERT-FR (ANSSI), "Vulnérabilité dans telnetd" — CERTFR-2026-ACT-003, published 2026-01-21 (updated 2026-05-21). https://www.cert.ssi.gouv.fr/actualite/CERTFR-2026-ACT-003/ ## 8\. Adverse Trace position We assess CVE-2026-24061 as **CVSS 9.8 CRITICAL (CWE-88)**, **CISA KEV-listed since 2026-01-26**, **EPSS 98%** — a confirmed-exploited, trivially exploitable, unauthenticated root-level authentication bypass in GNU InetUtils telnetd 1.9.3–2.7\. The client impact is severe wherever telnetd is reachable: full host compromise as root, with the downstream consequences (credential theft, lateral movement, data access) determined by the attacker and not evidenced in this source. The mitigating fact is that the fix is simple and available — GNU InetUtils 2.8 — and that the correct action, decommissioning telnet, removes the exposure entirely. Our key confidence caveats: the technical detail here is **single-sourced to CERT-FR**; no threat actor is named and **no attribution is made**; and no atomic IOCs are available, so detection must rest on behavioural hunting for anomalous root telnet logins. Adverse Trace will continue to monitor for post-exploitation tradecraft and any actor attribution, and will re-issue if either emerges. --- [Read the original source →](https://www.cert.ssi.gouv.fr/actualite/CERTFR-2026-ACT-003/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*