HF datasets 5.0.1 patches an arbitrary file read; no code needed
A crafted file_name in a folder dataset reads local files like /etc/passwd and can exfiltrate them on push_to_hub — no trust_remote_code needed.
Copy markdown
The bug: attacker-controlled file_name, no sandbox
Folder builders (imagefolder, audiofolder, videofolder, pdffolder) join a dataset's file_name metadata straight to disk, and os.path.normpath never strips leading ../. A row like {"file_name": "../../../../etc/passwd"} reads that file — no trust_remote_code, no custom loader. It's CVE-2026-66007 (CVSS 6.9), affecting datasets ≤ 5.0.0.
Why it bites: the file ends up in your output
The read isn't only local. embed_storage does an unconditional raw-byte read during save_to_disk() and push_to_hub(), so a stolen key or /etc/passwd gets baked into the dataset you publish back to the Hub. Load an untrusted dataset, process it, push results — and you've leaked your own secrets.
The fix: upgrade to 5.0.1 today
datasets 5.0.1 (Jul 28) validates file_name paths (commit f989ef9) and also closes a symlink-following arbitrary file write in archive extraction. Run pip install -U datasets. The same release clears 20+ loader bugs, including CSV breakage on pandas 2.0–2.2.
The pattern: treat datasets like untrusted code
This lands two weeks after Hugging Face disclosed a July 16 breach where an autonomous agent used a malicious dataset — a remote-code loader plus template injection — to move across internal clusters. Every load_dataset() call runs someone else's data through your builders.