CVE-2026-56740: JLine Telnet Server DoS Vulnerability

CVE-2026-56740 Overview

CVE-2026-56740 is a resource exhaustion vulnerability [CWE-400] in JLine, a Java library for handling console input. The JLine3 Telnet server remote-telnet module fails to limit the number of environment variables a client can inject through the Telnet NEW-ENVIRON option. An unauthenticated attacker can flood the server with unique variable pairs before sending the terminating IAC SE byte. This causes the JVM heap to exhaust and produces an OutOfMemoryError, resulting in denial of service. The issue is fixed in versions 3.30.14, 4.0.16, and 4.2.1.

Critical Impact
An unauthenticated network attacker can crash any JLine3-based Telnet server by exhausting JVM heap memory, causing full application denial of service.

Affected Products

JLine3 remote-telnet module versions prior to 3.30.14
JLine3 remote-telnet module 4.x versions prior to 4.0.16
JLine3 remote-telnet module 4.2.x versions prior to 4.2.1

Discovery Timeline

2026-07-17 - CVE-2026-56740 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-56740

Vulnerability Analysis

The vulnerability resides in the TelnetIO.readNEVariables() method of TelnetIO.java at lines 1127–1180. This method parses the Telnet NEW-ENVIRON option, which allows a client to negotiate environment variable name and value pairs during session setup. Each parsed variable pair is stored in a HashMap held by the ConnectionData object.

The implementation applied length limits per variable name and per variable value but did not cap the total number of pairs accepted before the terminating IAC SE byte. An attacker can therefore stream an unbounded number of distinct variables in a single unauthenticated session. The HashMap grows without bound until the JVM raises an OutOfMemoryError, terminating the service.

Root Cause

The root cause is missing input validation on the count of NEW-ENVIRON variable pairs. Constants NE_VAR_NAME_MAXLENGTH (50) and NE_VAR_VALUE_MAXLENGTH (1000) constrained the size of individual entries but no analogous constant bounded the collection size. Uncontrolled resource consumption falls under [CWE-400].

Attack Vector

The attack requires only network access to a Telnet listener backed by JLine3. No authentication or user interaction is needed. The attacker connects, negotiates the NEW-ENVIRON option, and streams unique variable pairs continuously without emitting the IAC SE sub-negotiation terminator. Because the parser stores every pair in a HashMap before the sub-negotiation completes, memory grows until the JVM exhausts its heap.

java

// Patched code from remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java
    protected static final int NE_IN_END = -3;
    protected static final int NE_VAR_NAME_MAXLENGTH = 50;
    protected static final int NE_VAR_VALUE_MAXLENGTH = 1000;
+   protected static final int NE_VAR_COUNT_MAX = 100;
    /**
     * Unused
     */
// Source: https://github.com/jline/jline3/commit/0389f0ee6d0375901b602671ad5dafd4d1d4ee09

The patch introduces a new constant NE_VAR_COUNT_MAX = 100 that bounds the total number of variable pairs accepted per NEW-ENVIRON negotiation.

Detection Methods for CVE-2026-56740

Indicators of Compromise

Java process crashes or restarts with java.lang.OutOfMemoryError: Java heap space in application logs.
Sustained inbound TCP connections to Telnet listener ports (commonly 23 or custom ports) originating from a single source without completing sub-negotiation.
Sharp growth of heap utilization coinciding with a Telnet session, followed by JVM termination.
Repeated IAC SB NEW-ENVIRON byte sequences within a single session without a corresponding IAC SE terminator.

Detection Strategies

Inspect application logs for OutOfMemoryError events tied to JLine TelnetIO stack traces.
Perform software composition analysis on Java applications to flag JLine3 versions below 3.30.14, 4.0.16, or 4.2.1.
Deploy network monitoring rules that alert on unusually long Telnet sub-negotiations or high byte volume in NEW-ENVIRON payloads.

Monitoring Recommendations

Track JVM heap metrics on services exposing Telnet interfaces and alert on abnormal allocation rate spikes.
Aggregate Telnet server crash and restart counts per source IP over rolling windows.
Correlate connection duration with byte counts to surface single sessions consuming disproportionate resources.

How to Mitigate CVE-2026-56740

Immediate Actions Required

Upgrade JLine to 3.30.14, 4.0.16, or 4.2.1 in all Java applications using the remote-telnet module.
Restrict network access to Telnet listeners using firewall rules that permit only trusted management networks.
Enforce JVM heap and connection limits on services running JLine3 to reduce blast radius from resource exhaustion attempts.

Patch Information

The maintainers fixed the flaw by introducing NE_VAR_COUNT_MAX = 100 in TelnetIO.java and enforcing the bound while parsing NEW-ENVIRON sub-negotiations. See the GitHub Security Advisory GHSA-47qp-hqvx-6r3f and the fix commits: 0389f0e, 4ee3a73, and 934f09e. Fixed releases: jline-3.30.14, 4.0.16, and 4.2.1.

Workarounds

Disable the Telnet server component in JLine-based applications where it is not required for operation.
Place the Telnet listener behind a reverse proxy or bastion that enforces authentication and per-connection byte limits.
Apply operating system firewall rules or TCP wrappers to restrict source addresses that can reach the Telnet port.

bash

# Example: restrict Telnet access with iptables to a management subnet
iptables -A INPUT -p tcp --dport 23 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 23 -j DROP

# Example Maven dependency update to a fixed version
# <dependency>
#   <groupId>org.jline</groupId>
#   <artifactId>jline-remote-telnet</artifactId>
#   <version>3.30.14</version>
# </dependency>