ModelScan H5 RCE blindspot — `lambda` carrier in a non-Lambda TextVectorization preprocessing field

Severity: High (arbitrary code execution; scanner false-clean) Affected tool: modelscan (latest, H5LambdaDetectScan) — scanned file is a Keras .h5; victim loader is tf.keras / keras.models.load_model(safe_mode=False) (keras 3.14.1). Category: ModelScan scanner-bypass on .h5/.keras (in-scope, Model File Formats).

Summary

modelscan's HDF5 scanner only treats a layer as dangerous when its class_name == "Lambda". A serialized Python callable ({"class_name":"__lambda__", ...}) planted inside a built-in, non-Lambda TextVectorization layer's standardize or split field is therefore never inspected — modelscan reports 0 issues, 0 skipped, 0 errors (a genuine clean bill). At load time, TextVectorization.from_config deserializes those fields through a path that honors __lambda__ → marshal.loads → arbitrary FunctionType, which is then invoked on the first predict()/adapt() = arbitrary code execution.

Root cause (scanner gap)

modelscan/scanners/h5/scan.py:105-130 (_get_keras_h5_operator_names) iterates only top-level config.layers[] and appends a finding solely when layer.get("class_name") == "Lambda".
modelscan/settings.py:43-45 → unsafe_keras_operators = {"Lambda": "MEDIUM"} only. Every other class and every config sub-field is ignored.

Exec sink (victim side, keras 3.14.1)

keras/src/layers/preprocessing/text_vectorization.py:491-505 — from_config calls bare serialization_lib.deserialize_keras_object(config["standardize"]) / (config["split"]) with no module_objects.
keras/src/saving/serialization_lib.py:660-670 — routes class_name == "__lambda__" to python_utils.func_load when safe_mode=False.
keras/src/utils/python_utils.py:54-100 — func_load → marshal.loads → FunctionType.
text_vectorization.py:541-542 / :566-567 — _preprocess does if callable(self._standardize): inputs = self._standardize(inputs) (same for split) → executes attacker bytecode.

Why this field and not the obvious ones: planting the same __lambda__ carrier in activation/constraint/initializer/regularizer does not work — those route through module_objects deserializers that short-circuit and return the bare class_name string. The TextVectorization.from_config path is distinct precisely because it calls deserialize_keras_object directly. (Control verified in the PoC: a Dense.activation carrier did not fire.)

Reproduce

python poc/poc_final.py (env: tensorflow 2.21.0, keras 3.14.1, h5py, modelscan). Builds evil_standardize.h5 and evil_split.h5 (6472 bytes each). For both:

[A1] ModelScan().scan() → 0 issues / 0 skipped / 0 errors (scanner blind, file recorded as scanned).
[A2] keras.models.load_model(path, safe_mode=False) then model(tf.constant(["hello world"])) → marker file written with real exfil (uid/host). With a vocabulary shipped in the config, predict() completes silently while the payload fires.

Impact

ACE on anyone who scans a malicious .h5 with modelscan (gets a clean result) and then loads + runs it via the standard load_model(safe_mode=False) + predict(). Defeats modelscan's core promise for a built-in layer with no victim-side custom class; two independent carrier fields (standardize, split). safe_mode=False is the standard/documented path for legacy .h5 (and Keras ignores safe_mode for .h5 per CVE-2025-1550/9905 anyway).

Dup-check

Clean. The dev.to "29 ways" article's only Keras/H5 bypass is Lambda-in-TimeDistributed (structurally different). modelscan docs describe H5 detection as "look for lambda layer" (Lambda-only). The Keras safe_mode-on-h5 CVEs are a different component (Keras honoring Lambda exec, not the scanner) and use actual Lambda layers. Distinct from our prior R1 h5 activation-field lambda (that field short-circuits via module_objects) and R2 modelscan H5 training_config blindspot (different sink). No public source ties a non-Lambda preprocessing-layer __lambda__ carrier to a modelscan H5 miss.

ModelScan H5 RCE blindspot — __lambda__ carrier in a non-Lambda TextVectorization preprocessing field