CVE-2026-77422 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 grep command in builtins/src/main/java/org/jline/builtins/PosixCommands.java accepts a user-controlled regular expression in grep(...) and, unless line-regexp mode is used, automatically adds a dot-star prefix and suffix before compiling it with Java's backtracking regular expression engine. The wrapping expands the backtracking search space, so a short nested-quantifier expression evaluated against non-matching input can consume excessive CPU and indefinitely block a command worker, including in remotely exposed shell sessions. This issue is fixed in versions 3.30.15 and 4.3.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The JLine library serves as a foundational component for Java-based console applications, providing robust support for handling terminal input, line editing, and command history. Within this ecosystem, the built-in grep utility implemented in PosixCommands.java offers users familiar Unix-like text filtering capabilities directly within interactive shell sessions. However, versions of JLine ranging from 3.0.0 up to 3.30.15 for the legacy branch and 4.3.1 for the newer branch contain a critical implementation flaw related to how regular expressions are processed during grep operations. This vulnerability stems from an insecure handling pattern where user-supplied search patterns are not adequately sanitized or constrained before being passed to the Java Regular Expression engine, leading to potential resource exhaustion attacks that can disrupt service availability and compromise system stability.
The core technical deficiency lies in the automatic wrapping of user-provided regular expressions with dot-star prefixes and suffixes when line-regexp mode is disabled. This design choice aims to ensure that grep matches substrings within lines rather than requiring full-line matches, which aligns with standard Unix grep behavior. However, by prepending . and appending ., the library significantly expands the search space for Java's backtracking regular expression engine. When a user provides a crafted pattern containing nested quantifiers, such as multiple instances of grouping constructs combined with repetition operators like asterisks or plus signs, the engine may enter an exponential time complexity state during evaluation against input that does not match the pattern. This phenomenon is widely known in cybersecurity circles as ReDoS, or Regular Expression Denial of Service, and it exploits the inherent inefficiencies of backtracking algorithms when faced with ambiguous regex structures.
The operational impact of this vulnerability is severe, particularly in environments where JLine powers remotely exposed shell sessions or interactive command-line interfaces accessible over a network. An attacker who can inject malicious regular expressions into grep commands can trigger indefinite CPU consumption on the host system. Because Java threads are typically mapped to operating system threads for blocking I/O and computation, an infinite loop within the regex engine will block the specific worker thread responsible for processing that input. In multi-threaded applications or servers handling multiple concurrent sessions, this can lead to resource starvation where available threads become exhausted waiting for blocked operations to complete. Consequently, legitimate users may experience significant latency, timeouts, or a complete inability to interact with the shell interface until the offending process is terminated manually by an administrator.
This vulnerability aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, specifically focusing on how improper validation of input leads to excessive resource usage. Furthermore, it maps to MITRE ATT&CK technique T1496, Host-Based Denial of Service, as the attacker leverages a local application feature to degrade system performance without necessarily requiring elevated privileges or network-level access beyond what is already granted for shell interaction. The attack vector relies on social engineering or command injection scenarios where an adversary can influence the arguments passed to grep within a JLine-enabled environment.
Mitigation strategies primarily involve upgrading to patched versions of the library, specifically version 3.30.15 and later for the legacy branch, or version 4.3.1 and later for the current development line. These releases address the issue by implementing stricter validation on regular expression complexity or modifying how patterns are compiled to prevent catastrophic backtracking. For organizations unable to immediately upgrade, defensive coding practices should be adopted within custom JLine integrations. This includes validating user input against a whitelist of allowed characters, limiting the length and complexity of regex patterns before compilation, or utilizing alternative matching mechanisms that do not rely on Java's default backtracking engine for untrusted inputs. Additionally, deploying runtime protection solutions such as Web Application Firewalls with regular expression inspection capabilities can help detect and block malicious pattern submissions in externally facing applications built upon JLine.