---
id: "CVE-2026-111074"
kind: "vulnerability"
aliases: ["CVE-2026-111074"]
title: "Eclipse OpenJ9: crafted TCP connections halt JITServer compilation without login"
severity: "high"
cvss: 8.7
epss: 0.00421
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["java", "jitserver", "openj9", "runtime", "self-hosted"]
not_affected_if: ["default-config", "no-jitserver"]
published_at: "2026-10-21T08:16:42+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-24T13:15:54+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111074", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-111074", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Eclipse OpenJ9: crafted TCP connections halt JITServer compilation without login

Eclipse OpenJ9 before 0.63.0 has an integer overflow in the JITServer length-field handling, so an unauthenticated remote client can send a few crafted TCP connections. The compilation worker threads then spin at about 100% CPU, stopping compilation for every connected client JVM.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

Check whether JITServer mode is in use: look for -XX:+JITServer or -XX:JITServerAddress flags in JVM startup options, and check the OpenJ9 version with java -version.

## Fix

Upgrade Eclipse OpenJ9 to 0.63.0 or later.
Until then, restrict network access to the JITServer port to trusted client hosts.

## Timeline

- 2026-10-23T21:57:28+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111074
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-111074

## From the sources

In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service. When processing the initial 4-byte length field of an incoming TCP connection, an integer overflow in `MessageBuffer::computeRequiredCapacity()` causes the receiving compilation worker thread to enter an infinite loop consuming ~100% CPU. An unauthenticated remote attacker can exploit this by opening a small number of crafted TCP connections to exhaust the entire worker thread pool, silently halting compilation services for all connected client JVMs.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_