GHSA-ph9c-7hw9-vhhw: Medium severity maven/org.jline:jline-builtins vulnerability

Published Sep 23, 2026
·
Updated

Summary

When regex search mode is enabled in the JLine3 nano editor, the user-supplied search term is compiled directly as a Java regular expression with no timeout or backtracking bound. A crafted pattern such as (a+)+b can hang the editor session thread at high CPU, causing a denial of service for that session.

Details

In builtins/src/main/java/org/jline/builtins/Nano.java, the search implementation uses Pattern.LITERAL only when regex mode is disabled. When regex mode is enabled, the search term is compiled as a raw Java regex:

java Pattern pat = Pattern.compile( searchTerm, (searchCaseSensitive ? 0 : Pattern.CASEINSENSITIVE | Pattern.UNICODECASE) | (searchRegexp ? 0 : Pattern.LITERAL));

This regex is then applied to buffer content. Because Java's regex engine is backtracking-based, nested-quantifier patterns can take exponential time on non-matching input.

Affected source location: - builtins/src/main/java/org/jline/builtins/Nano.java - doSearch(String text)

PoC

1. Create a file containing a long run of a characters and open it in the JLine3 nano editor. 2. Enable regex search mode with the editor's regex toggle. 3. Start a search and enter the pattern (a+)+b.

Expected result: - The editor stops responding. - The session 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-builtins and exposing the nano editor are impacted. In local use, the user can hang their own session. In remote multi-user deployments, an attacker can occupy a server worker thread indefinitely.

Suggested Fix

The preferred fix for the current git head is to use a linear-time regex engine for regex search mode while preserving literal matching behavior when regex mode is off.

Suggested patch:

diff diff --git a/builtins/pom.xml b/builtins/pom.xml --- a/builtins/pom.xml +++ b/builtins/pom.xml @@ <dependency> + <groupId>com.google.re2j</groupId> + <artifactId>re2j</artifactId> + <version>1.8</version> + </dependency> + <dependency> <groupId>org.jline</groupId> <artifactId>jline-reader</artifactId> </dependency>

diff --git a/builtins/src/main/java/org/jline/builtins/Nano.java b/builtins/src/main/java/org/jline/builtins/Nano.java --- a/builtins/src/main/java/org/jline/builtins/Nano.java +++ b/builtins/src/main/java/org/jline/builtins/Nano.java @@ -import java.util.regex.Pattern; +import com.google.re2j.Pattern;

If a dependency change is not acceptable, a fallback mitigation is to reject dangerous regex constructs or execute regex matching with a strict timeout, but that is weaker than replacing the backtracking engine.

Credits

This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.

Affected Software

2 affected componentsFixes available
maven/org.jline:jline-builtins>=3.0.0<3.30.15
3.30.15
maven/org.jline:jline-builtins>=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-builtins to a version that resolves this vulnerability.

    Fixed in 3.30.15
  2. Upgrade

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

    Fixed in 4.3.1
  3. Upgrade

    Upgrade com.google.re2j:re2j to a version that resolves this vulnerability.

    Fixed in 1.8
  4. Compensating control

    If replacing the regex engine is not acceptable, reject dangerous regex constructs such as nested-quantifier patterns or execute regex matching with a strict timeout.

Event History

Sep 23, 2026
Advisory Published
via GitHub·06:12 PM
Data Sourced
via GitHub·06:12 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Are users of ordinary text search affected?

No. The search term is compiled with Pattern.LITERAL when regex search mode is disabled. The issue applies when regex search mode is enabled.

2

What conditions are needed to trigger the denial of service?

An attacker or user needs to enter a crafted regular expression, such as one with nested quantifiers, while regex search mode is enabled. The pattern must be applied to buffer content that causes expensive non-matching backtracking, such as a long run of matching-looking characters.

3

What is the impact in practice?

The crafted search can consume high CPU and hang the JLine3 nano editor session thread. The stated impact is denial of service for that editor session.

4

What can be done if an update is not immediately available?

Keep regex search mode disabled so search input is treated as a literal string. Avoid running untrusted or complex regular-expression search terms against editor buffers.

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