CVE-2026-77422 is a high-severity (CVSS 7.5) CWE-1333 vulnerability in org.jline:jline-builtins. A fix is available for org.jline:jline-builtins — see the affected versions and patch details below.
JLine: ReDoS in Built-in grep Command Amplified by Automatic `.*` Wrapping
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77422.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-77422 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.jline:jline-builtins☕org.jline:jline-builtinsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The JLine3 built-in grep command wraps the user-supplied regular expression with
.* before compiling it with Java's backtracking regex engine. This amplifies
catastrophic backtracking and allows a short pattern such as (a+)+b to hang the
command thread on non-matching input. In environments that expose the JLine shell to
remote users, this is a denial-of-service issue.
Details
In builtins/src/main/java/org/jline/builtins/PosixCommands.java, the grep
implementation rewrites the user pattern before compilation:
String regex = args.remove(0);
String regexp = regex;
if (opt.isSet("word-regexp")) {
regexp = "\\b" + regexp + "\\b";
}
if (opt.isSet("line-regexp")) {
regexp = "^" + regexp + "$";
} else {
regexp = ".*" + regexp + ".*";
}
The transformed pattern is compiled with Pattern.compile(...) and then used to test
each input line. For a payload such as (a+)+b, the automatic .* prefix and suffix
increase the backtracking search space substantially.
Affected source location:
builtins/src/main/java/org/jline/builtins/PosixCommands.javagrep(...)
PoC
- Create a file containing a long run of
acharacters:
printf 'aaaaaaaaaaaaaaaaaaaaaaa\n' > /tmp/testfile.txt
- Run JLine3's built-in
grepagainst that file:
grep '(a+)+b' /tmp/testfile.txt
Expected result:
- The command stops responding.
- The executing thread consumes high CPU.
Reproduction environment:
- JLine3 on x86_64 Linux
- OpenJDK 25.0.2
Impact
This is a denial-of-service vulnerability caused by catastrophic regex backtracking.
Any application embedding org.jline:jline-builtins and exposing the built-in grep
command is impacted. In remote shell deployments, an attacker can occupy a worker
thread indefinitely and repeat the attack across multiple sessions to reduce service
availability for other users.
Suggested Fix
The preferred fix for the current git head is:
- stop rewriting non-line-regexp searches as
.*...* - use
Matcher.find()for substring semantics - compile user patterns with a linear-time engine such as RE2/J
Suggested patch:
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/PosixCommands.java b/builtins/src/main/java/org/jline/builtins/PosixCommands.java
--- a/builtins/src/main/java/org/jline/builtins/PosixCommands.java
+++ b/builtins/src/main/java/org/jline/builtins/PosixCommands.java
@@
-import java.util.regex.Pattern;
+import com.google.re2j.Pattern;
@@
if (opt.isSet("line-regexp")) {
regexp = "^" + regexp + "$";
- } else {
- regexp = ".*" + regexp + ".*";
}
@@
- boolean m = p.matcher(line).matches();
+ boolean m = opt.isSet("line-regexp")
+ ? p.matcher(line).matches()
+ : p.matcher(line).find();
Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.jline:jline-builtins | ≥ 4.0.0&&< 4.3.1 | 4.3.1org.jline:jline-builtins:4.3.1 |
| ☕Maven | org.jline:jline-builtins | ≥ 3.0.0&&< 3.30.15 | 3.30.15org.jline:jline-builtins:3.30.15 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.jline:jline-builtins, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.jline:jline-builtins to 4.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-77422 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important denial of service flaw in the JLine library's built-in `grep` command. An attacker could provide a specially crafted regular expression, leading to excessive CPU consumption due to amplified backtracking in the regular expression engine. This could indefinitely block command workers, potentially…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-77422 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-77422 in your dependencies?
Find it across Maven, including transitive dependencies.