Unsafe RMI deserialization in dd-trace-java enables potential RCE
TL;DR — If dd-trace-java is attached to a JDK 16-or-earlier JVM and a JMX/RMI port is reachable over the network, unsafe deserialization in RMI instrumentation can potentially be escalated to remote code execution.
What happened
dd-trace-java is Datadog’s Java APM agent used to instrument JVM applications (typically via -javaagent) for tracing and telemetry.
CVE-2026-33728 reports that dd-trace-java’s RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters, which can be exploitable on JDK 16 and earlier if an attacker can reach a configured JMX/RMI port and a gadget-chain-compatible library exists on the classpath. The CVE record assigns a CVSS v4.0 base score of 9.3 (Critical).
This is a classic “management plane meets deserialization” risk: seemingly “internal-only” JMX/RMI exposure is common in real deployments, and Java agent instrumentation can unintentionally widen attack surface when those ports become reachable.
Who is impacted
- Deployments using
dd-trace-javaversions>= 0.40.0, < 1.60.3(per CVE record). - JVMs running JDK 16 or earlier where
dd-trace-javais attached as-javaagent. - Environments where a JMX/RMI port is explicitly configured (e.g.,
-Dcom.sun.management.jmxremote.port) and network-reachable. - Apps whose classpath includes gadget-chain-compatible libraries (required for RCE chaining).
| Component | Affected versions (per CVE record) |
|---|---|
dd-trace-java | >= 0.40.0, < 1.60.3 |
What to do now
- Follow vendor remediation guidance and apply a patched release stream appropriate for your JDK.
"For JDK >= 17, no action is required, but upgrading is strongly encouraged." "For JDK >= 8u121 < JDK 17, upgrade to dd-trace-java version 1.60.3 or later." "For JDK < 8u121 and earlier where serialization filters are not available, apply the workaround." "The workaround is to set the following environment variable to disable the RMI integration:
DD_INTEGRATION_RMI_ENABLED=false." - Treat JMX/RMI exposure as an appsec incident waiting to happen: validate that any JMX/RMI endpoints are not internet-reachable (or broadly reachable inside the corp network) and are bound/filtered according to your platform standards.
- If you suspect exposure, review network telemetry and JVM/service logs for unexpected inbound connections to JMX/RMI ports and scope investigation to the privileges of the JVM process.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.