CVE-2026-33701
Received Received - Intake
Remote Code Execution via RMI Deserialization in OpenTelemetry Java

Publication date: 2026-03-27

Last updated on: 2026-04-01

Assigner: GitHub, Inc.

Description
OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. On JDK version 16 and earlier, an attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution.Β All three of the following conditions must be true to exploit this vulnerability: First, OpenTelemetry Java instrumentation is attached as a Java agent (`-javaagent`) on Java 16 or earlier. Second, JMX/RMI port has been explicitly configured via `-Dcom.sun.management.jmxremote.port` and is network-reachable. Third, gadget-chain-compatible library is present on the classpath. This results in arbitrary remote code execution with the privileges of the user running the instrumented JVM. For JDK >= 17, no action is required, but upgrading is strongly encouraged. For JDK < 17, upgrade to version 2.26.1 or later. As a workaround, set the system property `-Dotel.instrumentation.rmi.enabled=false` to disable the RMI integration.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-27
Last Modified
2026-04-01
Generated
2026-05-27
AI Q&A
2026-03-27
EPSS Evaluated
2026-05-25
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linuxfoundation opentelemetry_instrumentation_for_java to 2.26.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-502 The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-33701 is a critical vulnerability in the OpenTelemetry Java Instrumentation library affecting versions prior to 2.26.1. The issue arises from unsafe deserialization in the Remote Method Invocation (RMI) instrumentation component, where a custom RMI endpoint deserializes incoming data without applying serialization filters.

An attacker with network access to a JMX or RMI port on an instrumented Java Virtual Machine (JVM) running Java 16 or earlier can exploit this vulnerability to potentially execute arbitrary remote code with the privileges of the JVM process.

Exploitation requires three conditions: OpenTelemetry Java instrumentation must be attached as a Java agent (-javaagent), the JMX/RMI port must be network-accessible, and a gadget-chain-compatible library must be present on the classpath to enable the deserialization exploit.


How can this vulnerability impact me? :

This vulnerability can lead to arbitrary remote code execution on the affected system, allowing an attacker to run malicious code with the same privileges as the user running the instrumented JVM.

Because the attack vector is network-based and requires no user interaction or privileges, it poses a high risk of compromise for systems exposing JMX or RMI ports with OpenTelemetry Java instrumentation attached.

Successful exploitation could result in full system compromise, data theft, service disruption, or further lateral movement within a network.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by checking if your Java application is running with OpenTelemetry Java instrumentation attached as a Java agent (-javaagent) on Java 16 or earlier, and if a JMX or RMI port is explicitly configured and network-reachable.

You should verify the following conditions on your system or network:

  • Check if the Java process includes the OpenTelemetry Java agent: look for the -javaagent flag referencing opentelemetry-javaagent.
  • Check if the JVM is version 16 or earlier.
  • Check if the JMX or RMI port is configured and accessible over the network (e.g., via the system property -Dcom.sun.management.jmxremote.port).

Suggested commands to detect these conditions include:

  • Use `ps aux | grep java` or `jps -lv` to list Java processes and check for the presence of the -javaagent flag with OpenTelemetry Java agent.
  • Use `java -version` or inspect the running JVM version to confirm it is 16 or earlier.
  • Use `netstat -tuln | grep <port>` or `ss -tuln | grep <port>` to check if the JMX or RMI port is open and listening.
  • Attempt to connect to the JMX or RMI port remotely using tools like `telnet <host> <port>` or `nc -vz <host> <port>` to verify network accessibility.

What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability immediately, you should upgrade the OpenTelemetry Java Instrumentation to version 2.26.1 or later, where the unsafe deserialization issue in the RMI instrumentation component is fixed.

If upgrading is not immediately possible, you can apply the following workaround:

  • Disable the RMI integration by setting the system property `-Dotel.instrumentation.rmi.enabled=false` when starting your Java application.

Additionally, if you are running on JDK 17 or later, no action is required, but upgrading is still strongly recommended.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability allows remote code execution on affected systems by exploiting unsafe deserialization in the OpenTelemetry Java Instrumentation RMI component. This can lead to unauthorized access and control over the JVM process, potentially compromising the confidentiality, integrity, and availability of sensitive data.

Such a compromise could impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of sensitive personal and health data against unauthorized access and breaches.

Organizations using vulnerable versions prior to 2.26.1 should upgrade or apply mitigations to reduce the risk of exploitation and maintain compliance with these regulations.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart