JLine CVE-2026-77423

Exploitation requires the application to embed JLine's built-in less viewer (Less.java) and to expose it interactively so the attacker can supply search or display-filter patterns - the primary risk profile is multi-user Telnet or SSH deployments backed by a bounded worker pool. The attacker must be able to type a search/display-filter pattern into an active less session, meaning interactive session access is needed (not purely anonymous remote access), and the file content being viewed must contain non-matching lines against which the backtracking regex runs. Limiting factors: impact is availability-only (session thread hang, worker-pool exhaustion) with no data compromise, and applications not exposing the less viewer to untrusted users are unaffected. Versions 3.30.15 and 4.3.1 remediate via SafeRegex and regex timeouts.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) rates this as a network, unauthenticated, availability-only denial of service, which is defensible for a Telnet/SSH-exposed service but treats the search-pattern input as attacker-controllable without any session foothold. In practice the malicious regex comes from whoever is driving the interactive less viewer, so realistic exploitation requires an established interactive session - I assess PR:L rather than PR:N, lowering the effective severity to roughly 6.5. No EPSS score, no CISA KEV listing, and no public proof-of-concept are present in the supplied intelligence, so there is no signal of active or automated exploitation - this is no public exploit identified at time of analysis. The impact is bounded to availability (C:N/I:N): a hung session thread and, in bounded worker-pool deployments, pool exhaustion affecting other users. Net: a legitimate but low-urgency ReDoS/DoS issue, materially lower real-world priority than the 7.5 headline suggests because it needs an interactive session and only degrades availability.

An attacker with access to an interactive JLine-based console (e.g. a Telnet/SSH-exposed CLI application using the built-in less viewer) enters a nested-quantifier search or display-filter pattern such as (a+)+b. When applied to non-matching file lines, Java's backtracking regex engine consumes excessive CPU and indefinitely blocks the session thread; repeating this across sessions can exhaust a bounded worker pool and deny service to other users. No public exploit code is identified, though the nested-quantifier trigger is well understood and trivial to reproduce.