Skip to content

← Public intelligence

Maven package

org.jline:jline-builtins

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.5MavenAmendedPublished

    JLine: ReDoS in Nano Editor Regex Search Mode

    CVE-2026-77421 · GHSA-ph9c-7hw9-vhhw

    Affected
    • Maven org.jline:jline-builtins >= 4.0.0, < 4.3.1; >= 3.0.0, < 3.30.15
    Fixed in
    4.3.13.30.15· Vendor fix available
    Issue
    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: 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…

    Recommended action: Upgrade to 4.3.1 or 3.30.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. High, CVSS 7.5MavenAmendedPublished

    JLine: ReDoS in Built-in grep Command Amplified by Automatic .* Wrapping

    CVE-2026-77422 · GHSA-r2xf-8xr9-62gw

    Affected
    • Maven org.jline:jline-builtins >= 4.0.0, < 4.3.1; >= 3.0.0, < 3.30.15
    Fixed in
    4.3.13.30.15· Vendor fix available
    Issue
    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: 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: 2. Run JLine3's built-in grep against that file: Expected result: - The command stops…

    Recommended action: Upgrade to 4.3.1 or 3.30.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →