# Hugging Face Transformers CVE-2026-80047: Malicious Models Write Python to Disk Before You Click “Trust”

> CERT/CC VU#456290 (Sep 1, 2026): a flaw in Hugging Face Transformers 4.49.0–5.8.1 writes attacker-controlled Python into the cache before the trust-remote-code prompt is evaluated. How the consent-bypass works, who is exposed, and the mitigations.

Source: https://playciso.com/blog/hugging-face-transformers-cve-2026-80047-consent-bypass · Published: 2026-09-01 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://kb.cert.org/vuls/id/456290

---

A newly disclosed flaw in **Hugging Face Transformers** — the most widely used library for running open models — lets a malicious model repository **plant attacker-controlled Python on your disk before you ever click "trust."** Tracked as **CVE-2026-80047** and documented by the CERT Coordination Center as [VU#456290](https://kb.cert.org/vuls/id/456290) on 1 September 2026, it turns the safety prompt everyone relies on into theatre. Load model → fetch remote generate.py → ✍ written to ~/.cache (already on disk) → "Trust remote code?" prompt ## What happened Researcher Prasanna Dabi reported, and CERT/CC published on September 1, a flaw affecting **Hugging Face Transformers versions 4.49.0 through 5.8.1**. The library's `load_custom_generate()` path fetches and caches a remote Python module via `get_cached_module_file()` _before_ it evaluates user consent in `resolve_trust_remote_code()`. Execution of the module is correctly gated behind the prompt — but the **file write is not**. The attacker's `custom_generate/generate.py` lands in `~/.cache/huggingface/modules` whether you approve the trust prompt or decline it. ## Why "I clicked Decline" is not enough The whole mental model of "trust remote code" is that nothing dangerous happens until you say yes. This flaw breaks that assumption: simply _loading_ a model reference is enough to drop a file on disk. On its own an unexecuted file is inert — but combined with any second bug that runs cached modules, a scheduled job that sweeps the cache, or a developer who later runs the wrong thing, a planted file becomes a foothold. It is the classic write-primitive-plus-later-execution pattern, and it fires **before the one control users depend on ever appears.** ## Who is exposed Transformers is embedded almost everywhere models are run: developer laptops, cloud notebooks, CI pipelines, and production inference. Any of those that load models from untrusted or attacker-influenceable repositories are in scope. This is also a textbook **AI supply-chain** exposure — the risk lives in a model repository, not in your own code, which is precisely the kind of dependency a traditional scan never sees. ## What to do now - Do not call load_custom_generate() against untrusted repositories. Until a vendor patch ships, that is the operative mitigation from CERT/CC. - Inspect and clear the module cache. Periodically review ~/.cache/huggingface/modules and remove unexpected files across workstations, notebooks and pipelines. - Pin and vet model sources. Treat model repositories as dependencies with provenance, not as trusted content. An AI Bill of Materials inventories exactly which models and versions you pull, and a behavioural model audit checks the model itself. - Know the pattern. This is OWASP LLM supply-chain territory — the LLM Security (OWASP) checklist maps the model-provenance failure modes CVE-2026-80047 sits in. ## Sources - CERT/CC — VU#456290: Hugging Face Transformers writes remote code to disk prior to consent check - Cybersecurity News — Hugging Face Flaw Lets Malicious AI Models Plant Python Code - GBHackers — Transformers Flaw Writes Malicious Python Before User Consent **Own your model supply chain.** Generate a free [AI Bill of Materials](/tools/aibom) to inventory every model and dataset you depend on, run a [model behavioural audit](/tools/modelaudit), and check yourself against the [OWASP LLM Top 10](/tools/llm-security). No signup.