GPU VulnDB

Database/AI/ML frameworks & serving

Keras: unvalidated dataset sizes in .keras loading let a poisoned model exhaust node memory

CVE-2026-12570AI/ML frameworks & servingcurated

Impact

keras.models.load_model() reads dataset shape and size fields out of a .keras archive without bounds-checking them, so a crafted file drives an unbounded allocation until the process is OOM-killed (exit 137). On a GPU node this is worse than a normal OOM: the loader typically runs in the same container that holds the GPU, so the kill takes down a worker that has already been scheduled onto an accelerator, and on a node without strict cgroup memory limits the allocation storm can push other pods on the box into reclaim. The exposure is a pipeline that ingests models from a public hub, a shared model registry, or tenant uploads. Keras states this bypasses the earlier fix for CVE-2026-0897, which only covered KerasFileEditor.

Who can reach it

Anyone who can place a .keras file where a serving or training job will load it - a public model hub, a shared registry, or a tenant model-upload path. No authentication to the node is needed; the victim process does the loading.

What to do

Upgrade Keras past 3.15.0 to a build containing commit 4933ea4a5b3fcc24ceacdc276f5bb5dfbd06756c and restart the serving or training workers that load models. No node drain or reboot is involved. Until then, treat model files as untrusted input: load only from registries you control, and run loaders under a hard cgroup memory limit so an OOM kills one worker instead of destabilising the node.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.