Summary
A code injection vulnerability in Unsloth's model-loading compile path allows Python source embedded in a model configuration to reach a dynamically executed statement.
When a malicious model is loaded for training or inference, an attacker may achieve remote code execution with the permissions of the loading process.
Affected context
The issue occurs in Unsloth Zoo and related Unsloth model-loading workflows that derive generated import content from nested model_type values in a model's config.json. It becomes risky when an untrusted or tampered model is loaded and the configuration value is normalized without restricting control characters or validating it against an expected set of model types.
Exploit preconditions
- Attack surface: Model-loading and transformer compilation code
- Required access: Ability to supply or influence a model repository, artifact, or local model directory that will be loaded
- Trigger point: Loading the model for training or inference through the compile path
- Why exploitation is possible: A nested
model_typevalue can contain a newline and additional Python source that survives normalization and is incorporated into code executed byexec()
Why this happens
The vulnerability results from treating configuration-derived model metadata as trusted source-code content. The get_transformers_model_type() function collects nested model_type values without enforcing a strict character allowlist or validating the result as a known identifier, allowing line-breaking characters and arbitrary source text to reach generated Python code.
This maps to CWE-94: Improper Control of Generation of Code ('Code Injection'), because data from a model configuration influences dynamically generated code that is subsequently executed.
Potential impact
- An attacker may execute arbitrary Python code in the model-loading process
- The loading user's credentials, files, or environment may be exposed
- Training data, model artifacts, or checkpoints could be modified or exfiltrated
- A compromised worker may be used for lateral movement or supply-chain abuse
General mitigation guidance
Mitigation generally focuses on ensuring that model metadata remains data rather than executable source.
Common defensive patterns include:
- Treating model configuration files and repositories as untrusted input
- Validating
model_typevalues against a strict allowlist of expected identifiers - Rejecting control characters, line breaks, and unexpected syntax before code generation
- Avoiding dynamic code generation and
exec()for selecting model behavior - Using explicit dispatch tables or safe object mappings instead of interpolated Python source
- Loading models with least-privilege identities, restricted filesystem access, and limited network permissions
- Isolating untrusted model processing in sandboxed workers where practical
How teams detect issues like this
Organizations can detect similar weaknesses through:
- Static analysis rules identifying
exec(), dynamic imports, and string-built Python statements - Searches for configuration values interpolated into source code or command-like execution paths
- Code review checks requiring allowlists for identifiers derived from model metadata
- Tests using newlines, control characters, quotes, and unexpected Unicode in configuration fields
- Repository and artifact policies that verify model provenance and inspect configuration files before loading
- Automated security review tools that flag unsafe code-generation and execution patterns
