CVE-2026-77420 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, DefaultHistory.matchPatterns(String patterns, String line) in reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java converts the HISTORY_IGNORE configuration value into a Java regular expression while escaping only part of its syntax, allowing other regex metacharacters to reach the backtracking engine. An attacker who can control application or user configuration can supply a nested-quantifier expression that is reevaluated whenever a command is added to history, consuming excessive CPU and indefinitely blocking the reader thread. This issue is fixed in versions 3.30.15 and 4.3.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified within the JLine Java library represents a significant Regular Expression Denial of Service (ReDoS) risk, stemming from improper input validation during history management operations. JLine is widely utilized in enterprise applications for handling console input, command-line interfaces, and interactive shells. The core technical flaw resides in the DefaultHistory.matchPatterns method, specifically within versions ranging from 3.0.0 up to 3.30.15 and version 4.3.1 of the library. When an application utilizes JLine for user interaction, it often allows users or administrators to configure which commands should be ignored by history tracking via a HISTORY_IGNORE configuration parameter. The vulnerability arises because this configuration value is directly converted into a Java regular expression pattern without comprehensive sanitization. While certain syntax elements are escaped to prevent injection attacks, the implementation fails to escape all regex metacharacters effectively. This incomplete escaping allows specific patterns containing nested quantifiers to be passed intact to the underlying regex engine.
The operational impact of this flaw is severe due to the algorithmic complexity inherent in backtracking regular expression engines when processing maliciously crafted inputs. An attacker who possesses the ability to control application configuration or influence user input can supply a specifically designed string that triggers catastrophic backtracking. This occurs because nested quantifiers, such as repeated groups containing other repetitions, force the regex engine to explore an exponential number of possible matches before determining that no match exists or completing the search. In the context of JLine, this processing is triggered whenever a new command is added to the history buffer during normal user interaction. Consequently, if an attacker can induce the system to process such a pattern, it results in excessive CPU consumption and indefinite blocking of the reader thread. This effectively creates a denial-of-service condition where the application becomes unresponsive, as the main input handling thread is permanently occupied by the regex evaluation task rather than processing legitimate user commands or maintaining session integrity.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting through algorithmic complexity attacks on regular expressions. It also maps to MITRE ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources for their own purposes or causes a denial of service by exhausting system capacity. The attack vector is primarily local or requires initial access to modify configuration files or inject input into the console interface, making it particularly dangerous in environments where users have elevated privileges or when configurations are managed through untrusted sources.
To mitigate this vulnerability, organizations must immediately upgrade JLine to version 3.30.15 or later for the legacy branch and version 4.3.1 or later for the current development line. These versions contain patches that address the incomplete escaping of regex metacharacters in the history matching logic. For applications unable to update immediately, a temporary mitigation involves restricting the HISTORY_IGNORE configuration value to only allow simple literal strings without special characters, thereby preventing the construction of nested quantifier patterns. Additionally, implementing input validation layers at the application boundary can help filter out potentially malicious regular expression syntax before it reaches the JLine library. Regular security audits focusing on third-party dependencies and their handling of user-supplied data are essential to prevent similar algorithmic complexity vulnerabilities in other components of the software stack.