Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
HIGH severity

CVE-2026-77422 — jline-builtins

HIGHFix: jline/jline3@1d5fc30

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

Also known asGHSA-r2xf-8xr9-62gw
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs42th percentile — riskier than 42% of all scored CVEsHighest risk
0.00%0.33%0.66%1.00%0.5%0.5%Oct 26Oct 26

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

2 pkgs affected
☕org.jline:jline-builtins☕org.jline:jline-builtins

Real-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.java
  • grep(...)

PoC

  1. Create a file containing a long run of a characters:
printf 'aaaaaaaaaaaaaaaaaaaaaaa\n' > /tmp/testfile.txt
  1. Run JLine3's built-in grep against 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

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.jline:jline-builtins≥ 4.0.0&&< 4.3.14.3.1org.jline:jline-builtins:4.3.1
☕Mavenorg.jline:jline-builtins≥ 3.0.0&&< 3.30.153.30.15org.jline:jline-builtins:3.30.15

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

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

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

Red HatImportant

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…

Workaround published by Red Hat
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

### 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: ```java String regex = args.remove(0); String regexp = re
O3 Security · Impact-Aware SCA

Is CVE-2026-77422 in your dependencies?

Find it across Maven, including transitive dependencies.

CVE-2026-77422: jline-builtins — Fixed in 4.3.1