Originally published at HOL
CVE-2026-69112: Hugging Face Accelerate Path Traversal Lets Attackers Read Arbitrary Files from Checkpoint Indexes
TL;DR: Hugging Face Accelerate through version 1.14.0 fails to sanitize weight_map entries in sharded checkpoint indexes. An attacker who controls a checkpoint index file can supply relative paths with parent-directory traversal sequences or absolute paths to read arbitrary files from the filesystem, or point shard entries at named pipes to cause indefinite blocking and denial of service. The vulnerability affects the load_checkpoint_in_model and load_checkpoint_and_dispatch functions.
What happened
The attack chain starts with a sharded model checkpoint. Hugging Face Accelerate uses index files (typically model.safetensors.index.json or pytorch_model.bin.index.json) to map weight tensor names to the shard files that contain them. The weight_map inside these index files is a dictionary where each key is a tensor name and each value is the filename of the shard holding that tensor.
The problem: Accelerate passes those filenames directly to file open calls without validating them. No canonicalization. No bounds checking. No restriction to the checkpoint directory. A malicious weight_map can point tensor_name at ../../../../etc/passwd and Accelerate will open it. The file contents get loaded as if they were tensor weights. An attacker who can place or modify a checkpoint index file gains arbitrary file read on the host running the model loading code.
The second attack vector uses named pipes (FIFOs). Linux treats named pipes as special files that block on open until a writer connects. If an attacker sets a weight_map entry to a named pipe path, the loading process hangs indefinitely waiting for data. This is a denial-of-service vector that requires no privilege escalation, just the ability to influence the checkpoint index.
Both load_checkpoint_in_model and load_checkpoint_and_dispatch are affected. These are the two primary entry points for loading sharded checkpoints in Accelerate. If your code calls either function with a checkpoint loaded from an untrusted source, you are vulnerable.
Who is affected
Hugging Face Accelerate is a distributed training and inference library that sits between PyTorch and Hugging Face Transformers. It handles multi-GPU training, mixed precision, and model sharding across devices. The package sees roughly 27 million downloads per month on PyPI, with nearly 1 million downloads per day. It is a core dependency in thousands of ML pipelines, from research notebooks to production inference servers.
All versions through 1.14.0 are vulnerable. The affected package installs as accelerate from PyPI:
pip show accelerate
If the version is 1.14.0 or below, you are affected. No fixed version is available at the time of this writing.
The exposure surface depends on how your code loads checkpoints. The highest risk applies to:
- Inference servers that load models from user-supplied URLs or Hub repositories
- CI/CD pipelines that load checkpoints from pull request artifacts
- Training frameworks that load fine-tuned checkpoints from untrusted contributors
- Any workflow that calls
load_checkpoint_in_modelorload_checkpoint_and_dispatchwith a path not fully controlled by the application
What to do
No patched release exists yet. Until Accelerate ships a fix, you need to validate checkpoint index files before passing them to Accelerate loading functions.
Add a path validation step that rejects any weight_map entry containing .. or starting with /:
import json
from pathlib import Path
def validate_checkpoint_index(index_path):
with open(index_path) as f:
index = json.load(f)
weight_map = index.get("weight_map", {})
base_dir = Path(index_path).resolve().parent
for tensor_name, shard_file in weight_map.items():
resolved = (base_dir / shard_file).resolve()
if not str(resolved).startswith(str(base_dir)):
raise ValueError(f"Unsafe path in weight_map: {tensor_name} -> {shard_file}")
if not resolved.exists():
raise ValueError(f"Missing shard file: {shard_file}")
return index
Call this function on any checkpoint index before passing it to load_checkpoint_in_model or load_checkpoint_and_dispatch. The check resolves each weight_map path against the checkpoint directory and rejects anything that escapes it.
For the named pipe DoS vector, add a file type check:
import stat
for shard_file in weight_map.values():
path = base_dir / shard_file
if stat.S_ISFIFO(os.stat(path).st_mode):
raise ValueError(f"Named pipe detected in checkpoint: {shard_file}")
Long term, pin Accelerate and watch for a patched release. The fix will likely add path canonicalization in the index parsing code.
Why it matters
This vulnerability turns model loading into a file read primitive. That matters because ML pipelines run in environments with access to sensitive data: API keys in environment files, model weights worth millions, training datasets containing PII, and cloud provider credentials on disk. An attacker who can read arbitrary files from a model loading host can exfiltrate all of these.
The attack does not require code execution. It does not require a network connection. It requires only that the target loads a checkpoint whose index file the attacker can influence. In the Hugging Face Hub ecosystem, where users routinely download community models and fine-tuned checkpoints, this is a realistic attack path.
The named pipe vector is lower severity but easier to exploit. Any attacker who can write a checkpoint index file can create a named pipe and point a shard entry at it. The loading process blocks forever. In a serving environment, this ties up a GPU and prevents the model from serving requests.
Not in CISA KEV. No known exploitation at time of writing. NVD enrichment is pending; no CVSS score has been assigned yet.
