External risk intelligence

OpenTelemetry Java RMI Deserialization Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-33701

The vulnerability requires an explicitly configured, network-reachable JMX or RMI port on a Java application using an older JDK. While these ports can be exposed, they are typically restricted to internal management or monitoring networks rather than being public-facing by design, making direct internet exposure uncommon in standard deployments.

Deserialization

Linuxfoundation Opentelemetry Instrumentation For Java

before 2.26.1

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in OpenTelemetry Java Instrumentation could allow an attacker with network access to a JMX or RMI port to execute arbitrary code on affected Java applications, potentially impacting system integrity and confidentiality. This issue is particularly relevant for Java 16 and earlier versions where specific configuration conditions are met. The main concern is confirming relevance and exposure.

Unfiltered data input enables remote code execution.
Matters if using older Java and specific management ports.
Confirm if your older Java applications are exposed.

Attack Path

How an attacker could exploit the issue

An attacker could reach a Java application's JMX or RMI port if it's network-exposed and running an older JDK with specific OpenTelemetry Java instrumentation. By sending specially crafted data to this port, the attacker could exploit the instrumentation's deserialization flaw to execute arbitrary code on the server.

Network access to JMX/RMI port required.
Vulnerable RMI instrumentation triggers deserialization.
Risk of remote code execution.

Live Threat

Current exploitation, exposure, and threat context

When OpenTelemetry Java instrumentation is used as a Java agent on Java 16 or earlier, with a network-accessible JMX or RMI port, and compatible libraries on the classpath, an attacker could execute arbitrary code on the instrumented system.

Arbitrary code execution on the JVM.
Network access to JMX/RMI port.
Compromise of the user's privileges.

Operational Fix

Recommended remediation, mitigation, and detection steps

Platform or application owners responsible for Java applications using OpenTelemetry instrumentation should prioritize understanding their exposure to this critical vulnerability. The immediate first step is to identify all instances of the affected OpenTelemetry Java instrumentation, confirm if they are running on JDK 16 or earlier and have a network-accessible JMX or RMI port configured, and then verify the presence of gadget-chain-compatible libraries. This will allow for a risk-based remediation plan, which may involve upgrading OpenTelemetry, configuring specific system properties to disable RMI integration, or coordinating with vendor-management teams if the affected application is from a third party.

Platform and application owners should own this.
Verify JDK version and RMI port exposure.
Plan remediation based on confirmed risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is OpenTelemetry Java Instrumentation?

OpenTelemetry Java Instrumentation is a toolkit for Java applications that automatically collects telemetry data, such as traces and metrics. It is commonly deployed as a Java agent to monitor application performance and behavior without requiring extensive manual code changes.

What does CVE-2026-33701 mean by deserialization?

This vulnerability falls under the CWE-502 weakness class, which involves deserialization of untrusted data. When the software reconstructs objects from incoming data streams without proper filtering, it can be tricked into processing malicious input. In this case, that flaw allows an attacker to execute arbitrary code on the system.

Do I need all these conditions for the bug to be triggered?

Yes. This vulnerability is not triggered unless three specific conditions coincide: the use of OpenTelemetry instrumentation on Java 16 or earlier, an explicitly configured and network-reachable JMX or RMI port, and the presence of specific library files on the application classpath. If any one of these is missing, the attack path is not present.

How do I know if my systems are relevant for this?

According to Halo Surface Signal, this vulnerability is considered unlikely to be reachable from the internet because JMX and RMI ports are typically meant for restricted management or monitoring networks. You should prioritize internal systems where these ports might be broadly accessible or misconfigured.

What is the first step to address this risk?

Begin by auditing your environment to locate applications running on Java 16 or earlier that use this instrumentation. If you cannot immediately upgrade to version 2.26.1 or later, you can disable the vulnerable RMI integration by setting the system property -Dotel.instrumentation.rmi.enabled=false.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.