Summary
PEFT's LoRA-GA and CorDA initialization modules use torch.load() without restricting deserialization to safe tensor weights. If a malicious cache or covariance file is supplied through configuration and loaded by the application, an attacker may achieve arbitrary code execution in the process context.
Affected context
The vulnerability occurs in PEFT's LoRA-GA and CorDA initialization paths when configuration points to cache or covariance files that are loaded with unrestricted PyTorch deserialization. It is most relevant to workflows that use shared, downloaded, or otherwise externally sourced LoRA-GA or CorDA artifacts and where those files are trusted without sufficient integrity or provenance checks.
Exploit preconditions
- Attack surface: LoRA-GA or CorDA model initialization and cache-loading logic
- Required access: Ability to place, replace, or cause the application to consume a malicious cache or covariance file
- Trigger point:
torch.load()invoked while initializing the configured adapter - Why exploitation is possible: Without
weights_only=True, PyTorch may deserialize arbitrary pickle objects, allowing code-bearing serialized data to execute during loading
Why this happens
The underlying bug is the use of unrestricted PyTorch serialization for files that may not be fully trusted. torch.load() without weights_only=True relies on general pickle deserialization, which can reconstruct attacker-controlled objects and execute associated behavior during loading. This is a CWE-502: Unsafe Deserialization condition, compounded by inconsistent use of a safer loading wrapper elsewhere in the codebase.
Potential impact
- An attacker may execute arbitrary code within the PEFT process context
- The affected workload could be modified, disrupted, or used to access available data
- Model artifacts, credentials, or environment variables may be exposed
- Compromised loading infrastructure could facilitate broader supply-chain or pipeline abuse
General mitigation guidance
Mitigation generally focuses on ensuring that model-related artifacts are treated as untrusted input and are parsed using restricted serialization behavior.
Common defensive patterns include:
- Prefer
torch.load()configurations that restrict loading to weights and tensor data, such asweights_only=True, where compatible - Use a centralized safe-loading abstraction consistently across all initialization paths
- Validate artifact provenance, integrity, and expected format before loading
- Reduce trust in user-controlled or shared cache locations and apply appropriate filesystem permissions
- Run model-loading workloads with least privilege and isolate them from sensitive credentials and systems
- Reject unexpected object types through explicit schema and state-dictionary validation
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis rules for
torch.load()calls that omit restricted loading options - Code review checks comparing serialization behavior across related loading paths
- Dependency and policy scans that flag unrestricted pickle-compatible deserialization
- Runtime monitoring for unexpected file reads, child-process creation, or network activity during model initialization
- CI enforcement requiring provenance and integrity metadata for downloaded model and adapter artifacts
Automated code review tools may help detect unsafe loading calls, but findings should be confirmed against the trust boundary and supported PyTorch versions.
