LUOYE-LLM/modelscan-keras-nested-lambda-bypass-poc

ModelScan .keras nested Lambda scanner gap PoC

This repository demonstrates a scanner coverage gap in ModelScan's .keras Lambda detection.

Two Keras v3 files are included:

• flat_lambda.keras: a control model with a top-level Lambda layer.
• nested_lambda.keras: a model where the Lambda layer is inside a nested Sequential layer.

Keras treats both files as having the same Lambda deserialization risk boundary:

keras.models.load_model(path, safe_mode=True)  -> blocks both files
keras.models.load_model(path, safe_mode=False) -> loads both files

ModelScan detects the flat control but misses the nested Lambda because its .keras scanner only checks top-level config.layers in config.json.

Expected ModelScan behavior with modelscan==0.8.8 and TensorFlow installed:

flat_lambda.keras   -> 1 MEDIUM issue, KerasLambdaDetectScan
nested_lambda.keras -> 0 issues

Reproduce

Recommended full scanner-reproduction environment:

python3.12 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
python reproduce.py

modelscan==0.8.8 is currently the scanner version under test. It may not install on newer Python versions such as Python 3.13. If ModelScan is not available for the current interpreter, the script still prints the Keras loader parity and config structure, then reports that native ModelScan scanning was unavailable.

For local verification with a vendored ModelScan 0.8.8 source tree, set:

MODEL_SCAN_LIB=/path/to/modelscan_lib python reproduce.py

The expected scanner differential is:

flat_lambda.keras   -> modelscan_total_issues=1
nested_lambda.keras -> modelscan_total_issues=0

Scope

This is a scanner coverage / scanner bypass issue. It is not claiming default-path arbitrary code execution in modern Keras. Modern Keras blocks Python lambda deserialization by default unless unsafe deserialization is explicitly enabled.