GHSA-5q95-hrpc-m3w3: Medium severity maven/org.jline:jline-reader vulnerability
Summary
The JLine3 HISTORYIGNORE variable is converted into a Java regular expression with only partial escaping. As a result, regex metacharacters other than and : are passed through to the regex engine. A crafted value such as (a+)+b can cause catastrophic backtracking each time a command line is added to history, hanging the reader thread at high CPU.
Details
In reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java, matchPatterns() converts HISTORYIGNORE into a regex:
java for (int i = 0; i < patterns.length(); i++) { char ch = patterns.charAt(i); if (ch == '\\') { ch = patterns.charAt(++i); sb.append(ch); } else if (ch == ':') { sb.append('|'); } else if (ch == '') { sb.append('.').append(''); } else { sb.append(ch); } } return line.matches(sb.toString());
This logic translates wildcard syntax but does not escape regex metacharacters such as (, ), +, ?, {, }, [, and ]. Those characters therefore reach the Java regex engine unchanged.
Affected source location: - reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java - matchPatterns(String patterns, String line)
PoC
1. Configure HISTORYIGNORE to a malicious pattern, for example:
sh set history-ignore "(a+)+b"
2. At the JLine prompt, enter a long non-matching line:
text aaaaaaaaaaaaaaaaaaaaaaaaaaax
3. Press Enter.
Expected result: - The prompt does not return. - The reader thread consumes high CPU.
Reproduction environment: - JLine3 on x8664 Linux - OpenJDK 25.0.2
Impact
This is a denial-of-service vulnerability caused by catastrophic regex backtracking. Applications embedding org.jline:jline-reader are impacted if they allow HISTORYIGNORE to be configured through user configuration or application settings. The issue is lower severity than the interactive editor findings because the attacker must control configuration, but it can still reliably hang a reader session.
Suggested Fix
The safest fix for the current git head is to stop treating arbitrary HISTORYIGNORE content as a regex. Instead, escape all characters by default and translate only the intended JLine wildcard syntax () and separator syntax (:).
Suggested patch:
diff diff --git a/reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java b/reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java --- a/reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java +++ b/reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java @@ StringBuilder sb = new StringBuilder(); for (int i = 0; i < patterns.length(); i++) { char ch = patterns.charAt(i); if (ch == '\\') { ch = patterns.charAt(++i); - sb.append(ch); + sb.append(Pattern.quote(Character.toString(ch))); } else if (ch == ':') { sb.append('|'); } else if (ch == '') { sb.append('.').append(''); } else { - sb.append(ch); + sb.append(Pattern.quote(Character.toString(ch))); } } return line.matches(sb.toString());
Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.jline:jline-readerto a version that resolves this vulnerability.Fixed in 3.30.15 - Upgrade
Upgrade
maven/org.jline:jline-readerto a version that resolves this vulnerability.Fixed in 4.3.1 - Configuration
Update reader/src/main/java/org/jline/reader/impl/history/DefaultHistory.java so matchPatterns() uses Pattern.quote(Character.toString(ch)) for ordinary characters instead of appending them directly, preventing arbitrary HISTORY_IGNORE content from reaching the Java regex engine.
JLine3 org.jline:jline-reader HISTORY_IGNORE regex translation in DefaultHistory.matchPatterns() = Escape all characters by default; translate only '*' as '.*' and ':' as '|', while preserving backslash handling
Event History
Frequently Asked Questions
What access does an attacker need to trigger the issue?
The attacker needs the ability to supply or configure the HISTORY_IGNORE value with a crafted pattern. The provided severity vector identifies the attack vector as local and requires low privileges.
When does the crafted pattern consume CPU?
The pattern is evaluated whenever a command line is added to history. A catastrophic-backtracking pattern can hang the reader thread while consuming high CPU.
How can I identify configurations that may be exposed?
Review effective HISTORY_IGNORE values for regex metacharacters that are not intended as JLine wildcard syntax, including parentheses, plus signs, question marks, braces, and square brackets. These characters can reach the Java regex engine unchanged through DefaultHistory.matchPatterns().