OpenTelemetry Java Agent 2.26.1 fixes RMI deserialization RCE risk (CVE-2026-33701)

Photo by protect.computer (custom explainer graphic) on protect.computer

What happened

OpenTelemetry published a security advisory for CVE-2026-33701 affecting the Java agent package io.opentelemetry.javaagent:opentelemetry-javaagent.

According to the advisory, versions before 2.26.1 register an RMI instrumentation endpoint that can deserialize untrusted data without proper serialization filters. If the environment is reachable over JMX/RMI, this can allow remote code execution (RCE) with the privileges of the Java process.

The project released v2.26.1 as a security patch and explicitly lists this CVE in the release notes.

Why this matters

OpenTelemetry Java auto-instrumentation is often deployed across production services by default in observability pipelines. That means one vulnerable agent version can quietly exist across many JVMs and environments.

If an attacker reaches an exposed RMI/JMX surface on a vulnerable host, this moves from a telemetry tooling issue to a potential server takeover path.

How to check if you’re affected

Potentially affected systems/services

JVM services running opentelemetry-javaagent versions earlier than 2.26.1.
Java 16-and-older environments where RMI/JMX endpoints are network-reachable.
Services whose classpath includes gadget-chain-compatible libraries.

Concrete verification steps (10–20 minute triage)

Inventory Java agent versions now
- Check startup flags (-javaagent) and deployment manifests across production/staging.
- Mark anything below 2.26.1 as vulnerable.
Confirm RMI/JMX exposure
- Search JVM flags for -Dcom.sun.management.jmxremote.port or other exported RMI services.
- Validate whether those ports are reachable from untrusted networks (not just localhost/admin subnet).
Check runtime mitigation state
- Verify whether -Dotel.instrumentation.rmi.enabled=false is set as a temporary workaround.
- If not set and immediate upgrade is blocked, apply this workaround while scheduling emergency patching.
Patch and verify
- Upgrade to 2.26.1 or newer.
- Restart affected JVM services and confirm the new agent version is active at runtime.
Hunt for suspicious access
- Review logs/firewall telemetry for unexpected connections to JMX/RMI ports.
- Investigate unusual JVM child process execution, outbound callbacks, or privilege escalation events.

Immediate defensive actions

Roll out opentelemetry-javaagent 2.26.1+ on an accelerated timeline.
Restrict JMX/RMI exposure to trusted admin networks or localhost only.
Keep the temporary disable flag (-Dotel.instrumentation.rmi.enabled=false) in place until patched everywhere.

Sources

Bottom line

If your organization runs OpenTelemetry Java auto-instrumentation, treat this as a fleet-level patching task, not a niche library update. The risk hinges on exposure conditions, but affected environments can lead to full remote code execution if left unpatched.