CVE-2026-8751 is a high severity (CVSS 7.3) unsafe deserialization flaw in h2oai H2O-3 up to version 7402. The importBinaryModel function in the JAR handler can be abused remotely. The record says the vendor did not respond, so no fix is confirmed. Restrict network access and avoid importing untrusted models.
What's affected
The record lists H2O-3 up to 7402, and names the function importBinaryModel in h2o-core, in the component that handles model JAR files. It says the attack can start from the network and needs no privileges.
The record also says the disclosure is public and that the vendor did not answer when contacted. I could not confirm a fixed release, so check the H2O-3 project releases and security notes for a newer version.
How to check if you're exposed
Find the version of every H2O-3 deployment, including notebooks, containers and embedded copies in data science platforms.
pip show h2o
For Java or Sparkling Water deployments, look at the jar file name or the build information shown in the H2O Flow web interface. Then check network exposure: H2O's REST API port is often left open inside a cluster network. Anything reachable by people or systems you do not fully trust is in scope.
What to do now
- List every H2O-3 instance and its version.
- Put the API behind a firewall or private network. Do not expose it to the internet.
- Require authentication in front of H2O, for example through a reverse proxy.
- Only import model files you built yourself or can verify.
- Check the project for a release newer than 7402 that addresses this and update when you can confirm one.
Why it matters
The record lists CWE-20 (improper input validation) and CWE-502 (deserialization of untrusted data). Deserialization rebuilds objects from bytes. If the bytes come from someone else and the code does not restrict which classes can be built, the data can steer what the program does.
Machine learning platforms often move model files around as if they were data, when they are closer to programs. Treat a model from an unknown source like an executable.
The record says a public exploit exists. It does not say the flaw is exploited in the wild, and it is not in the CISA KEV list.
Quick check
Is there a fix?
I could not confirm one. The record says the vendor did not respond. Watch the project releases and reduce exposure in the meantime.
What is the safest short term step?
Make the API unreachable from untrusted networks and stop importing models from sources you do not control.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Listed in the record but not readable when this guide was written, so confirm details there:
Last reviewed: 19 October 2026.
