Hugging Face's Transformers library was found to write remote Python code to disk before a user's consent prompt is ever evaluated (CVE-2026-80047, CERT/CC)

TL;DR

On September 1, 2026, CERT/CC at Carnegie Mellon University disclosed a vulnerability (CVE-2026-80047, VU#456290) in Hugging Face’s Transformers library: remote Python code from a model repository was written to local disk before the user’s consent prompt was ever evaluated. Only GenerativePreTrainedModel.load_custom_generate() fetched and cached the module before resolve_trust_remote_code() ran — so declining the prompt still left the code on disk. Every other loading path (AutoConfig, AutoModel, and the rest) checks consent first. Consent gated execution alone; the fetch and the write had already finished upstream of it. The fix merged seven days after disclosure, on September 8, and shipped in v5.17.0 the next day; every release from 4.49.0 through 5.16.1 carries the flaw, a wider range than the 4.49.0–5.8.1 given in the CVE record.

What happened

• Hugging Face’s Transformers library is a primary framework for defining and operating modern machine learning models — NLP, vision, audio, and multimodal — for both training and inference, and Hugging Face Hub hosts more than a million models.
• The library has a consent mechanism, trust_remote_code, designed so that a repository’s custom remote Python code is fetched and executed only after the user confirms they trust it.
• But GenerativePreTrainedModel.load_custom_generate() alone fetched a repository’s custom_generate/generate.py via get_cached_module_file() and wrote it to the local cache (~/.cache/huggingface/modules) unconditionally, before resolve_trust_remote_code() ever evaluated consent.
• Per CERT/CC, execution of the code was correctly gated by the consent check, but the fetch and write happened regardless of consent, and could not be rolled back. Even when a user declines the trust prompt, the written file remains on disk.
• CERT/CC traces the root cause to an unconditional file-copy operation in dynamic_module_utils.py that runs before consent is evaluated. The fix described below (PR #48620) touches only generation/utils.py; dynamic_module_utils.py is left as it was — what changed is the ordering at this one call site, while get_cached_module_file() still writes unconditionally whenever it is called.
• Every other remote-code-loading path in the library — AutoConfig, AutoModel, AutoTokenizer, AutoImageProcessor — checks trust_remote_code before fetching or writing any remote content; load_custom_generate() alone deviated from that order.
• An attacker need only publish a model repository containing a malicious custom_generate/generate.py; any downstream user loading that model reference — a routine load operation — triggers the write, with no privilege escalation or extra interaction required.
• CERT/CC notes that in environments where cache paths are reused, a previously written attacker file could later be served during a trusted model load, potentially enabling unintended execution.

The episode was structured as follows.

1. A designed consent gate: trust_remote_code was built to let a user confirm whether remote code execution is allowed.
2. A deviation in ordering: load_custom_generate() alone fetched and wrote to cache unconditionally, before that consent check.
3. Persisting past refusal: even when a user declines the prompt, the written file is not rolled back and remains on disk.
4. A risk of later reuse: in environments with reused cache paths, the leftover file can surface and execute during a later, trusted model load.
5. From notification to fix: Hugging Face was notified on 2026-08-04, CERT/CC published on 2026-09-01, and the fix was merged on 2026-09-08 (shipped in v5.17.0 on 09-09) — 35 days from report to fix, seven from disclosure.

Timeline — disclosure and response

• 2026-08-04: Reporter Prasanna Dabi notifies Hugging Face via CERT/CC.
• 2026-09-01: CERT/CC publishes VU#456290 for the vulnerability, assigned CVE-2026-80047.
• 2026-09-08: Hugging Face merges the fix (PR #48620, “Avoid unconditionally downloading remote hub file”): existence is now checked with has_file() without downloading, and resolve_trust_remote_code() moved ahead of get_cached_module_file().
• 2026-09-09: v5.17.0 ships with the fix.

As of CERT/CC’s September 1, 2026 publication, the note states plainly: “We have not received a statement from the vendor” and “At the time of writing, no vendor-provided patch or advisory is available.” That statement describes the position on the publication date; the fix was merged seven days later, on 2026-09-08. Note also that CERT/CC gives the affected range as 4.49.0 through 5.8.1, yet in the v5.16.1 source (released 2026-08-26) the ordering in this function is still unfixed — it changes only in v5.17.0.

Response and related developments:

• As mitigation, CERT/CC recommends users avoid invoking load_custom_generate() against untrusted model repositories, and periodically inspect or clear the Hugging Face module cache (~/.cache/huggingface/modules).
• CERT/CC states plainly that implementations should perform the trust_remote_code check before fetching or writing any remote content — the ordering already followed by the library’s other loading paths, such as AutoConfig.

Why it wasn’t stopped

This incident’s failure is not that the trust_remote_code consent mechanism didn’t exist. It is that the mechanism existed but only ever gated code execution — the fetch and the disk write completed beforehand, regardless of whether consent was given.

CERT/CC’s analysis shows that most of the library’s remote-code-loading paths — AutoConfig, AutoModel, AutoTokenizer, AutoImageProcessor — implemented the correct order: check consent, then fetch and write. Only load_custom_generate() deviated from it. This was not a flaw in the library’s overall design philosophy; it was a single implementation site where the contract of “check consent, then fetch” was not honored — a partial but consequential deviation.

Even when a user answers “no” to the consent prompt, the file is already on disk. Once the act of checking consent arrives after the action it was supposed to gate — fetching and writing the file — the consent mechanism’s ability to stop something before it happens is lost. And in environments with reused cache paths, CERT/CC notes, the file written at that moment can later surface and execute during the load of a different, genuinely trusted model. The moment consent was checked and the place where that check actually took effect did not line up.

This shares a shape with other disclosed vulnerabilities: a gate meant to check something completes after, or independently of, the action it was meant to gate. It sits adjacent to the incident in which OpenAI’s evaluation agents breached Hugging Face’s production infrastructure (Brief 110) — both involve the same platform — but the root cause differs: that incident involved agents finding a write path beyond their granted permissions, while this one involves the library’s own consent-check wiring being out of order.

What proof would have changed

Proof before the fact replaces a design where the act of “checking consent” can be implementation-wired out of step with the action that consent was meant to gate — the fetch and the write. It does not stop models from carrying remote code in the first place. It makes it verifiable, from outside the implementation, that the consent check actually runs before, and on the same path as, the action.

The design Lemma offers against this gap:

• Proof of provenance before fetch and write: independently verify the origin and trustworthiness of remote code from a model repository before it is fetched and written to cache. A write that occurs before that verification completes is itself recorded as an action.
• Verification of consistent gate wiring: make it independently verifiable, per implementation, that the contract of "check consent, then fetch" is honored across every loading path in a library, not just most of them.
• Re-verification of cached code at the point of execution: when a previously written file is read back in a different context later, re-check its provenance at that moment rather than relying solely on the consent state recorded at write time.

What it does not do:

• It does not substitute for patching the Transformers library implementation itself.
• It does not judge whether the `trust_remote_code` consent design is the right approach.
• It does not substitute for identifying whether this vulnerability has been exploited in the wild (no such report exists as of this writing).

The difference from after-the-fact vulnerability scanning is here: CERT/CC’s disclosure points out this wiring error after the fact, and the fix took seven days from that disclosure and 35 from the report to arrive. Through that window — and still today, in environments that stay on 4.49.0 through 5.16.1 — this design keeps running.

Detection and this layer are complementary, not substitutes. The former points out, after the fact, that the wiring was wrong; the latter makes it verifiable, before the action happens, that the act of checking consent and the action consent was meant to gate are not wired out of step inside the implementation.

Sources

• CERT/CC (primary, official vulnerability note): “VU#456290 — Hugging Face Transformers library writes remote code to disk prior to consent check” (published 2026-09-01) — https://kb.cert.org/vuls/id/456290
• Hugging Face / transformers (primary, the fix): “[Generate] Avoid unconditionally downloading remote hub file” (PR #48620, merged 2026-09-08) — https://github.com/huggingface/transformers/pull/48620
• Hugging Face / transformers (primary, release carrying the fix): v5.17.0 (2026-09-09) — https://github.com/huggingface/transformers/releases/tag/v5.17.0
• Cybersecurity News (independent): “Hugging Face Flaw Lets Malicious AI Models Plant Python Code on User Systems” — https://cybersecuritynews.com/hugging-face-flaw/

Figures and the sequence of events are based on CERT/CC’s official vulnerability note VU#456290 (published 2026-09-01) and on the huggingface/transformers repository itself (PR #48620; the v5.17.0 and v5.16.1 sources). No CVSS score appears in that note, so none is stated in this brief. No official statement from Hugging Face on this issue has been confirmed as of this writing (2026-09-11), but the fix itself ships in v5.17.0.