JLine vulnerabilities

In JLine from 3.0.0 until 3.30.15 and 4.3.1, the built-in less viewer passes user-controlled search and display-filter patterns 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.

In JLine from 3.0.0 until 3.30.15 and 4.3.1, the built-in grep command accepts a user-controlled regular expression 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.

The JLine Java console library has a vulnerability in the built-in nano editor where regex search mode passes a user-controlled term to the regex engine without timeout or backtracking bound. A malicious expression can cause excessive CPU usage and block the editor session thread.

The JLine library has a vulnerability in DefaultHistory.matchPatterns where the HISTORY_IGNORE configuration value is converted to a regex with incomplete escaping. An attacker controlling configuration can supply a malicious expression that is reevaluated on each history addition, causing excessive CPU usage and blocking the reader thread.

JLine, a Java library for console input, contains a vulnerability in the Telnet server remote-telnet module. The TelnetIO.handleNAWS() function does not limit terminal dimensions received from the client, allowing an unauthenticated attacker to repeatedly set large values (e.g., 65535x65535), causing intensive rendering calculations and CPU exhaustion (DoS).

JLine is a Java library for console handling. Prior to versions 3.30.14, 4.0.16, and 4.2.1, the Telnet module does not limit the number of environment variables a client can inject. An unauthenticated attacker can send many unique variable pairs, causing JVM heap memory exhaustion and an OutOfMemoryError.