Originally published at HOL

Unsloth RCE: malicious Hugging Face model config.json injects code

If you fine-tune or serve models with Unsloth and you load weights from Hugging Face (or any path that ships a config.json), a nested model_type string can turn into Python that Unsloth execs. Same-day record CVE-2026-93348 (CVSS 8.6 HIGH, CWE-94) covers Unsloth Zoo >=2025.9.9 and <2026.8.14, as pulled in by Unsloth >=2025.9.9 and <2026.8.20. The maintainer fix is already on PyPI: upgrade unsloth-zoo to 2026.8.14+ and unsloth to 2026.8.20+ (current wheels are newer). This is the operator write-up from the merged Unsloth Zoo patch and the VulnCheck advisory. The HOL Guard evidence pack is at /guard/security/cves/CVE-2026-93348-unsloth-zoo-code-injection-via-modeltype-in.

Who is not in scope

You can ignore this ticket if any of these hold:

• You do not install or import unsloth / unsloth-zoo at all.
• pip show unsloth-zoo reports 2026.8.14 or newer and pip show unsloth reports 2026.8.20 or newer (or you never pin the older train).
• Your training / inference path never calls Unsloth's transformers compile / load helpers that read model_type from a downloaded config (plain transformers without Unsloth is a different stack).

Hugging Face Hub hosting alone is not the bug. The issue is what Unsloth does with a config field after you choose to load that model.

What broke

get_transformers_model_type() in unsloth_zoo/hf_utils.py walked nested model configs and collected model_type after a light normalize that rewrote -, /, and . to _. It did not enforce an [a-z0-9_] allowlist. A newline (or other injection) in a nested model_type inside a malicious model's config.json survived into the string that unsloth_compile_transformers() built for an import, then handed to exec(). The same string also shaped compiled cache filenames via create_new_function.

Merged Unsloth Zoo PR #1083 (follow-up #1108) and the Unsloth bump commit 92ee020 close that path. Credit for the report: Ariel Fogel (afogel) of Pillar Security, per the VulnCheck advisory.

One operator check

pip show unsloth-zoo unsloth | egrep '^(Name|Version):'

Treat any unsloth-zoo below 2026.8.14 or any unsloth below 2026.8.20 (on the affected train starting at 2025.9.9) as vulnerable until upgraded. If those packages are absent, you are out of scope for this CVE.

What this is not

This is not an unauthenticated internet worm and not a Hub-wide remote exploit against every Hugging Face user. CVSS 4.0 marks UI:P: someone (or a pipeline) has to load a malicious model so Unsloth's compile path runs as that user. Impact is still full code execution as the loading account once that happens, which is why the score sits at 8.6 HIGH.

How to fix

pip install -U "unsloth-zoo>=2026.8.14" "unsloth>=2026.8.20"

Or bump the same floors in your lockfile / image and redeploy. Re-run the pip show check above. Prefer pinned known-good model revisions from authors you trust; treat unknown config.json trees like untrusted code when they feed a compile path that used to exec interpolated imports.

What the patch actually changed (so you can sanity-check a backported fork):

• Allowlist model_type with [a-z0-9_]+ immediately after the existing normalize in hf_utils.py (single choke point for Unsloth loaders).
• Replace exec(f"import {model_location}") with importlib.import_module in the compiler path (keeping a deliberate import transformers for downstream eval call sites that still expect that binding).
• Stop string-exec assignment in empty_model.set_additional_modules in favor of a dotted path walk.

PR #1083 reports the allowlist accepts every legitimate model_type shipped in the tested transformers matrices and rejects newline / quote / path-injection style payloads.

References

• VulnCheck advisory: Unsloth Zoo code injection via model_type in config.json
• unsloth-zoo PR #1083 (merged)
• unsloth-zoo PR #1108 (follow-up)
• unsloth bump commit 92ee020