CVE-2026-24802: 
Java vulnerability analysis and mitigation

CVE-2026-24802 is an infinite loop (CWE-835) vulnerability in the jsonrpc4j library by briandilley, specifically within the NoCloseOutputStream.java file in the RPC stream writer component. It affects all versions of com.github.briandilley.jsonrpc4j:jsonrpc4j through 1.6.0, with version 1.7.0 containing the fix. The vulnerability was published on January 27, 2026, and carries a CVSS v4.0 base score of 5.3 (Medium) (Github Advisory, Red Hat CVE).

The root cause is a Loop with Unreachable Exit Condition (CWE-835) in the write method of NoCloseOutputStream.java, which lacks proper input validation before delegating to the underlying output stream. When a malformed or crafted JSON-RPC request is processed, the stream writer can enter an infinite loop, consuming CPU resources indefinitely. The fix, merged via pull request #333, adds input validation to prevent null inputs and out-of-bounds array access, and ensures operations only proceed with valid inputs (Github PR #333, Github Advisory). The vulnerability requires passive user interaction (e.g., a request being processed) but no privileges or authentication, making it exploitable by any network-accessible attacker.

Successful exploitation causes the affected application to hang indefinitely due to the infinite loop, resulting in a denial-of-service (DoS) condition and service unavailability. The CVSS v4.0 scoring also indicates low confidentiality and integrity impacts on the vulnerable system, suggesting some potential for limited data exposure or modification as a side effect. Downstream systems depending on the jsonrpc4j service may also experience availability degradation (Github Advisory, Red Hat CVE).

1. Reconnaissance: Identify services exposing a JSON-RPC endpoint built on jsonrpc4j version ≤ 1.6.0, using network scanning or application fingerprinting tools.
2. Craft malformed request: Construct a JSON-RPC request with malformed or invalid payload data (e.g., null byte arrays or out-of-bounds array references) designed to trigger the unvalidated write method in NoCloseOutputStream.
3. Send request: Transmit the crafted request to the target JSON-RPC endpoint over the network; no authentication is required.
4. Trigger infinite loop: The write method in NoCloseOutputStream.java enters an infinite loop while attempting to process the invalid input, consuming CPU resources and causing the application thread to hang.
5. Achieve DoS: Repeated requests (automatable) exhaust server resources, rendering the JSON-RPC service unavailable to legitimate users (Github PR #333, Github Advisory).

• Network: Repeated or high-volume JSON-RPC requests to the service endpoint from unexpected source IPs, particularly with malformed or unusually structured payloads.
• Process: Java process hosting jsonrpc4j showing sustained 100% CPU utilization on one or more threads with no corresponding throughput increase.
• Logs: Application logs showing stalled or non-completing JSON-RPC request processing; thread dump output revealing threads stuck in NoCloseOutputStream.write() with no exit.
• Availability: Sudden unresponsiveness of the JSON-RPC service endpoint coinciding with the above indicators.

The fix is available in jsonrpc4j version 1.7.0, which includes proper input validation in the write method of NoCloseOutputStream.java (Github Advisory, Github PR #333). Users should upgrade the Maven dependency com.github.briandilley.jsonrpc4j:jsonrpc4j to version 1.7.0 or later. As of the time of reporting, a formal release of 1.7.0 to Maven Central had not yet been confirmed; users should monitor the project repository and issue #361 for release updates (Github PR #333). As a temporary workaround, restrict network access to JSON-RPC endpoints and implement request rate limiting or input validation at the API gateway layer.

A contributor on the GitHub pull request noted that CVE-2026-24802 was assigned after the fix was merged, and requested a new patch release (e.g., 1.7.1) to make the fix available on Maven Central, particularly one that retains Java 8 compatibility (Github PR #333). The vulnerability received standard automated tracking coverage from vulnerability aggregators (Vulners, VulDB, Bluesky CVE feeds) but no notable independent security researcher commentary or media coverage has been identified.