PEFT unsafe cache loading exposes ML pipelines to code execution

At a glance

What this is: Corgea says PEFT’s CorDA and LoRA-GA cache paths can deserialize attacker-controlled artifacts and execute code during ML preprocessing.

Why it matters: AppSec and platform teams need to treat ML cache files as untrusted inputs when training or inference jobs can reach sensitive credentials, datasets, and infrastructure roles.

Context

PEFT cache files are meant to speed up model adaptation, but they also create a trust boundary: if a preprocessing step loads serialized artifacts without strict deserialization controls, the file becomes executable input rather than passive data. In modern ML pipelines, that boundary often spans notebooks, shared object stores, batch jobs, and agent backends, so a small code path can expose a much larger environment.

This issue sits at the intersection of application security and ML platform governance. The question is not only whether a library can load a file, but whether the workflow allows untrusted, reused, or cross-tenant artifacts to reach a privileged Python process with access to tokens, datasets, and cloud credentials.

Key questions

Q: What breaks when ML cache files are loaded with raw torch.load()?

A: The security boundary breaks because the file is no longer treated as inert model data. A raw torch.load() call can deserialize attacker-controlled objects, so a cache or covariance file can become an execution vector inside the training or inference process. The result is code execution in a runtime that often already has secrets, data access, and network reach.

Q: Why does unsafe ML deserialization create a credentials risk, not just a model risk?

A: Because the affected process is usually more privileged than the artifact itself. Training workers, notebooks, and agent backends often have access to cloud roles, API tokens, and internal datasets, so code execution during preprocessing can immediately inherit those privileges. The issue is blast radius, not model quality.

Q: What do security teams get wrong about reusable ML artifacts?

A: They often assume a file labelled as a cache is trustworthy because it speeds up preprocessing. That assumption is fragile in shared environments where artifacts can be copied, downloaded, or reused across users and jobs. Security review should focus on artifact provenance and deserialization policy, not just package versions.

Q: When should teams isolate ML preprocessing from high-value credentials?

A: They should do it whenever a preprocessing job can load artifacts from shared storage, public examples, or prior runs. If an attacker can influence the file path, isolation becomes the difference between a contained issue and a credential-bearing host compromise. Keep secrets out of runtimes that deserialize untrusted artifacts.

Technical breakdown

Why raw torch.load() changes the security boundary

In Python ML stacks, torch.load() is a deserialization primitive, not a safe data parser. If called without an explicit weights_only=True policy, it may reconstruct arbitrary pickled objects, which means the file can carry executable behavior through __reduce__-style gadget chains. That is fundamentally different from loading a plain tensor checkpoint. In this case, the vulnerable PEFT paths treat cache-like preprocessing artifacts as trusted acceleration inputs, so the act of loading the file becomes the execution event. Practical implication: any cache, covariance, or adapter artifact that reaches torch.load() must be treated as code-bearing content until proven otherwise.

Practical implication: Route cache deserialization through a safe-only wrapper and do not let untrusted preprocessing artifacts reach raw torch.load().

How cache reuse becomes a code execution path

LoRA-GA and CorDA use cache files to avoid repeating expensive preprocessing. That design assumes the cache already belongs to the current trusted workflow, but shared notebooks, object storage, and team scratch spaces break that assumption. If the file exists, preprocessing may skip recomputation and immediately deserialize the cached object. At that point, the attacker only needs influence over the artifact path, not the model itself. Practical implication: the danger is not model quality degradation, it is trust transfer from file presence to process execution.

Practical implication: Constrain who can create or reuse preprocessing caches and isolate them to the job that generated them.

Why safer loading helpers matter in ML libraries

The critical control gap here is inconsistency. PEFT already ships a safer helper that defaults to weights_only=True, which shows the project understood the risk and had a pattern for reducing it. The vulnerable CorDA and LoRA-GA code paths simply bypassed that control and called torch.load() directly. That creates a governance problem, not just a coding bug, because one part of the library follows a secure loading standard while adjacent paths do not. Practical implication: review ML libraries for split security behavior, especially where one code path handles trusted checkpoints and another handles reusable artifacts.

Practical implication: Standardise deserialization policy across all model and cache loading paths, not just the obvious checkpoint loaders.

Threat narrative

Attacker objective: The attacker aims to run code inside a privileged ML process and use that foothold to reach secrets, data, or infrastructure access.

1. Entry occurs when an attacker supplies or influences a LoRA-GA cache file or CorDA cache or covariance file that a pipeline later trusts.
2. Credential access happens during deserialization because raw torch.load() can instantiate a malicious pickle payload instead of only loading weights.
3. Impact follows when the training or inference process executes attacker-controlled code with access to credentials, datasets, notebooks, or cloud-linked resources.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ML cache files are becoming privileged execution surfaces. This disclosure is not mainly about PEFT as a library; it is about the broader pattern of treating reusable ML artifacts as harmless data. Once a preprocessing cache can be deserialized with a generic loader, the artifact itself becomes part of the execution chain. For practitioners, that means model-adaptation pipelines need the same trust review applied to code deployment pipelines.

