EUVD-2026-45342
GHSA-2r2c-cx56-8933
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Unauthenticated, network-reachable NAWS input with no user interaction and trivial repetition (AV:N/AC:L/PR:N/UI:N); impact is pure CPU-exhaustion DoS, so A:H with C:N/I:N.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4Blast Radius
ecosystem impact- 1 maven packages depend on org.jline:jline-remote-telnet (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 4.1.0.
DescriptionCVE.org
JLine is a Java library for handling console input. Prior to 3.30.14, 4.0.16, and 4.2.1, the JLine3 Telnet server remote-telnet module does not apply an upper bound to terminal dimensions received via the Telnet NAWS option, and TelnetIO.handleNAWS() in TelnetIO.java:856-879 reads client-supplied width and height as 16-bit unsigned integers and passes values such as 65535x65535 to setTerminalGeometry(), allowing an unauthenticated remote attacker to repeatedly alternate values and trigger continuous expensive rendering work that causes CPU exhaustion and denial of service. This issue is fixed in versions 3.30.14, 4.0.16, and 4.2.1.
AnalysisAI
Denial of service in the JLine3 Telnet server (jline-remote-telnet module) lets an unauthenticated remote attacker exhaust server CPU by abusing the Telnet NAWS window-size option. Because TelnetIO enforces only a lower bound on terminal dimensions, a client can advertise a 65535x65535 terminal and repeatedly alternate values to force continuous, expensive redisplay/rendering cycles. Publicly available exploit code exists (a raw two-packet Telnet PoC is published in the vendor GHSA advisory), and there is no public exploit identified as being actively exploited; the issue is fixed in 3.30.14, 4.0.16, and 4.2.1.
Technical ContextAI
JLine is a widely used Java library for console/line input handling; the vulnerable code lives specifically in its optional remote-telnet module (org.jline:jline-remote-telnet), which implements a Telnet server built on JLine's LineReader. The root cause is CWE-400 (Uncontrolled Resource Consumption): TelnetIO.handleNAWS() (TelnetIO.java:856-879) parses client-supplied width and height from the Telnet NAWS (Negotiate About Window Size, RFC 1073) subnegotiation as 16-bit unsigned integers and forwards them through setTerminalGeometry(), which clamps only the minimum (SMALLEST_BELIEVABLE_WIDTH/HEIGHT, ~20x6) and accepts values up to 65535. The geometry change raises a WINCH signal (Telnet.java:140-175) that drives LineReaderImpl.redisplay() (LineReaderImpl.java:929-962), where freshLine() loops size.getColumns()-1 (~65534) iterations building space-padded output and columnSplitLength() reprocesses the full line width, so each spoofed resize triggers work proportional to the enormous declared dimensions. The CPE cpe:2.3:a:jline:jline3:*:*:*:*:*:*:*:* identifies the affected component as jline3.
RemediationAI
Upgrade JLine to a fixed release on your branch: Vendor-released patch: 3.30.14, 4.0.16, or 4.2.1 (see release notes at https://github.com/jline/jline3/releases/tag/4.0.16 and https://github.com/jline/jline3/releases/tag/4.2.1). The fix (https://github.com/jline/jline3/pull/2000) adds an upper bound of 500 for width and height (LARGEST_BELIEVABLE_WIDTH/HEIGHT) so oversized NAWS geometries are rejected, and also caps environment variable counts (NE_VAR_COUNT_MAX). If you cannot upgrade immediately, the most effective compensating control is to stop exposing the JLine3 Telnet server to untrusted networks - disable the remote-telnet module if unused, or restrict its listening port to trusted management networks via firewall/ACL, accepting that this removes remote console access for legitimate users. Where a resize hook is available you can also clamp incoming terminal dimensions to sane values before they reach setSize(); reference the advisory at https://github.com/jline/jline3/security/advisories/GHSA-2r2c-cx56-8933 for exact code locations.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| openSUSE Leap 16.0 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Linux Enterprise Server 16.0 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.0 | Affected |
| SUSE Linux Enterprise Server 16.0 | Affected |
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.0 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| openSUSE Leap 16.0 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today