---

archetype: ml-model-loaders

headline: true

primary_gate_families: [1, 7]

---

# Archetype - ML Model Loaders & Inference Runtimes (HEADLINE)

**This is the highest-yield archetype for Cyclops v2.** The thesis: model files are *executable

attack surface masquerading as data*. The entire ML ecosystem ships parsers and deserializers that

run at **load time**, before any inference, often in C/C++ with weak bounds checking, written fast,

shipped weekly, and consumed by millions who treat a downloaded `.gguf` / `.safetensors` / `.pt` /

`.onnx` as inert. It is not inert. A model is a program.

Two distinct kill-chain classes live here and you must hunt both:

- **(A) Deserialization-as-design** - formats that *intentionally* execute code (pickle, joblib,

  arbitrary Python in custom nodes). The bug is the trust, not a memory error.

- **(B) Parser memory-corruption** - formats that *claim* to be safe data (GGUF, safetensors, ONNX

  protobuf, NPY) but whose C/C++ parsers have OOB read/write, integer overflow, type confusion. The

  bug is in the loader, and the oracle is ASan.

See: [[../00-doctrine/SEVERITY-GATE#family-1-remote-code-execution-the-crown|Gate Family 1]] ·

[[memory-unsafe-parsers]] (sister archetype for the pure-parser fuzzing mechanics) ·

[[ai-agent-mcp]] (model loaders reached *over the network* via inference servers).

---

## Principals & trust boundaries

- **Principals:** the model *author/publisher* (untrusted - anyone on HuggingFace Hub, Civitai, an

  npm/PyPI package, a torrent), the *runtime/library* (the thing parsing the file), the *host user*

  (whose process and credentials the load runs as).

- **The core trust boundary:** *"downloaded model file → load function"*. Every user who does

  `from_pretrained(...)`, `llama_load_model_from_file(...)`, `onnxruntime.InferenceSession(...)`,

  `torch.load(...)`, `joblib.load(...)`, `comfyui` "drag this workflow in" - crosses it.

- **Why it's so wide:** model sharing is the *entire culture* of the field. The file is meant to be

  passed around. The trust boundary is crossed billions of times a day and almost no consumer thinks

  of the file as code.

**Boundary map (fill this per target):**

```

principals:        [model publisher (untrusted)] → [loader lib] → [host process / user creds]

trust inputs:      .gguf | .safetensors | .pt/.pth | .onnx | .npy/.npz | .pkl | .joblib |

                   .bin (HF) | workflow.json (ComfyUI) | model_index.json | tokenizer.json |

                   config.json | *.gradio cache | adapter_config.json (PEFT/LoRA)

enforcement pts:   header magic check, version gate, "weights_only" flag, allowlist of globals,

                   tensor-count/dim sanity checks, mmap bounds, protobuf size limits

cross-boundary

sinks:             pickle.Unpickler.find_class / __reduce__ ; numpy buffer parse ;

                   memcpy/alloca from file-controlled length ; ggml tensor dim multiply ;

                   protobuf arena alloc ; eval/exec in custom node ; os.system in workflow

confusion

hypotheses:        "weights_only=True is actually bypassable here"; "the header length field is

                   trusted before the file size is checked"; "n_dims * n_elements overflows size_t";

                   "the allowlist misses one __reduce__-able global"; "the safe format has an

                   unsafe metadata side-channel"

```

---

## Kill chains (each lands on a Gate family)

### KC-1 - Pickle / `__reduce__` deserialization → RCE (Class A)

The classic and *still* live. `pickle` calls `__reduce__` on unpickling, which can return

`(os.system, ('id',))`. PyTorch `.pt`/`.pth` are zip files containing a pickle. `joblib`/sklearn

`.pkl`, many HF `.bin` legacy weights, are pickles.

- **Sinks:** `pickle.load`, `pickle.Unpickler.find_class`, `torch.load(..., weights_only=False)`,

  `joblib.load`, `numpy.load(..., allow_pickle=True)`, `dill.load`, `cloudpickle.load`.

- **The fresh angle (novelty, not sibling-CVE):** everyone knows raw pickle is dangerous. The novel

  bugs are in the **allowlist bypasses** of the "safe" loaders: `weights_only=True` (PyTorch's

  defense) has had repeated bypasses (e.g. via allowed globals that themselves reach dangerous

  reductions; via `torch.storage` / rebuild functions; via nested types the allowlist forgot). Hunt

  the *allowlist*, the `_get_allowed_globals` table, the `GLOBAL`/`REDUCE` opcode handling - find one

  reachable dangerous global the allowlist trusts.

- **Oracle:** loading the crafted model fires a callback / writes `/tmp/cyclops-$RAND` → Family 1.

- **CVE class to cite & avoid duplicating:** CVE-2025-class PyTorch `weights_only` bypasses,

  `numpy.load` allow_pickle RCE, the perennial sklearn/joblib pickle RCE. Check the feed first.

### KC-2 - GGUF / GGML parser memory-corruption → RCE (Class B) *(prime hunting ground)*

`llama.cpp` and everything built on it (Ollama, LM Studio, text-generation-webui, countless wrappers)

parse GGUF with hand-written C. The format has a header → metadata KV array → tensor-info array →

tensor data, all with **file-controlled length and count fields**.

- **Sinks to CPG-trace:** `gguf_init_from_file`, `gguf_read_emplace`, the KV-pair reader

  (`gguf_kv` / `gguf_get_arr_*`), `ggml_new_tensor`, `ggml_nbytes`, `ggml_row_size`, and every

  `malloc`/`GGML_MALLOC`/`memcpy` whose size derives from a file field.

- **Bug shapes:** integer overflow in `n_dims * ne[i] * type_size` → undersized alloc → heap

  overflow on tensor copy; an array `n` count read before validating it against remaining file size →

  OOB read; a metadata string length field trusted into a `memcpy`/`malloc`; type/enum confusion in

  `ggml_type` indexing a per-type size table OOB.

- **Oracle:** build `llama.cpp` (or the wrapper) with `-fsanitize=address`, feed the crafted `.gguf`,

  get the ASan report with a controlled fault → Family 1 (SOURCE/REPLICA). Escalate to control of

  RIP/allocations for the full RCE claim.

- **CVE class:** the GGUF heap-overflow / OOB family (multiple 2024 llama.cpp advisories). Novelty =

  a *different* field or a wrapper that re-implemented the parse and reintroduced the class.

### KC-3 - safetensors metadata / header parse (Class B, the "safe format" trap)

`safetensors` was designed to *be the safe alternative* to pickle - no code execution by design. That

makes it the perfect place for a novel bug, because everyone assumes it can't have one.

- **Surface:** the 8-byte little-endian header length, then a JSON header describing each tensor's

  `dtype`, `shape`, and **byte offsets** `[begin, end]` into the buffer. The Rust core is memory-safe,

  but: (a) the **offset/shape arithmetic** - does `begin..end` get validated against the buffer and

  against `shape × dtype_size`? An offset overflow or a mismatch can yield OOB; (b) **language ports** -

  C++/Zig/Go re-implementations and the C ABI consumers don't get Rust's guarantees; (c) the JSON

  metadata fed to a *downstream* consumer that does something unsafe with it.

- **Sinks:** `SafeTensors::deserialize`, the offset-validation routine, and any C/C++ reimpl's

  `memcpy(dst, base+begin, end-begin)`.

- **Oracle:** ASan crash on a port, or a proven OOB read returning out-of-tensor bytes.

### KC-4 - ONNX / protobuf model graph → parse corruption or operator abuse (Class B)

ONNX Runtime parses a protobuf graph then *builds and runs operators*. Two sub-surfaces:

- **Protobuf/loader corruption:** `onnx::ModelProto` parse, external-data references (an ONNX model

  can point at an *external* data file path - path traversal / arbitrary file read sink), and the

  shape-inference pass (`onnxruntime::...ShapeInference`) doing arithmetic on attacker dims.

- **Operator-level:** custom ops, the `Scan`/`If`/`Loop` control-flow ops, and ops that allocate from

  attacker-controlled dims. ORT has a real history of heap overflows in op kernels.

- **External-data trap (Family 7):** the `external_data` location field can be a path → arbitrary

  file read at load. Cite the ONNX external-tensor path-traversal class.

- **Sinks:** `onnxruntime::Model::Load`, `LoadExternalTensor`, op `Compute()` kernels with dim-derived

  allocs. **Oracle:** ASan crash, or the external-data path reading our canary file → Family 7.

### KC-5 - ComfyUI custom nodes / workflow.json → RCE (Class A, social)

ComfyUI workflows are shared as JSON/PNG-embedded graphs that reference **custom nodes** (arbitrary

Python packages auto-installed from a registry). "Load this cool workflow" → pulls a custom node →

runs its `__init__` / node code.

- **Sinks:** the custom-node loader (`nodes.py` import path), any node calling `eval`/`exec`/

  `subprocess`/`os.system` on workflow-supplied strings, the model-manager auto-download.

- **This is also a [[cicd-supplychain|supply-chain]] / [[ai-agent-mcp|agent]] surface** - rotate the lens.

- **Oracle:** importing/running the malicious workflow fires a callback → Family 1.

### KC-6 - Gradio / model-server file & SSRF surface (Family 7, bridges to [[ai-agent-mcp]])

Gradio (the demo UI under most HF Spaces and local model demos) has a history of path traversal

(`/file=` arbitrary file read) and SSRF in the proxy/`/queue` paths.

- **Sinks:** the `/file=` route's path resolution, the URL-fetch in upload/proxy handlers.

- **Oracle:** read our canary secret via `/file=` (Family 7) or land SSRF→metadata.

- **CVE class:** Gradio `/file=` traversal (CVE-2023/2024 class), Gradio SSRF. Find the *new* route.

### KC-7 - Tokenizer / config side-channels (Class A/B, the overlooked input)

Even with "safe" weights, the *accompanying* files load too: `tokenizer.json`,

`tokenizer_config.json`, `config.json`, `generation_config.json`, `chat_template` (a **Jinja2

template** → SSTI sink!), `adapter_config.json` for PEFT/LoRA. The `chat_template` Jinja2 is a real

[[../00-doctrine/SEVERITY-GATE#family-1-remote-code-execution-the-crown|SSTI→RCE]] surface - HF added

a sandbox; hunt the sandbox bypass.

- **Sinks:** `jinja2.Environment` rendering the chat template, any `eval`-ish config parse, the

  `trust_remote_code=True` path (which literally imports model-repo Python - a known but still-fertile

  RCE: hunt where `trust_remote_code` defaults true or is reachable without the flag).

- **Oracle:** template/remote-code executes → Family 1.

---

## The dynamic oracle, concretely (this archetype's whole point)

For **Class B (parser memory-corruption)** the pipeline is:

1. `git clone` the freshest in-scope loader. Pin the commit.

2. Build with `-fsanitize=address,undefined` (or use the project's fuzz harness if present -

   `llama.cpp` ships `tests/`, ORT has fuzzers, many have OSS-Fuzz targets you can *re-run on new code*).

3. Write a libFuzzer/AFL++ harness whose entry is the **load function** (`gguf_init_from_file`,

   `safetensors deserialize`, `Model::Load`). Seed with a real valid model, mutate.

4. Run; collect crashes; **`triage_crash`** to confirm a *controlled* fault (write to attacker data,

   PC control, OOB on heap with our pattern). A null-deref / pure read-DoS is **DISPROVEN for RCE**

   per [[../00-doctrine/SEVERITY-GATE#family-6-mass-data-exfil-financial-impact|the gate]] - log it,

   do not dress a DoS as critical.

5. Minimize the crashing model file; that file *is* the REPLICA_CONFIRMED artifact.

For **Class A (deserialization)** the oracle is direct: craft the malicious model, load it in a

disposable container, observe the callback/file-write. No fuzzing needed - the proof is the popped

shell.

Relevant tooling in the kit: ASan/UBSan builds, libFuzzer/AFL++/`boofuzz`, `joern_query` &

`codeql_query` for the source→sink path, `triage_crash`, a disposable `sandbox_create` to detonate

Class-A models, `start_callback_server` for the RCE callback.

---

## BORING traps - do NOT spend time here

- **"`torch.load` runs arbitrary pickle."** Known since forever. Reporting raw-pickle RCE against a

  tool that *documents* "only load models you trust" is a non-finding. The finding is the

  **safe-path bypass** (`weights_only=True` defeated, allowlist escaped, a "safe" format corrupted).

- **Null-deref / assertion-abort / pure read-DoS in a parser.** Not RCE. Cleared-axes hardening note.

- **"This model could be malicious."** Of course it could. That is the threat model, not a bug. The

  bug is a *specific* loader flaw with an *artifact*.

- **Re-finding a public llama.cpp/ORT CVE in an old checkout.** Sibling-CVE. Hunt code days old.

- **Out-of-memory from a huge dim field.** Resource exhaustion ≠ corruption. Verify it's actually an

  OOB write before getting excited.

- **Gradio version banner / "old Gradio".** Version-based "findings" are not findings; prove the route.

---

## Where the novel bugs actually are (steer here)

1. **Allowlist / safe-mode bypasses** in the *defenses* (`weights_only`, find_class allowlists, the

   chat-template sandbox, safetensors offset validation). The defense is newer code than the format.

2. **Re-implementations** - a Go/C++/Zig/Rust-C-ABI port of a "safe" format that dropped a check.

3. **Integer arithmetic on attacker dims** - `n0*n1*n2*type_size` overflow before alloc. Grep/CPG for

   every multiply feeding a `malloc`/`memcpy` in `ggml`, ORT kernels, NPY/`safetensors` consumers.

4. **External-reference fields** - ONNX `external_data` path, GGUF embedded paths, anything where the

   model file names *another* file/URL → traversal / SSRF (Family 7).

5. **The accompanying files** - tokenizer/chat-template/config that load alongside "safe" weights and

   reach Jinja2/`trust_remote_code`/eval.

6. **Freshly-merged format extensions** - a new GGUF KV type, a new ONNX opset, a new quant format

   landed last week. New parse code = unfuzzed code. See [[../06-methods/NOVELTY-DOCTRINE]].