The named failure mode here is unsafe deserialization trust transfer. The problem is not simply that a dangerous function exists, but that the workflow grants trust to a file because it is labelled as a cache or covariance artifact. That assumption fails in shared ML environments, where files can move between users, jobs, and workspaces. The right governance question is who can influence the artifact boundary, not whether the file looks like model data.

Split security behavior inside one library is a governance smell. PEFT already had a safer loading helper, which means the organisation understood that weights-only loading should be explicit. When one path uses that helper and another bypasses it, the control model is no longer coherent. AppSec teams should treat that inconsistency as a review trigger for the whole dependency chain, especially where the same package handles both trusted checkpoints and untrusted caches.

AI platform teams need file provenance controls, not just dependency scanning. A patched package version helps, but the deeper issue is whether any shared cache, downloaded artifact, or notebook output can reach a privileged process. In ML systems, provenance and deserialization policy are identity-adjacent controls because they decide which producer is trusted to influence which runtime. The operational conclusion is to govern artifact lineage as tightly as code provenance.

Model pipelines now inherit the same blast-radius logic as cloud workloads. A compromised preprocessing step is no longer a contained failure if the job can reach cloud credentials, internal datasets, or downstream agent backends. That shifts the control objective from model correctness to execution containment. Practitioners should treat artifact loading, job isolation, and secret scoping as one governance problem, not three separate ones.

From our research library:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Unsafe deserialization is now a platform-governance issue, not just a library bug. ML teams that allow cache reuse across users or workspaces should assume that any artifact path can become an execution path. The control question is whether the runtime can be forced to treat files as data-only, especially when those files are exchanged through shared pipelines and multi-tenant storage.

AI pipeline trust boundaries need the same discipline as software supply chains. A model-adaptation workflow that accepts reused cache files without provenance checks creates hidden entry points for code execution. Teams should align artifact handling with provenance controls, runtime isolation, and least-privilege secret scoping so a single poisoned file does not become a full environment compromise.

PEFT cache trust gap: this pattern shows how quickly a convenience feature becomes a security boundary failure when it bypasses explicit safe-loading policy. In practice, that means AppSec and MLOps teams need one governance model for all serialized ML inputs, not separate assumptions for checkpoints, caches, and covariance files. According to the State of Secrets in AppSec, the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

For practitioners

• Verify every PEFT cache-loading path Inspect any use of CorDA or LoRA-GA preprocessing to confirm whether cache_file or covariance_file can be influenced by users, shared storage, or prior runs. Treat any direct torch.load() call as a security review item until the exact code path is confirmed safe.
• Constrain cache provenance to the generating job Keep preprocessing caches inside the same trusted job or isolated workspace that created them, and do not reuse downloaded or cross-tenant artifacts for model initialization.
• Prefer safe-only deserialization wrappers Use explicit weights_only=True behavior or an equivalent project helper for all model-adjacent loads, including cache, covariance, and adapter artifacts.
• Reduce secrets exposure in ML runtime environments Limit what credentials, tokens, and datasets are mounted into training or notebook processes so a deserialization flaw cannot immediately reach high-value assets.
• Review suspicious artifact handling after exposure If an untrusted file may already have been loaded, rotate reachable secrets, inspect process activity, and preserve the artifact for offline analysis instead of reopening it in place.

Key takeaways

• PEFT cache-loading paths can turn a shared ML artifact into an execution vector when raw deserialization is used.
• The practical impact extends beyond model integrity because training and inference jobs often run with access to secrets, datasets, and cloud credentials.
• The most effective control is explicit safe-loading policy combined with tight artifact provenance and runtime isolation.

Key terms

• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Model artefact provenance: Model artefact provenance is the chain of trust showing where a model file, tokenizer, metadata bundle, or derived package came from and whether it was modified. For autonomous and agentic deployments, provenance must cover the whole package, not just the neural weights.
• Cache Loading Boundary: The cache loading boundary is the point where a system decides whether a stored artifact is treated as trusted operational data or as untrusted input requiring verification. In PEFT-style workflows, that boundary matters because a cache file can be loaded automatically during preprocessing and execution.
• Safe-Only Loading: Safe-only loading is a deserialization policy that limits object reconstruction to the minimum necessary data, usually weights or other constrained structures. It reduces the chance that a serialized file can instantiate arbitrary code paths inside a privileged process.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security decisions that shape runtime risk.