CVE-2026-54712: Uncontrolled Resource Consumption in OpenTelemetry Javaagent RMI Context Propagation

The OpenTelemetry Javaagent provides auto-instrumentation capabilities for Java applications, injecting tracing, metrics, and logging facilities into various frameworks without requiring manual code modifications. Within this ecosystem, Remote Method Invocation (RMI) instrumentation is utilized to capture and trace remote calls across JVM boundaries. To maintain trace context across these distributed boundaries, the agent intercepts incoming and outgoing RMI invocations to propagate context payloads containing trace IDs, span IDs, and associated metadata.

The vulnerability, tracked as CVE-2026-54712, resides in how the OpenTelemetry Javaagent deserializes incoming RMI context propagation payloads. Specifically, when an RMI endpoint is monitored by an instrumented Java Virtual Machine, the agent attempts to parse trace context from the incoming stream. If the network interface exposing the RMI service is reachable by an unauthenticated attacker, malicious payloads can be transmitted directly to the instrumentation layer.

This flaw belongs to the class of Uncontrolled Resource Consumption (CWE-400), which can lead to complete Denial of Service (DoS) of the underlying application. By abusing the context propagation parsing logic, a remote attacker can force the Java Virtual Machine to allocate an excessive volume of heap memory, triggering a java.lang.OutOfMemoryError (OOM) and terminating the host process.

The root cause of CVE-2026-54712 is a lack of validation on the cumulative size of strings deserialized from the RMI context propagation stream. Distributed tracing agents must reconstruct context state from serialized inputs. In vulnerable versions of the OpenTelemetry Javaagent (2.26.1 up to, but excluding, 2.27.0), the context deserialization logic is handled by the ContextPayload class, which extracts keys and values directly from an incoming object input stream.

While the implementation implemented a check on the total number of map entries (MAX_CONTEXT_ENTRIES set to 1000) to prevent CPU-based denial of service or hash collision attacks, it omitted any verification of the length of the individual strings. The deserialization loop sequentially reads string keys and values using the ObjectInput.readUTF() method. This method reads a length indicator from the stream and attempts to allocate and construct a corresponding Java String instance.

Because Java's readUTF() function supports strings up to 65,535 bytes in length, an attacker can supply 1,000 entries where every key and value is of maximum length. The JVM is then forced to allocate memory for 1,000 keys and 1,000 values, each close to 64 KB, within a single short-lived network transaction. This results in the allocation of approximately 131 megabytes of heap memory per malicious payload, bypassing the entry-count limit and exhausting system resources when multiple concurrent requests are processed.

An analysis of the vulnerable source code in io.opentelemetry.javaagent.instrumentation.rmi.context.ContextPayload reveals the precise implementation weakness. The parsing mechanism reads an integer indicating the number of context entries, performs a simple boundary check against MAX_CONTEXT_ENTRIES, and then enters a loop to retrieve the string elements.

// Vulnerable Code Path (v2.26.1)
public static ContextPayload read(ObjectInput oi) throws IOException {
  int size = oi.readInt();
  if (size > MAX_CONTEXT_ENTRIES) { // Only limits entry count, not byte size
    logger.log(FINE, "RMI context propagation payload size {0} exceeds...", size);
    return null;
  }
  Map<String, String> map = new HashMap<>();
  for (int i = 0; i < size; i++) {
    String key = oi.readUTF(); // Allocates string up to 65535 characters
    String value = oi.readUTF(); // Allocates string up to 65535 characters
    map.put(key, value);
  }
  return new ContextPayload(map);
}

The patch implemented in version 2.27.0 introduces two defensive layers. First, the MAX_CONTEXT_ENTRIES limit is lowered from 1,000 to 100, which aligns the threshold with standard corporate limits such as Tomcat's maxHeaderCount. Second, a new constant MAX_CONTEXT_SIZE (8,192 characters) is introduced, and a running total of character allocations is accumulated during the loop.

