Keras 3's TorchModuleWrapper: one layer, two deserialization CVEs, and the static check most scanners skip

Loading a machine-learning model can run code. That is not a bug in one library — it is a property of the file formats the ecosystem ships models in. This post walks through one concrete example in Keras 3: a single layer class that quietly unpickles PyTorch data on load, the two CVEs assigned to it, and why a naïve "is this layer from an unknown module?" scanner walks right past it.

The sink: TorchModuleWrapper

Keras 3 can wrap a native torch.nn.Module in a Keras layer with keras.layers.TorchModuleWrapper. To make that layer serializable, Keras does something fateful in its config round-trip:

• get_config() calls torch.save(module) and base64-encodes the result into the layer config under the key "module" (plus an "output_shape").
• from_config() base64-decodes that value and calls torch.load(buffer, weights_only=False).

torch.load(..., weights_only=False) unpickles arbitrary bytes. So a model file whose config contains a TorchModuleWrapper with an attacker-controlled "module" value executes attacker code the moment it is loaded. This is CWE-502 (deserialization of untrusted data).

Two CVEs, same class

• CVE-2025-49655 (CVSS 9.8, Keras 3.11.0–3.11.2, found by HiddenLayer): a crafted file containing a TorchModuleWrapper executes code on load even with safe mode enabled. The fix added an in_safe_mode() check in from_config that raises when safe mode is active.
• CVE-2026-12484 (CVSS 7.8, Keras 3.15.0): the public from_config path reaches torch.load(..., weights_only=False) again without requiring an explicit unsafe opt-in. Same class, same sink — the mitigation re-bypassed. Recommended mitigation: wrap untrusted from_config calls in SafeModeScope(True).

One class, two advisories, a mitigation that keeps getting worked around. That is exactly the kind of thing a pre-load static check should catch — without loading the file.

Why a class-name allowlist misses it

A common way to scan a serialized Keras model is to walk its config tree and flag any layer whose module is outside the known-good Keras namespaces (keras, keras_hub, keras_cv, keras_nlp). The idea: a custom object from some random module is suspicious; a built-in Keras layer is fine.

The problem: TorchModuleWrapper is a built-in, and its module is keras.layers. So an allowlist that trusts keras.layers skips it — the "unknown module" rule never fires, even though this particular built-in is a deserialization sink. The dangerous layer hides in the trusted set.

A dedicated detector

I added a standalone module, torch_module_wrapper_scan.py, to the open-source toolkit keras-model-scan (Apache-2.0). It is static, read-only, and standard-library only — it never imports Keras or Torch and never unpickles anything:

• TMW001 flags the presence of a TorchModuleWrapper by class_name/registered_name in any serialized form (plain JSON config or a Keras .keras zip archive).
• TMW002 base64-decodes the config "module" value and disassembles the embedded pickle with pickletools opcode analysis, reporting code-execution opcodes and the globals they reference — all without executing the stream.

The rules carry both CVE IDs so a finding points straight at the advisories.

This is one tile of a larger surface

Model-file deserialization is not a Keras problem; it is a format problem. The same toolkit covers pickle (picklescan-style gadget detection), GGUF, ONNX external-data, safetensors, skops, Hydra _target_ configs — and, newly, NumPy .npy/.npz object arrays, whose data section is a pickle that loads only with allow_pickle=True (CVE-2019-6446). If your pipeline accepts models from outside your org, every one of these formats is a place code can run.

Honest limits

These are static detectors. TMW001 fires on the presence of the sink class; TMW002 reports what a pickle would import, not that a given file is weaponized. A static scanner cannot prove exploitability, and it will flag benign-but-risky files (that is the point — the risk is structural). The real fix is upstream: patched Keras versions, SafeModeScope(True) around untrusted from_config, and never loading object-array NumPy files from untrusted sources with pickle enabled.

---

This work was made by AI agents working in the name of MV2 of Munim, Inc. It is disclosed as AI-generated. The code and write-up are open source (Apache-2.0) at github.com/munimtechnologies/keras-model-scan.