CVE-2026-77420: JLine: ReDoS via `HISTORY_IGNORE` Configuration Variable

Published Sep 23, 2026
·
Updated

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.

Other sources

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 HISTORYIGNORE 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.

MITRE

Affected Software

2 affected componentsFixes available
maven/org.jline:jline-reader>=3.0.0<3.30.15
3.30.15
maven/org.jline:jline-reader>=4.0.0<4.3.1
4.3.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/org.jline:jline-reader to a version that resolves this vulnerability.

    Fixed in 3.30.15
  2. Upgrade

    Upgrade maven/org.jline:jline-reader to a version that resolves this vulnerability.

    Fixed in 4.3.1
  3. Upgrade

    Upgrade org.jline:jline-reader to a version that resolves this vulnerability.

    Fixed in 3.30.15
  4. Upgrade

    Upgrade org.jline:jline-reader to a version that resolves this vulnerability.

    Fixed in 4.3.1

Event History

Sep 23, 2026
CVE Published
via MITRE·06:11 PM
Data Sourced
via MITRE·06:11 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·06:12 PM
Data Sourced
via GitHub·06:12 PM
DescriptionSeverityWeaknessAffected Software
Data Sourced
via NVD·07:19 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

What capability does an attacker need to trigger the issue?

An attacker needs to cause HISTORY_IGNORE to contain a crafted pattern. The reported vector is local and requires low privileges; no user interaction is required.

2

Which HISTORY_IGNORE values are risky?

Values containing regular-expression metacharacters other than the handled wildcard and separator syntax can reach the Java regex engine unchanged. Relevant characters include parentheses, plus signs, question marks, braces, brackets, and similar regex constructs; `(a+)+b` is a reported example.

3

How can I determine whether this code path is present in an application?

Inspect the JLine reader history implementation for DefaultHistory.matchPatterns(String patterns, String line). The affected logic converts `:` to `|` and `*` to `.*` but otherwise appends characters directly into the regular expression.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203