CVE-2026-33701: RMI Deserialization in OpenTelemetry Java Agent

CVE-2026-33701 is an unsafe deserialization flaw in the RMI instrumentation of the OpenTelemetry Java agent. NVD scores it 9.8. It can lead to remote code execution, but only when three conditions all hold. Upgrade to 2.26.1 or turn the RMI integration off.

What's affected

The advisory says versions of the Java agent before 2.26.1 are affected, and 2.26.1 is the patched version. The Maven package is io.opentelemetry.javaagent:opentelemetry-javaagent. The 2.26.1 release on 23 March lists the fix as unsafe deserialization in RMI instrumentation.

The advisory says all three of these must be true:

• The agent is attached with -javaagent.
• An RMI endpoint is network reachable, for example a JMX remote port, an RMI registry or an application exported RMI service.
• A gadget chain compatible library is on the classpath.

The NVD description adds that the exploitable case is on JDK 16 and earlier, because newer JDKs apply serialization filters by default. The NVD text also ties the endpoint to a configured JMX or RMI port.

How to check if you're exposed

Start with the JDK version on each service:

java -version

Then check how the process starts and whether a JMX port is open:

ps aux | grep javaagent
ps aux | grep jmxremote.port

If a process loads the OpenTelemetry agent jar and also sets -Dcom.sun.management.jmxremote.port, note the agent version in the jar file name or your build config. For build level checks, list the dependency tree of services that bundle the agent:

mvn dependency:tree | grep opentelemetry-javaagent

Reachability matters more than the version alone here. A service on JDK 17 or newer, or with no network reachable RMI port, does not meet the conditions described by the advisory.

What to do now

1. Upgrade the OpenTelemetry Java agent to 2.26.1 or later.
2. If you cannot upgrade yet, set -Dotel.instrumentation.rmi.enabled=false, the workaround the advisory gives.
3. Close JMX and RMI ports to anything outside trusted management networks.
4. Move services to a JDK that applies serialization filters by default, version 17 or newer, as part of your normal upgrade plan.
5. Rebuild and redeploy container images so the new agent jar is the one actually running.

Why it matters

The record files this under CWE-502, deserialization of untrusted data. Java deserialization turns bytes into live objects, and existing classes on the classpath can be strung together to run code. Serialization filters limit which classes are accepted, and the advisory says this endpoint applied none.

The impact reaches the privileges of the user running the JVM. Observability agents run inside every service, so a flaw in one agent repeats across your fleet. The same advisory pattern appears for Datadog's agent in CVE-2026-33728.

The record is not marked as exploited in the wild and is not in the CISA KEV catalog.

Try it yourself

Click through it at your own pace, or open it full screen.

This CVE is a good example of why reachability analysis helps. The version is only part of the story, and the exposed port and JDK version decide the real risk.

Quick check

Sources

• GitHub advisory GHSA-xw7x-h9fj-p2c7
• OpenTelemetry Java Instrumentation 2.26.1 release

Last reviewed: 19 October 2026.