No. A dataset can contain poisoned examples, personal data or restricted licenses, and some datasets are distributed with code that runs when they load. Plain data files are lower risk than code, but they still shape what your model learns, so they need provenance and review.
Myth 1: Data cannot run code
Fact: Data files in common formats such as CSV, JSON, Parquet and text are parsed, not executed. But the Hugging Face Datasets documentation also describes a dataset builder with methods that download files and generate examples, which is code. A dataset that ships loading code asks you to run it. Check whether your library will execute dataset scripts and what flag controls it. See datasets, loading scripts and trust remote code.
Myth 2: A popular dataset is a vetted dataset
Fact: Popularity is not review. A 2023 paper, "Poisoning Web-Scale Training Datasets is Practical", showed how its authors could have poisoned 0.01 percent of two named datasets for 60 US dollars, and notified the maintainers. Many popular datasets are lists of links to content that others can change. See split view and frontrunning poisoning.
Myth 3: A malware scan covers everything that matters
Fact: The Hugging Face documentation says dataset repositories on the Hub are scanned for malware. That addresses one class of threat. It does not tell you whether examples were poisoned, mislabeled, mislicensed or full of personal data. Scanning and data review answer different questions.
Myth 4: Checksums are on, so tampering is covered
Fact: The same documentation says SHA256 checksum verification of downloaded files is disabled by default in that loader. Even when on, a checksum shows just that the file matches what the author published. It cannot show the content was clean. See how to verify a downloaded dataset with checksums.
Myth 5: Poisoning needs a huge amount of bad data
Fact: No threshold is given here, because none could be confirmed from a source and the real number depends on the model and the attack. What OWASP does say is that poisoning can target pre-training, fine tuning and embedding data, and that backdoors may leave behavior normal until a trigger appears. Do not rely on a belief that small amounts are harmless.
Summary table
| Belief | Better statement |
|---|---|
| Data cannot run code | Data files are parsed; loading scripts are code |
| Popular means vetted | Popular means widely used |
| Malware scan is enough | It covers malware, not content quality or rights |
| Checksums protect me | They detect change after you recorded the value |
| Small poison is harmless | Backdoors can hide until triggered |
What to do instead
- Prefer plain data files over datasets that need loading code.
- Copy and hash what you accept, and keep the copy.
- Review a sample of records, license and sensitive content before use.
- Record the dataset in your inventory with an owner.
- Limit what the model trained on it can do.
Quick check
Is synthetic data free of these risks?
No. It inherits flaws from the model that generated it and can carry hidden bias or restricted content. Review it like any other source.
Do these points apply to evaluation datasets?
Yes. A tampered evaluation set can hide a problem or push you toward the wrong model.
Sources
- Hugging Face Datasets: build and load
- arXiv 2302.10149: Poisoning Web-Scale Training Datasets is Practical
- OWASP LLM04:2025 Data and Model Poisoning
Last reviewed: 19 October 2026.
