OpenTelemetry RMI Deserialization RCE - Unsafe Gadget Chain Exploitation Vector
OpenTelemetry Java instrumentation versions <2.26.1 fail to apply serialization filters on RMI deserialization, allowing unauthenticated remote code execution when RMI endpoints are network-accessible and gadget chains are present. This affects production observability infrastructure with potential for supply-chain compromise.
CVE References
Affected
Vulnerability Class & Root Cause
This is an unsafe deserialization vulnerability (CWE-502) in OpenTelemetry's RMI instrumentation module. The vulnerability stems from the absence of Java serialization filters on custom RMI endpoints registered by the agent. When Java objects are deserialized without filters, attackers can craft malicious serialized payloads containing gadget chains from dependencies (Commons Collections, Spring Framework, etc.) to achieve arbitrary code execution. The RMI protocol itself does not enforce authentication by default on custom endpoints, making this exploitable from the network if exposed.
Proof-of-Concept Significance
A working PoC demonstrates the vulnerability is reliable and does not require race conditions or timing attacks. The attack requires three strict preconditions: (1) OpenTelemetry agent attachment via -javaagent, (2) network-exposed RMI endpoints (JMX ports, RMI registries), and (3) presence of gadget-chain libraries. The PoC validates that these conditions together create an unauthenticated RCE pathway. This is particularly critical because observability agents are often deployed organization-wide and given elevated privileges.
Detection Guidance
Network-level indicators:
- Unexpected inbound connections to RMI ports (default 9010, 9011, or JMX port 9999)
- JMX/RMI traffic from untrusted subnets
- High-volume serialized Java object traffic to RMI endpoints
Application-level signals:
- Java SecurityManager logs of attempted deserialization
- OpenTelemetry agent initialization logs (
otel.instrumentation.rmi.enabled=true) - Presence of gadget-chain libraries in classpath via SBOM analysis
- Unexpected child process spawning from JVM after RMI traffic
Log patterns:
ClassNotFoundExceptionorInvalidClassExceptionin serialization logs- JMX connector authentication failures followed by RMI operations
- Agent startup logs confirming RMI instrumentation is active
Mitigation Steps
Immediate (temporary):
- Set system property:
-Dotel.instrumentation.rmi.enabled=falseto disable RMI instrumentation - Network-segment RMI/JMX ports to trusted internal networks only
- Disable remote JMX access if not operationally required
Long-term (patches):
- Upgrade OpenTelemetry Java instrumentation to version 2.26.1 or later
- Remove unnecessary gadget-chain libraries from classpath (Commons Collections, older Spring versions)
- Enable Java serialization filters via
jdk.serialFiltersystem property - Implement network access controls (firewall rules) restricting RMI port access
- Enable JMX authentication and SSL/TLS encryption
Risk Assessment
Likelihood of wild exploitation: HIGH - RMI ports are frequently exposed in microservice architectures and Kubernetes deployments. Observability agents run with application privileges, making them attractive targets. The preconditions are easily met in typical Python/Java polyglot environments.
Threat actor interest: HIGH - This affects monitoring infrastructure used to detect intrusions, making it attractive for advanced persistent threats seeking to maintain persistence post-compromise. Supply-chain attacks via instrumentation updates are plausible.
Exploitability: HIGH - No authentication required, reliable gadget chains readily available, unauthenticated network access common in cloud environments.
Sources