CVE-2026-33728 is unsafe deserialization in the RMI instrumentation of Datadog's dd-trace-java agent. NVD scores it 9.8. It needs JDK 16 or earlier and a reachable JMX or RMI port. Upgrade to 1.60.3 or disable the RMI integration. The same weakness appears in the OpenTelemetry Java agent as CVE-2026-33701.
What's affected
The advisory lists affected versions as 0.40.0 through 1.60.2 and the patched version as 1.60.3, for the Maven package com.datadoghq:dd-java-agent. NVD says prior to 1.60.2 in its text, so treat 1.60.3 as the target from the advisory and release page.
All three conditions must hold: the agent is attached with -javaagent on Java 16 or earlier, a JMX or RMI port is configured with -Dcom.sun.management.jmxremote.port and is network reachable, and a gadget chain compatible library is on the classpath.
How to check if you're exposed
java -version
ps aux | grep -E "dd-java-agent|jmxremote.port"
Check the agent version in the jar name or your build file. The advisory splits advice by JDK. For JDK 17 and newer, it says no action is required, though upgrading is encouraged. For JDK 8u121 up to but not including 17, upgrade to 1.60.3 or later. For older JDKs without serialization filters, use the workaround.
What to do now
- Upgrade dd-trace-java to 1.60.3 or later.
- If you cannot upgrade, set
DD_INTEGRATION_RMI_ENABLED=false, the workaround in the advisory. - Close JMX and RMI ports to untrusted networks.
- Rebuild images so the new agent jar is in what actually runs.
Why it matters
This is CWE-502, deserialization of untrusted data. The agent registered an RMI endpoint that accepted serialized objects without serialization filters. Code runs with the privileges of the JVM user. The OpenTelemetry Java agent had the same flaw, covered in CVE-2026-33701. The record is not marked as exploited in the wild and is not in CISA KEV.
When you plan the fix, remember that the agent is usually baked into container images or started by an init script. Updating a package in one place does not change images that were already built, so rebuild and redeploy the images, then confirm the new version by checking the running process.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is JDK 17 affected?
The advisory says no action is required on JDK 17 or newer, though it still encourages upgrading.
Sources
Last reviewed: 19 October 2026.