CVE-2024-6960: H2O Machine Learning Platform RCE Flaw

CVE-2024-6960 Overview

CVE-2024-6960 is an insecure deserialization vulnerability in the H2O machine learning platform [CWE-502]. H2O uses Iced classes as its primary serialization format for moving Java objects across cluster nodes. The format permits embedded serialized Java objects, and the deserializer applies no class whitelist when loading models. An attacker can craft a malicious Iced model that chains Java gadgets to achieve arbitrary code execution when the model is imported into H2O. Successful exploitation compromises confidentiality, integrity, and availability of the host running H2O. The vulnerability requires user interaction, typically a data scientist or operator importing the attacker-supplied model file.

Critical Impact

Importing a crafted H2O model file results in arbitrary Java code execution on the cluster node, leading to full host compromise.

Affected Products

• H2O machine learning platform (ai.h2o:h2o-core)
• H2O cluster nodes that ingest externally supplied models
• Downstream applications and MLOps pipelines that import H2O models

Discovery Timeline

• 2024-07-21 - CVE-2024-6960 published to the National Vulnerability Database (NVD)
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-6960

Vulnerability Analysis

The H2O platform exchanges Java objects between cluster components using the proprietary Iced serialization format. The format encapsulates standard Java serialized objects, which the receiving node reconstructs via ObjectInputStream-style deserialization. Because the deserializer accepts any class present on the classpath, an attacker controls which classes are instantiated during model import.

The attacker chains existing classes — known as gadgets — to reach a sink that executes arbitrary commands. Common gadget chains target reflection, JNDI lookups, or runtime command execution available in dependencies bundled with H2O. The result is remote code execution under the privileges of the H2O process.

Exploitation does not require authentication on the network path itself, but it does require a user to import the malicious model. The attack complexity is elevated by the need to craft a gadget chain compatible with H2O's classpath. Refer to the JFrog Vulnerability Report for the technical write-up.

Root Cause

The deserialization routine for Iced models lacks a class allowlist. Any class reachable on the H2O classpath can be instantiated during model load. This violates secure deserialization practice for untrusted input [CWE-502]. The platform treats imported models as trusted data even when they originate from external sources.

Attack Vector

An attacker hosts a crafted Iced model file on a shared repository, model marketplace, or sends it directly to a target user. When the operator imports the model through the H2O UI, REST API, or scripting interface, the deserializer reconstructs the embedded gadget chain. The chain executes Java code, allowing the attacker to run shell commands, exfiltrate training data, or pivot into the broader cluster.

No verified public exploit code is associated with this CVE. The mechanism is described in prose to avoid synthetic examples. See the JFrog research advisory and the Maven Repository entry for h2o-core for version and dependency details.

Detection Methods for CVE-2024-6960

Indicators of Compromise

• Unexpected child processes spawned by the H2O JVM, such as sh, bash, cmd.exe, or powershell.exe
• Outbound network connections from H2O nodes to unknown hosts shortly after a model import event
• Newly written files in H2O working directories that do not match known model artifacts
• H2O log entries referencing reflection, ObjectInputStream, or unusual class loads during model import

Detection Strategies

• Hunt for process trees where the H2O Java process is the parent of a shell or scripting interpreter
• Inspect imported model files for embedded Java serialized object headers (AC ED 00 05) or unexpected class references
• Correlate model import API calls with subsequent file writes, credential access, or network egress on the same host
• Apply YARA rules that flag known Java deserialization gadget class names within Iced or ZIP-packaged models

Monitoring Recommendations

• Enable JVM audit logging and capture class load events for the H2O process
• Forward H2O application logs and host telemetry to a centralized analytics platform for correlation
• Alert on any model import from sources outside an approved internal model registry
• Baseline normal network destinations for H2O nodes and alert on deviations

How to Mitigate CVE-2024-6960

Immediate Actions Required

• Restrict H2O model import to trusted operators and block model uploads from untrusted users or networks
• Treat all externally sourced H2O models as untrusted and do not import them into production clusters
• Isolate H2O clusters on segmented networks with no direct internet egress
• Run the H2O JVM under a dedicated, low-privilege service account with minimal filesystem and network access

Patch Information

No fixed version is referenced in the available advisory data. Review the JFrog Vulnerability Report and the H2O project on Maven Central for the latest releases and vendor guidance. Track upstream H2O advisories before upgrading production deployments.

Workarounds

• Import only models produced by your own training pipelines and stored in an integrity-verified registry
• Sign model artifacts and verify signatures before any H2O import operation
• Run H2O inside a container or sandbox with seccomp, AppArmor, or SELinux profiles that block process execution and outbound connections
• Disable or firewall the H2O REST endpoints that accept model uploads when not strictly required

# Configuration example: restrict H2O service account and network exposure
# Run H2O under a dedicated unprivileged user
useradd --system --no-create-home --shell /usr/sbin/nologin h2osvc

# Bind H2O to loopback or an internal interface only
java -jar h2o.jar -ip 10.0.0.10 -port 54321 -network 10.0.0.0/24

# Block outbound egress from the H2O host (iptables example)
iptables -A OUTPUT -m owner --uid-owner h2osvc -d 10.0.0.0/8 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner h2osvc -j DROP