GHSA-ph9c-7hw9-vhhw: Medium severity maven/org.jline:jline-builtins vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.jline:jline-builtinsto a version that resolves this vulnerability.Fixed in 3.30.15 - Upgrade
Upgrade
maven/org.jline:jline-builtinsto a version that resolves this vulnerability.Fixed in 4.3.1 - Upgrade
Upgrade
com.google.re2j:re2jto a version that resolves this vulnerability.Fixed in 1.8 - 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
Frequently Asked Questions
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.
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.
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.
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.