CVE-2026-56741: 
Java vulnerability analysis and mitigation

CVE-2026-56741 is an unauthenticated remote Denial of Service vulnerability in the JLine3 Telnet server (remote-telnet module) caused by unbounded acceptance of terminal dimensions via the Telnet NAWS (Negotiate About Window Size) option. An unauthenticated attacker can send crafted NAWS subnegotiation packets advertising extreme terminal sizes (up to 65535×65535) and alternate between values to trigger continuous, CPU-intensive rendering cycles on the server. All versions of org.jline:jline-remote-telnet before 4.2.1 are affected. The vulnerability was published on June 17, 2026, with a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory).

The root cause is CWE-400 (Uncontrolled Resource Consumption): TelnetIO.handleNAWS() (TelnetIO.java:856–879) reads client-supplied width and height as 16-bit unsigned integers and enforces only a lower bound (minimum 20 columns / 6 rows), accepting values up to 65535 without an upper limit. The geometry change event propagates to Telnet.java:153–158, which calls terminal.setSize(new Size(65535, 65535)) and raises a WINCH signal, triggering LineReaderImpl.handleSignal() → redisplay(). Within redisplay(), freshLine() loops up to 65,534 iterations building and writing space-padding strings over the network socket, and columnSplitLength() is called multiple times processing all characters against the 65,535-wide line width. Because WINCH only fires on change, an attacker alternates between two large values (e.g., 65535 and 65534) at ~10 packets/second to sustain an unlimited stream of expensive render cycles. No authentication is required, as NAWS negotiation occurs before any login sequence. A public PoC consisting of two raw Telnet packet sequences is included in the advisory (GitHub Advisory).

Successful exploitation causes CPU exhaustion on the server, with a single unauthenticated connection at ~10 NAWS packets per second sufficient to fully occupy one connection-handling thread. Because connection threads are reused for the life of the session, one attacker per available connection slot can deny service to all legitimate users of that slot. There is no confidentiality or integrity impact; the vulnerability is purely an availability issue affecting any application embedding the JLine3 remote-telnet module with a network-exposed Telnet server (GitHub Advisory).

1. Reconnaissance: Identify network-exposed JLine3 Telnet servers (default Telnet port, typically TCP 23 or application-specific port) using network scanners such as Nmap or Shodan, targeting services running org.jline:jline-remote-telnet versions prior to 4.2.1.
2. Establish Telnet connection: Open a raw TCP connection to the target Telnet server. No authentication or login is required — NAWS negotiation occurs at the protocol level before any login sequence.
3. Send alternating NAWS packets in a loop: Transmit the following two raw Telnet packets alternately at approximately 10 packets per second:
   • Packet 1 (NAWS 65535×65535): FF FA 1F FF FF FF FF FF F0
   • Packet 2 (NAWS 65534×65534): FF FA 1F FF FE FF FE FF F0
4. Trigger CPU exhaustion: Each alternating packet causes the server to raise a WINCH signal, invoking redisplay() which loops up to 65,534 iterations and writes large space-padding strings over the socket, pegging one CPU core per connection.
5. Sustain DoS: Maintain the connection and continue sending alternating packets; the server remains in a degraded state for the duration of the connection, denying service to legitimate users of that connection slot (GitHub Advisory).

• Network: Inbound Telnet connections sending repeated NAWS subnegotiation packets (IAC SB NAWS sequences, bytes FF FA 1F) at high frequency (~10/second or more) from a single source IP; large volumes of outbound data from the Telnet server to a single client (space-padding writes).
• Process: Sustained high CPU utilization on the JVM process hosting the JLine3 Telnet server, particularly on connection-handling threads; thread dumps showing threads blocked in LineReaderImpl.redisplay() or freshLine().
• Logs: Application logs showing rapid, repeated CONNECTION_TERMINAL_GEOMETRY_CHANGED events from a single client; unusual WINCH signal handling frequency in JLine3 debug logs (GitHub Advisory).

Upgrade org.jline:jline-remote-telnet to version 4.2.1 or later, which introduces an upper bound on accepted terminal dimensions. As a network-level workaround, restrict access to the Telnet server port using firewall rules to trusted IP ranges, or disable the remote-telnet module entirely if Telnet access is not required. Rate-limiting inbound Telnet connections at the network perimeter can also reduce exposure (GitHub Advisory).

The vulnerability was identified by Michał Majchrowicz and Marcin Wyczechowski of the AFINE Team and disclosed responsibly to the JLine3 maintainers. The advisory was published by maintainer gnodet on June 17, 2026. No significant broader media coverage or notable community commentary beyond the advisory itself has been observed (GitHub Advisory).