CVE-2026-77421: 
Java vulnerability analysis and mitigation

CVE-2026-77421 is a Regular Expression Denial of Service (ReDoS) vulnerability in the JLine library's built-in nano editor regex search mode. When regex search is enabled, the user-supplied search term is passed directly to Java's backtracking NFA regex engine in doSearch(String text) within builtins/src/main/java/org/jline/builtins/Nano.java without any timeout or backtracking bound. Crafted nested-quantifier patterns (e.g., (a+)+b) evaluated against non-matching buffer content can consume exponential CPU time, indefinitely blocking the editor session thread. The vulnerability affects org.jline:jline-builtins versions >= 3.0.0 and < 3.30.15, and >= 4.0.0 and < 4.3.1. It was disclosed on September 23, 2026, with a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Feedly).

The root cause is CWE-1333 (Inefficient Regular Expression Complexity), classified under CAPEC-492 (Regular Expression Exponential Blowup). In Nano.java, the doSearch() method compiles the user-supplied search term using Pattern.compile(searchTerm, ...) with no timeout or backtracking limit — Pattern.LITERAL is only applied when regex mode is disabled, leaving raw user input compiled as a Java regex when regex mode is on. Java's backtracking NFA engine can take exponential time on nested-quantifier patterns like (a+)+b when matched against long non-matching strings (e.g., a buffer of repeated a characters). An authenticated user with access to the nano editor can trigger this by enabling regex search mode and entering a malicious pattern. The fix introduced a SafeRegex utility class using a TimeoutCharSequence wrapper that checks System.nanoTime() every 1,024 charAt() calls and throws a RegexTimeoutException if a wall-clock deadline is exceeded (GitHub Advisory, Fix PR #2012).

Successful exploitation causes a denial of service by indefinitely blocking the session thread handling the affected nano editor session at high CPU utilization. In local single-user deployments, the user can only hang their own session. In remote multi-user deployments (e.g., SSH-based Java applications embedding JLine), an attacker can occupy a server worker thread per affected session, potentially exhausting the thread pool and denying service to all users. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The NVD SSVC assessment indicates exploitation is "none" and the vulnerability is not automatable, requiring low privileges (authenticated access to the nano editor). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The advisory includes a conceptual PoC: open a file with a long run of a characters in the JLine3 nano editor, enable regex search mode, and enter the pattern (a+)+b (GitHub Advisory, Feedly).

1. Identify a target: Locate a remote multi-user Java application that embeds org.jline:jline-builtins (versions >= 3.0.0 and < 3.30.15, or >= 4.0.0 and < 4.3.1) and exposes the JLine3 nano editor to authenticated users (e.g., via SSH or a custom shell interface).
2. Authenticate: Obtain low-privilege credentials sufficient to access the nano editor session.
3. Open a large file: Open or create a file in the nano editor containing a long sequence of repeated characters (e.g., thousands of a characters) to maximize backtracking depth.
4. Enable regex search mode: Use the nano editor's regex toggle (typically Alt+R or equivalent keybinding) to switch from literal to regex search mode.
5. Enter a catastrophic regex pattern: Initiate a search and enter a nested-quantifier pattern such as (a+)+b. Because the buffer contains only a characters and no b, the Java regex engine will backtrack exponentially.
6. Achieve DoS: The session thread is now blocked at high CPU consumption. In multi-user deployments, repeating this across multiple sessions can exhaust the server's worker thread pool, denying service to all users (GitHub Advisory).

• Process: Java process(es) consuming sustained high CPU (near 100%) on a single thread without completing work; thread dumps showing threads stuck in java.util.regex.Pattern or java.util.regex.Matcher methods called from org.jline.builtins.Nano.doSearch().
• Logs: Application logs showing unresponsive or hung nano editor sessions; absence of normal session completion events for affected users.
• Network: Persistent, idle-looking connections from authenticated users to the JLine-based service that do not terminate or produce output for extended periods.

Upgrade org.jline:jline-builtins to version 3.30.15 (for the 3.x branch) or 4.3.1 (for the 4.x branch), which introduce the SafeRegex utility with TimeoutCharSequence to enforce wall-clock deadlines during regex matching. The fix was applied via PR #2012 (master) and backported via PR #2018 (jline-3.x branch). If an immediate upgrade is not feasible, consider disabling access to the nano editor's regex search mode at the application level, or restricting access to the JLine nano editor in multi-user deployments. There is no configuration-only workaround that fully mitigates the issue without patching (GitHub Advisory, Fix PR #2012, Backport PR #2018).

The vulnerability was discovered and reported by Michał Majchrowicz and Marcin Wyczechowski of the AFINE Team. The JLine maintainer (gnodet) responded promptly, merging a fix on the same day as disclosure (June 30, 2026) for both the master and jline-3.x branches. The fix was broader than the reported issue, addressing 8 locations across the codebase where user-controlled input was matched as a Java regex without protection, covering multiple related GHSAs. No significant broader media coverage or social media discussion has been identified (GitHub Advisory, Fix PR #2012).