Loading story…
High-severity flaws in Datadog dd-trace-java and OpenTelemetry Java Instrumentation can allow remote code execution through unsafe deserialization in their RMI instrumentation. The issues, tracked as CVE-2026-33728 and CVE-2026-33701, affect dd-trace-java versions 0.40.0 through before 1.60.2 and OpenTelemetry versions before 2.26.1. In both cases, the Java agent registers a custom endpoint that deserializes incoming data without serialization filters, creating an attack path on JDK 16 and earlier when a reachable JMX or RMI port is exposed and a compatible gadget-chain library is present on the classpath.
Successful exploitation would let an attacker execute arbitrary code with the privileges of the JVM process, but only when the agent is attached, the JMX/RMI service is explicitly configured and network-accessible, and the target environment contains a usable gadget chain. Datadog recommends upgrading to 1.60.3 or later, while OpenTelemetry users should upgrade to 2.26.1 or later; both vendors note that JDK 17 and later are not affected in the same way. For older Java deployments where immediate patching is not possible, disabling RMI instrumentation is the primary workaround, including OpenTelemetry's setting:
-Dotel.instrumentation.rmi.enabled=false
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
Elastic published security advisory ESA-2026-22 / GHSA-xw7x-h9fj-p2c7 for Elastic OTel Java 1.10.0. This represents a new vendor-specific disclosure and update related to the Java OTel instrumentation deserialization issue.
Datadog disclosed CVE-2026-33728 affecting dd-trace-java versions 0.40.0 through before 1.60.2, caused by unsafe deserialization in RMI instrumentation that could enable remote code execution on JDK 16 and earlier under specific exposure conditions. Datadog advised upgrading to dd-trace-java 1.60.3 or later, noted JDK 17+ does not require action, and suggested disabling the RMI integration as a workaround for older JDKs.
OpenTelemetry disclosed CVE-2026-33701 affecting Java Instrumentation versions prior to 2.26.1, where unsafe deserialization in RMI instrumentation could allow remote code execution on Java 16 and earlier if a reachable JMX/RMI port and a gadget-chain library were present. The project recommended upgrading to 2.26.1 or later and provided a workaround to disable RMI instrumentation on older JDKs.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
discuss.elastic.co
Open sourcecvefeed.io
Open sourcecvefeed.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Apache Commons Collections contained a critical unsafe-deserialization vulnerability, **CVE-2015-7501**, in its serializable `InvokerTransformer` component. An attacker able to supply crafted serialized Java objects to exposed endpoints—including JMX, RMI, or remote EJB services—could chain vulnerable classes with `sun.reflect.annotation.AnnotationInvocationHandler` to execute arbitrary code under the permissions of the affected Java application. The flaw affected Commons Collections 3.0 and 4.0 and exposed products and applications using the library, including WebLogic, WebSphere, JBoss, Jenkins, and OpenNMS. Apache addressed the issue in Commons Collections versions 3.2.2 and 4.1 by preventing `InvokerTransformer` transformations following deserialization. Red Hat also issued a critical update for JBoss Operations Network 3.3.4, directing customers to shut down and patch every server individually, including each node in high-availability deployments. Organizations should identify applications that deserialize untrusted Java objects and either upgrade the library or apply vendor-provided patches.
Aug 29, 2026
A deserialization vulnerability tracked as **`CVE-2026-25747`** affects the Apache Camel LevelDB component and can lead to arbitrary code execution. Red Hat rated the issue **Important** with a **CVSS v3 score of 7.8**, stating the flaw stems from Camel-LevelDB using **`java.io.ObjectInputStream`** to read LevelDB aggregation repository data without validation or class-loading restrictions. If an attacker can write a malicious serialized Java object into the LevelDB database files, the application may deserialize it and execute attacker-controlled code. Red Hat said no acceptable mitigation is currently available under its product security criteria. In its product status matrix, **Red Hat build of Apache Camel for Spring Boot 4** and **Red Hat Fuse 7** are marked **Will not fix**, while **Red Hat JBoss Enterprise Application Platform 8** and the **JBoss Enterprise Application Platform Expansion Pack** are listed as **Not affected** because the vulnerable component is not present. The issue is cataloged in the CVE program as **`CVE-2026-25747`**.
Aug 20, 2026
A reported Apache Log4j2 deserialization flaw, tracked as Issue #4255, may allow attackers to bypass `FilteredObjectInputStream` protections through the allowlisted `java.rmi.MarshalledObject` class. During native serialized `LogEvent` processing, `Log4jLogEvent.LogEventProxy.readResolve()` can invoke `MarshalledObject.get()`, deserializing an embedded object with an unfiltered `ObjectInputStream`; a compatible gadget chain on the target classpath could then enable remote code execution. The issue may also permit resource-exhaustion denial of service and log injection. Exposure is limited to services that accept native Java-serialized Log4j event objects over the network, rather than ordinary local logging or non-native log transports. A Nuclei template has been proposed to detect blind out-of-band exploitation using Interactsh DNS callbacks against ObjectInputStreamLogEventBridge-style receivers. Reported affected releases include `log4j-api` and `log4j-core` through 2.26.1; an Apache patch and CVE assignment were pending. Rejecting `java.rmi.MarshalledObject` with `-Djdk.serialFilter='!java.rmi.MarshalledObject'` blocks the tested deserialization path.
Aug 28, 2026