// Patched Code Path (v2.27.0)
public static ContextPayload read(ObjectInput oi) throws IOException {
  int size = oi.readInt();
  if (size > MAX_CONTEXT_ENTRIES) { // MAX_CONTEXT_ENTRIES is now 100
    logger.log(FINE, "RMI context propagation entries count {0} exceeds...", size);
    return null;
  }
  int contextSize = 0;
  Map<String, String> map = new HashMap<>();
  for (int i = 0; i < size; i++) {
    String key = oi.readUTF();
    String value = oi.readUTF();
    contextSize += key.length() + value.length();
    if (contextSize > MAX_CONTEXT_SIZE) { // MAX_CONTEXT_SIZE is 8192
      logger.log(FINE, "RMI context propagation payload size exceeds maximum...");
      return null; // Triggers early abort
    }
    map.put(key, value);
  }
  return new ContextPayload(map);
}

> [!WARNING] > Note that this check is post-facto. The readUTF() call still instantiates the String object into memory before its length is checked. While this prevents the massive accumulation across 100 entries, an attacker can still force the allocation of a single pair of large strings on the first iteration before the limit is exceeded. This minimal residual risk is unlikely to cause a Denial of Service unless executed under highly concurrent conditions.

Exploiting CVE-2026-54712 requires network line-of-sight to an RMI endpoint exposed by an application running the vulnerable OpenTelemetry Javaagent. Since RMI registries usually listen on default TCP ports such as 1099 or 1098, an attacker begins by identifying accessible RMI services on the target network. Authentication is not required because context propagation is intercepted and processed prior to standard application-level authentication checks.

To construct an exploit, a client sends standard RMI call structures containing a serialized ContextPayload object. The payload is carefully formatted to set the entry count integer to a value just below the validation threshold (e.g., 1000 for vulnerable versions). Each map entry is populated with long dummy string parameters composed of repeating characters to maximize payload volume while keeping computational overhead low.

When the agent receives the RMI packet, it invokes the deserialization routine. The JVM attempts to parse and instantiate the strings on the heap. Because multiple threads often process concurrent RMI calls, a sustained transmission of these oversized packets causes rapid heap consumption. The garbage collector becomes overwhelmed, leading to thread starvation, application unresponsiveness, and an eventual crash due to a java.lang.OutOfMemoryError.

The technical impact of CVE-2026-54712 is a complete loss of availability for the affected Java Virtual Machine. While CVSS v3.1 rates the availability impact as 'Low' (yielding a base score of 5.3), in practical enterprise scenarios, an unhandled java.lang.OutOfMemoryError typically leads to JVM crash or freeze. The process is either terminated by the operating system kernel (OOM Killer) or enters a state of perpetual garbage collection thrashing, rendering the service entirely unresponsive.

Because this vulnerability occurs within the auto-instrumentation agent itself, it affects any downstream application that relies on the agent for monitoring, regardless of whether the business logic itself utilizes RMI. If the target application exposes RMI endpoints for administrative tasks, JMX monitoring, or legacy middleware communications, the entire application becomes vulnerable to remote, unauthenticated disruption.

No confidentiality or integrity impacts are associated with this flaw. The exploit vector is strictly restricted to resource exhaustion and does not allow for remote code execution (RCE) or information disclosure. The vulnerability lacks an active exploitation record in the CISA KEV catalog, and EPSS scores suggest low exploitation probability in standard enterprise networks due to the declining prevalence of externally exposed RMI services.

Remediation requires upgrading the OpenTelemetry Javaagent to version 2.27.0 or higher. This release integrates strict cumulative size boundaries during RMI context parsing, ensuring that any payload exceeding 8,192 characters is rejected immediately, thereby mitigating the risk of heap exhaustion.

If upgrading is not immediately feasible, organizations can implement workarounds to eliminate the attack surface. The most effective workaround is to disable the RMI instrumentation module entirely. This can be accomplished by setting the environment variable OTEL_INSTRUMENTATION_RMI_ENABLED=false or passing the system property -Dotel.instrumentation.rmi.enabled=false at JVM startup.

Additionally, robust network access control lists (ACLs) should be deployed to prevent external networks from accessing RMI registries and communication ports (typically TCP 1099, 1098, and transient dynamic ports). Standard security best practices dictate that RMI and JMX services should never be exposed to the public internet or untrusted zones.