# modelscan Keras `.keras` RCE blindspot — `__lambda__` carrier in a `keras.ops.vectorized_map` (`VectorizedMap`) operation

**Severity:** High (arbitrary code execution; scanner reports a fully clean bill)
**Affected tool:** `modelscan` 0.8.8 — `KerasLambdaDetectScan` (native `.keras` v3 zip). Also applies to the H5 path (`H5LambdaDetectScan`).
**Victim loader:** `keras.models.load_model(path, safe_mode=False)` (keras 3.15.0 / TF 2.21.0) — the documented path for loading Lambda-bearing models.
**Category:** ModelScan scanner-bypass on Keras `.keras`/`.h5` (Model File Formats, in-scope).

## Summary
modelscan flags a Keras model as dangerous only when a **top-level `config.layers[]` entry has `class_name == "Lambda"`**. `keras.ops.vectorized_map(fn, x)` used inside a functional model serializes as a top-level layer entry whose **`class_name` is `"VectorizedMap"`** (a `keras.src.ops.core.Operation`), carrying the attacker's Python callable as a `{"class_name":"__lambda__", ...}` value in its `function` config field. Because the class name is not `"Lambda"`, modelscan never inspects it and returns **`total_issues: 0, errors: [], scanned: [evil]`** — a genuine clean result. At load, `VectorizedMap.from_config` **bare-deserializes** that field (no `module_objects`, so no short-circuit) via `serialization_lib.deserialize_keras_object` → `__lambda__` branch → `python_utils.func_load` → `marshal.loads` → a real `FunctionType`, which `VectorizedMap.call` then **invokes** (`backend.core.vectorized_map(self.function, elements)`) during model build/first inference = **arbitrary code execution**.

## Root cause
- **Scanner gap (both formats):**
  - `modelscan/scanners/keras/scan.py` `_get_keras_operator_names` — only `layer.get("class_name") == "Lambda"` in top-level `config.layers`.
  - `modelscan/scanners/h5/scan.py` `_get_keras_h5_operator_names` — same Lambda-only top-level check.
  - `modelscan/settings.py` — `unsafe_keras_operators = {"Lambda": "MEDIUM"}` only. `"VectorizedMap"` is not listed and sub-fields are never inspected.
- **Exec sink (victim side, keras 3.15.0):**
  - `keras/src/ops/core.py:1163-1167` — `VectorizedMap.from_config`: `config["function"] = serialization_lib.deserialize_keras_object(config["function"])` (**bare**, no `module_objects` → does not short-circuit `__lambda__`).
  - `keras/src/saving/serialization_lib.py:686` — `class_name == "__lambda__"` → `python_utils.func_load(inner_config["value"])`.
  - `keras/src/utils/python_utils.py` `func_load` → `marshal.loads` → `types.FunctionType`.
  - `keras/src/ops/core.py:1139` — `VectorizedMap.call` → `backend.core.vectorized_map(self.function, elements)` **calls** the reconstructed function.

## Distinct from previously-filed Keras/modelscan carriers
- **Not** the `TextVectorization` `standardize`/`split` carrier (different layer, different field).
- **Not** the `"module"`-key legacy→modern deserializer fork on `.h5` activation (this needs **no** injected `"module"` key; `VectorizedMap.from_config` bare-deserializes natively, and the class is not a `Dense`/activation layer).
- **Not** the nested-Functional-submodel real-`Lambda` carrier (there is **no** `Lambda` layer anywhere — `class_name` is `"VectorizedMap"`, a distinct built-in operation).
- **Not** the `training_config`/compile loss/metric blindspot (this is a forward-pass model op firing at build/inference, not a compile-time callable).
- Among all `keras.ops` operations, `VectorizedMap` is the one that both **stores** its function in `get_config` and **bare-deserializes + invokes** it (`Map`/`Scan`/`Cond`/`Switch`/… take functions as call-time args and do not round-trip a stored function through model config).

## Reproduce
Env: `pip install tensorflow keras 'modelscan==0.8.8'`, `KERAS_BACKEND=tensorflow` (Python 3.10–3.12).
```
python build_poc.py          # writes evil_vectorizedmap.keras + control_lambda.keras
modelscan -p evil_vectorizedmap.keras     # -> No issues found! (total_issues: 0, errors: [])
modelscan -p control_lambda.keras         # -> 1 MEDIUM 'Lambda' (control: detection works)
python demo_load.py          # load_model(safe_mode=False) + predict -> /tmp/VMAP_PWN.txt written
```

## Verified output (modelscan 0.8.8, keras 3.15.0, TF 2.21.0)
- **`evil_vectorizedmap.keras`** — modelscan JSON: `total_issues: 0`, `total_issues_by_severity` all 0, `errors: []`, `scanned_files: ["evil_vectorizedmap.keras"]` (see `modelscan_evil_result.json`). Top-level layer `class_name`s are `["InputLayer", "VectorizedMap"]` — no `"Lambda"`.
- **Execution:** `keras.models.load_model("evil_vectorizedmap.keras", safe_mode=False)` fires the payload **during load** (functional trace) and `predict()` completes normally (output shape `(2,3)`); marker `/tmp/VMAP_PWN.txt` = `VMAP_RCE_1000` (real `os.system` / `id -u`).
- **Control 1 (detection works):** `control_lambda.keras` (identical payload wrapped in a real `Lambda`) → modelscan `total_issues: 1`, `MEDIUM`, `"Use of unsafe operator 'Lambda'"` (see `modelscan_control_result.json`).
- **Control 2 (exec gate):** default `load_model(...)` (`safe_mode=True`) raises `ValueError: Requested the deserialization of a Python lambda ...` and the marker is **not** written — payload only fires under the documented `safe_mode=False`.

## Impact
ACE against any pipeline that scans an untrusted `.keras` (or `.h5`) model with modelscan — receiving a clean, 0-issue, file-marked-scanned result — and then loads it via the standard `load_model(safe_mode=False)`. No victim-side custom class and **no `Lambda` layer present**, so it defeats modelscan's "look for Lambda layers" detection model with a benign-looking built-in Keras operation.

## Files
- `build_poc.py` — regenerates both models (payload is benign: writes `/tmp/VMAP_PWN.txt` with `id -u`).
- `evil_vectorizedmap.keras` — malicious model (`class_name` `VectorizedMap`, no `Lambda`).
- `control_lambda.keras` — negative control (same payload as a real `Lambda`; modelscan flags it).
- `demo_load.py` — loads the evil model and triggers the payload.
- `modelscan_evil_result.json` / `modelscan_control_result.json` — captured scanner output.

## Suggested fix
In both Keras scanners, recurse **all** layer/operation entries and normalize sub-fields, flagging any `class_name == "__lambda__"` anywhere in the config (and treat function-carrying operations like `VectorizedMap` as unsafe), rather than matching only a top-level `class_name == "Lambda"`.