Split view poisoning changes web content after a dataset's maintainers indexed it, so later downloaders get different data than the annotators saw. Frontrunning poisoning edits crowd sourced pages shortly before a periodic snapshot. A 2023 research paper showed both were practical against popular datasets.
Where the terms come from
The paper is "Poisoning Web-Scale Training Datasets is Practical" by Nicholas Carlini and eight co-authors, first submitted to arXiv in February 2023. OWASP cites these two techniques as examples in its data and model poisoning entry for LLM applications.
Many large datasets are not stored as files of content. They are lists of links, and each user downloads the content from the web. That design is the source of the first attack.
Split view poisoning
The dataset maintainers check a list of URLs and publish it. Later, you download what each URL serves. If an attacker controls a domain in that list, perhaps one that expired and was re-registered, the attacker can serve different content to you than the maintainers saw.
The paper's abstract says this exploits the mutable nature of internet content, so that an annotator's initial view of the dataset differs from the view downloaded by later clients. It reports that, by exploiting specific invalid trust assumptions, the authors showed they could have poisoned 0.01 percent of two named image text datasets for 60 US dollars. The authors notified the maintainers of each affected dataset and recommended low overhead defenses.
Frontrunning poisoning
Some datasets periodically snapshot crowd sourced content, such as an encyclopedia. An attacker then needs a time limited window and little else: make a malicious edit, wait for the snapshot, and let it be captured before moderators revert it. The edit may be gone from the live page a few minutes later, yet remain in the frozen copy.
Why it matters to a normal team
You may never train a model from scratch. You may still fine tune on scraped text, build a retrieval corpus from web pages, or download a public dataset. Each fits one of these patterns when content is fetched from a place someone else can edit.
| Your situation | Exposure |
|---|---|
| Download a dataset that is a list of links | Content may differ from what was reviewed |
| Scrape sites on a schedule | Pages can change between runs |
| Ingest a community edited source | Short lived edits can be captured |
| Use a dataset distributed as fixed files | Lower, but you inherit whatever was in them |
Defenses that follow from the attacks
I take these from the structure of the attacks rather than quoting the paper's list, so check the paper for its exact recommendations.
- Store a copy of the content you train on, not just the links, so later changes do not reach you.
- Record a cryptographic hash of each item or file at collection time, and compare on every reuse.
- Check that domains in a link list still belong to the original owners before downloading.
- For crowd sourced sources, prefer snapshots that are old enough for reverts to have happened, rather than the freshest copy.
- Keep provenance records. OWASP suggests tracking data origins and transformations with tools like CycloneDX or an ML bill of materials.
For the records themselves, see what to record for a dataset in an AI bill of materials.
Quick check
Does using a smaller dataset avoid this?
Not automatically. Size matters less than where the content is fetched from and whether you keep a verified copy.
Is a link based dataset unsafe to use?
It carries more exposure than a fixed file. Mirror the content, hash it and review it before you rely on it.
Sources
- arXiv 2302.10149: Poisoning Web-Scale Training Datasets is Practical
- OWASP LLM04:2025 Data and Model Poisoning
Last reviewed: 19 October 2026.
