HF Transformers Cross-Repo Remote Code Fetch
Some Hugging Face model repositories load Python code from a second repository referenced inside their config.json. This rule flags cases where that second repository is not the one the model configuration came from, which is a known way to smuggle in and execute unexpected code when a model is loaded.
How the attack works
An application calls from_pretrained() on a model repository (repoA), which downloads its config.json as normal. That config contains a reference — via fields like auto_map or _attn_implementation_internal — pointing to a different repository (repoB) for the actual Python implementation. transformers then fetches and executes that .py file from repoB, a repository the victim never explicitly asked to trust. If, within the same session, a process then runs a tool associated with data exfiltration or persistence, the finding is escalated from suspected to confirmed.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- b7c41f2e-9d38-4a6c-8f15-2e6b9a0d47c3
- Severity
- Critical
Why it matters
Arbitrary Python code from an untrusted repository runs in the context of whatever loaded the model, which can lead to credential theft, persistence, or further compromise of the host running the AI pipeline.
What you can do
- →Set trust_remote_code=False unless you have manually reviewed and pinned the exact repository providing the code.
- →Audit any auto_map or _attn_implementation_internal entries in model config.json files for repository references that differ from the model's own repo.
- →Pin model and code repositories to specific commit hashes rather than tracking branches, and monitor for outbound requests to Hugging Face resolve URLs that don't match the loaded model.
- →If using a self-hosted hub mirror or HF_ENDPOINT proxy, verify that path rewriting does not obscure genuine cross-repository code fetches.
Known benign look-alikes
- Documented cross-repository remote code references ("org/repo--modeling_x.MyClass" in auto_map). Uncommon, and reported only at SUSPECTED tier with no post-exploitation stage attached.
- A repository whose config.json was already cached on disk, so only its *.py module is re-fetched. No config repo is observable, so the rule falls to the DEGRADED tier and requires an egress/persistence spawn in the same session before it reports at all.
- Self-hosted hub mirrors or HF_ENDPOINT proxies that rewrite the path prefix so the config and the code appear to come from different repository ids.
- Build tooling for custom CUDA kernels that shells out during model load; the post-exploitation matcher deliberately excludes compilers/ninja/nvcc and only matches network-egress and persistence utilities.