CVE-2026-77423 in JLine
Summary
by MITRE • 09/23/2026
JLine is a Java library for handling console input. From 3.0.0 until 3.30.15 and 4.3.1, the JLine built-in less viewer passes user-controlled search and display-filter patterns from getPattern(boolean doDisplayPattern) in builtins/src/main/java/org/jline/builtins/Less.java directly to Java's backtracking regular expression engine and repeatedly applies them to file content. A nested-quantifier expression evaluated against non-matching lines can consume excessive CPU and indefinitely block the session thread, and repeated sessions in Telnet or SSH deployments can exhaust a bounded worker pool. This issue is fixed in versions 3.30.15 and 4.3.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified within JLine, specifically affecting versions from 3.0.0 through 3.30.15 for the legacy branch and up to version 4.3.1 in the current line, represents a critical implementation flaw in how user-supplied input is processed by the built-in less viewer component. This Java library, widely used for handling console input across various command-line interfaces, contains a function named getPattern within its Less.java module that accepts search and display-filter patterns directly from users without adequate sanitization or complexity checks. When these patterns are passed to Java's native backtracking regular expression engine, they are applied repeatedly against file content during the viewing process. The core technical flaw lies in the lack of validation for regex structures that exhibit nested quantifiers, such as expressions containing multiple consecutive asterisks or plus signs within capturing groups. This oversight allows an attacker to craft malicious input strings designed specifically to trigger catastrophic backtracking behavior inherent in certain regular expression engines when faced with non-matching inputs against complex patterns.
From a technical perspective, this vulnerability is classified under CWE-400, which denotes Uncontrolled Resource Consumption, and more specifically aligns with the characteristics of Regular Expression Denial of Service (ReDoS). The mechanism involves an attacker providing a carefully constructed regex pattern that forces the Java Virtual Machine to perform an exponential number of computational steps when attempting to match or fail-match against specific input strings. Because JLine applies these patterns repeatedly during file viewing operations, even a single instance of such malicious input can consume excessive CPU cycles indefinitely. This behavior effectively blocks the session thread responsible for handling user interaction, leading to a complete freeze of the console interface. The impact is not merely localized; in environments where multiple sessions are managed through Telnet or SSH connections that rely on bounded worker pools, repeated exploitation attempts by different users or automated scripts can exhaust available resources entirely. This results in a denial of service condition for all active and potentially new connections to the affected system, as the thread pool becomes saturated with hung threads waiting for regex evaluation to complete.
The operational impact extends beyond simple resource exhaustion. In production environments where JLine is integrated into administrative tools or remote access gateways, this vulnerability can be exploited remotely if an attacker has the ability to send input commands that trigger the less viewer functionality. The indefinite blocking of session threads means that legitimate users are locked out, and system administrators lose control over the affected terminal sessions unless they manually intervene at a lower level. Furthermore, because the issue stems from how patterns are processed rather than memory corruption or code execution, it does not typically lead to privilege escalation but serves as an effective vector for disrupting availability services. The persistence of this flaw across multiple major versions highlights the importance of rigorous input validation in libraries that process untrusted text data using powerful parsing engines like regular expressions.
Mitigation strategies primarily involve upgrading to patched versions immediately. Users running JLine version 3.0.0 through 3.30.14 should upgrade to at least version 3.30.15, while those on the newer line must update to version 4.3.1 or later where this issue has been resolved by implementing stricter validation and limits on regex complexity before execution. For organizations unable to patch immediately due to dependency constraints, applying network-level access controls to restrict who can interact with services utilizing JLine's less viewer is a viable temporary countermeasure. Additionally, developers integrating JLine into custom applications should consider wrapping user-supplied patterns in timeout mechanisms or using alternative parsing libraries that do not rely on backtracking engines for high-risk operations. Monitoring system logs for unusual CPU spikes correlated with terminal sessions can also aid in detecting active exploitation attempts of this vulnerability before total resource exhaustion occurs.