Poisoning Web-Scale Training Datasets is Practical

ArXiv: 2302.10149

🎯 Pitch

Deep learning's reliance on internet-scraped data is a ticking time bomb: for just $60, an attacker can buy expired domains that are already indexed in popular datasets like LAION-400M and serve poisoned images to anyone downloading the data. The paper shows over 800 real downloads of these datasets could have been hijacked through such 'split-view poisoning,' proving that no special access or sustained control is needed to corrupt the foundation models trained on them.

---

1. Executive Summary

This paper analyzes whether poisoning web-scale training datasets is practically achievable by introducing two novel attack mechanisms—split-view poisoning (purchasing expired domains that host images indexed in distributed datasets, then returning malicious content to subsequent downloaders) and frontrunning poisoning (timing malicious edits to Wikipedia just prior to known snapshot collection times so that reverted vandalism persists in the frozen dump). The authors measure the attack surface across 10 popular datasets—including LAION-400M, COYO-700M, and Conceptual 12M—and demonstrate that for just $60 USD an adversary could control 0.01% of the LAION-400M or COYO-700M datasets, a poisoning rate already shown effective in prior work. Through passive monitoring of purchased expired domains over 12 months, they record over 800 downloads of these datasets that could have been poisoned, establishing that practical poisoning requires neither specialized knowledge nor sustained resource control—only exploitation of the trust assumptions inherent in how web-scale datasets are distributed and snapshotted.

2. Context and Motivation

The Gap: We Know Poisoning Works, But Not How to Do It

The paper identifies a striking asymmetry in the poisoning literature. There exists an "exceptionally vast" body of work (the authors cite over 70 papers in their introduction alone) that studies what happens after an adversary has successfully modified a training dataset: what impact poisoned data has on model behavior, how to make poisoning stealthy, how to defend against it, and how to attack those defenses. These papers typically begin with the premise that the adversary can modify some fraction of training examples, and then proceed to analyze the downstream effects.

But the paper argues that this vast literature has collectively skipped over the most fundamental question: is it actually possible for an adversary to poison a real-world web-scale dataset in the first place? The authors state this explicitly:

"Our paper does not address any of these questions as there are already hundreds of papers already dedicated to each. We focus on the preliminary question: is it actually possible for an adversary to actually poison a dataset?"

This is not merely a gap in the academic literature — it is a gap that determines whether the entire subfield of poisoning attacks is practically relevant or purely theoretical. Prior work had demonstrated that poisoning rates as low as 0.001% can be effective for certain attack objectives (e.g., targeted misclassification or planting model backdoors), but no one had shown whether an adversary could realistically achieve even that minuscule fraction of control over a dataset like LAION-400M or COYO-700M without guessing in advance which URLs would be crawled.

Why This Matters: The Shift to Web-Scale, Uncurated Datasets

The practical significance of this question has grown enormously because of a fundamental shift in how deep learning training data is collected. The paper traces this evolution:

From curation to crawling. Early influential datasets were relatively small and carefully curated — ImageNet (Deng et al., 2009) contains roughly 1.3 million hand-labeled images, and the Penn Treebank (Marcinkiewicz, 1994) contains meticulously annotated text. Curating such datasets is expensive and slow, but it provides quality control: human annotators inspect each example, making it difficult for an adversary to slip in malicious content unnoticed.

The scaling imperative. The paper draws on the Chinchilla scaling laws (Hoffmann et al., 2022) to quantify the problem: training a compute-optimal 500 billion parameter language model would require 11 trillion tokens of training data — over 10× more data than is currently used to train models of this size. No amount of manual curation can scale to this volume. The result has been a necessary tradeoff: models are trained on data crawled from an increasingly wide range of untrusted, uncurated web sources.

Quantity over quality — and its accepted risks. This tradeoff has been deemed acceptable for two reasons articulated in the paper. First, modern neural networks are "extremely resilient to large amounts of label noise" (citing Rolnick et al., 2017 and Zhang et al., 2021), meaning that random errors in the training data don't catastrophically degrade performance. Second, training on noisy data can actually improve model utility on out-of-distribution data (citing Radford et al., 2021 on CLIP and Radford et al., 2023 on Whisper). The community has thus accepted random noise as a cost of scale.

But adversarial noise is different. The paper draws a critical distinction: while models are robust to random noise, even "minuscule amounts of adversarial noise in training sets (i.e., a poisoning attack) suffices to introduce targeted mistakes in model behavior." Prior work (Carlini and Terzis, 2021; Carlini, 2021; Schuster et al., 2021; Wallace et al., 2020) had established that poisoning rates as low as 0.01% or even 0.001% can cause targeted misclassification, implant backdoors, or otherwise compromise model integrity. The threat model had been validated — but only conditional on the adversary actually being able to place poisoned samples in the dataset.

Prior Work Falls Short: The Missing "How"

The paper identifies several specific ways in which prior work has failed to address the practical poisoning question:

1. Prior attacks assumed dataset access without explaining how to get it. The vast poisoning literature "first presumes an adversary can modify a training dataset, and then asks (1) what impact this could have, (2) if poisoning can be stealthy, (3) how to defend against poisoning, and (4) how to attack these defenses." But the mechanism by which an adversary gains that access is treated as out of scope. The authors argue this is a critical omission: if practical poisoning vectors don't exist, then all downstream poisoning research is solving a problem that may never arise; if they do exist, then understanding them is essential to building defenses.

2. The few attacks that considered practical deployment required unrealistic capabilities. Some prior poisoning attacks attempted to be more practically grounded. For example, backdoor attacks that modify training data often assume the adversary can compromise the dataset distribution pipeline, or can add new URLs to a dataset's index, or can modify both the content and the label of training examples. The paper explicitly constrains its threat model more tightly than prior work: the adversary has "no specialized or insider knowledge about the curator, downloader, or maintainer," cannot modify auxiliary data (captions, labels), and cannot add or remove URLs from the dataset index. This makes the attack strictly harder to execute than what prior work assumed, but the authors show it remains feasible by exploiting structural properties of how web-scale datasets are actually distributed.

3. Existing attacks on uncurated data require knowing which data will be collected. A critical challenge that prior work ignored is that an adversary wanting to poison a web-scale dataset must either (a) know in advance which URLs the dataset curator will include, or (b) have some way to modify data after the dataset index is published. The paper states this clearly:

"it is not well understood how an adversary could place poisoned samples in any training dataset without guessing beforehand which parts of the web will be collected. This paper answers that question."

Without this knowledge, an adversary would have to poison random web pages and hope they get crawled — a strategy with astronomically low success probability given the size of the web compared to any given dataset.

4. No prior work studied the dataset distribution architecture as an attack surface. The paper identifies that web-scale datasets fall into two architectural categories — distributed datasets (which provide URL indices that clients crawl themselves) and centralized datasets (which provide periodic snapshots of web content) — and that each architecture introduces distinct trust assumptions that can be exploited. Prior work had not analyzed these distribution mechanisms as security vulnerabilities, instead treating the dataset as an abstract collection of examples.

How This Paper Positions Itself

The paper explicitly positions itself as addressing the preliminary question that the entire poisoning literature has taken for granted. It does not propose new poisoning objective functions, new stealth techniques, new defenses against poisoned models, or attacks against defenses. Instead, it investigates the attack vector — the mechanism by which an adversary ensures their malicious content enters the training pipeline.

This positioning is important because it reorients the conversation around poisoning from "what can we do with poisoned data?" to "can we actually poison data in practice?" The paper's answer — yes, for just $60 USD — has implications across the entire poisoning literature, because it validates that the threat models assumed in prior work are not merely hypothetical.

The paper also positions itself relative to a broader context beyond security. It acknowledges that the shift to uncurated, web-scale data has implications for "fairness, bias, and ethics" (citing Birhane et al., 2021 on problematic content in LAION-400M, and Luccioni and Viviano, 2021 on hate speech in Common Crawl). The security vulnerability that enables poisoning — the lack of integrity verification on downloaded content — is thus part of a larger pattern of quality-control challenges that arise when datasets outgrow human-scale curation.

The Connection to Evidence of Prior Attack Difficulty

To further motivate why practical poisoning is non-obvious, the paper notes that "to our knowledge no real-world attacks involving poisoning of web-scale datasets have occurred." This is despite the attack vectors having existed for years, and despite the relative ease of execution the paper demonstrates. Section 4.4 actively searches for evidence of past exploitation by looking for domains that (1) host images modified since the initial dataset release and (2) changed ownership since release — a signature of the split-view attack. Across CC3M and LAION-400M, the authors find "no evidence at present that this attack would have been exploited."

This finding is simultaneously reassuring (the attack hasn't happened yet) and alarming (the vulnerability has been present for years without anyone noticing). It underscores the paper's core argument: the security community has not been paying attention to the practical attack surface of dataset distribution, and the lack of past exploitation should not be interpreted as evidence of security — only as evidence that attackers haven't yet recognized the opportunity.

3. Technical Approach

3.1 Reader Orientation

This is primarily a measurement and attack-design paper that demonstrates two concrete exploit vectors for poisoning web-scale training datasets, rather than proposing new poisoning objectives or defenses. The paper solves the problem of guaranteeing that malicious content ends up in a dataset by exploiting structural properties of how modern datasets are distributed: for distributed datasets (URL indices), the adversary purchases expired domains that are already in the index; for centralized datasets (periodic snapshots), the adversary times malicious edits to occur just before a predictable snapshot window, ensuring the edits persist in the frozen dump even if later reverted.

3.2 Big-Picture Architecture (Diagram in Words)

The paper's system is not a single unified tool but rather a methodology for identifying and validating poisoning attack surfaces across two distinct dataset architectures. The flow is:

1. Dataset Architecture Classifier — determines whether a target dataset is distributed (URL index, clients crawl themselves) or centralized (snapshot of content distributed as artifact). This determines which attack applies.
2. For distributed datasets — Split-View Attack Pipeline:
   • Expired Domain Scanner — queries DNS records for every domain in the dataset index, identifies domains returning NXDOMAIN (expired), and ranks them by cost-per-image (number of URLs hosted on the domain divided by purchase price).
   • Domain Purchaser — buys the most cost-effective expired domains, sets up HTTPS servers with valid certificates, and serves 404 responses to avoid actually harming anyone.
   • Passive Download Monitor — logs all incoming HTTP/HTTPS requests to purchased domains over 12 months, then applies precision-and-recall filters to distinguish genuine dataset downloads from web crawlers and random traffic.
   • Integrity-Attack Demonstrator — for a proof-of-concept, locally replaces images from purchaseable domains with poisoned samples and trains a model to verify the attack would succeed at the observed poisoning rate.
3. For centralized datasets — Frontrunning Attack Pipeline:
   • Snapshot Timing Predictor — exploits the deterministic, sequential, well-documented Wikipedia dump protocol to predict within ~30 minutes when any given article will be scraped for inclusion in a snapshot.
   • Reversion Speed Estimator — passively analyzes Wikipedia edit histories to build a distribution of how quickly malicious edits are reverted, without ever making edits.
   • Success Rate Calculator — combines timing predictions and reversion speed to compute a lower bound on the fraction of articles an attacker could poison, parameterized by an adjustment variable that trades off "too early" (reverted before snapshot) vs. "too late" (snapshot already taken) failures.
4. Defense Proposer — for each attack, proposes a concrete, low-overhead defense (cryptographic integrity hashes for split-view; randomized or time-gated snapshots for frontrunning) and analyzes their limitations.

3.3 Roadmap for the Deep Dive

• First, the threat model and terminology — what "distributed" vs. "centralized" datasets are, what the adversary can and cannot do, and the two critical (yet realistic) assumptions that enable the attacks. This establishes the security boundaries within which the rest of the paper operates.
• Second, the split-view poisoning attack in full detail — how expired domains are identified, purchased, and monitored; how dataset downloads are distinguished from noise; what the attack costs; and whether the attack has been exploited in the wild. This is the more quantitative of the two attacks and establishes the methodology for measuring attack surface.
• Third, the frontrunning poisoning attack — how Wikipedia snapshot timing is predicted, how reversion speed is estimated, and how these combine to yield a success rate. This attack has a different flavor (temporal rather than financial) and requires explaining Wikipedia's specific dump infrastructure.
• Fourth, the defenses — how integrity hashes and timing-based countermeasures work, their limitations, and the broader transparency proposals. These are evaluated against the specific mechanisms that enable each attack.

3.4 Detailed, Sentence-Based Technical Breakdown

This is a measurement and attack-design paper whose core idea is that the way web-scale datasets are distributed — either as URL indices that clients crawl or as periodic snapshots of live content — creates exploitable trust assumptions that an adversary can violate without specialized capabilities, enabling guaranteed dataset poisoning at costs as low as $60 USD.

---

3.4.1 Threat Model and Dataset Taxonomy

Dataset Types: Distributed vs. Centralized

The paper first establishes a taxonomy of how web-scale datasets are published, because the attack vector depends fundamentally on which category a dataset falls into.

Distributed datasets consist of a maintainer publishing a set of $N$ tuples $\{(url_i, c_i)\}_{i=1}^N$, where $url_i$ is a resource identifier (typically an HTTP URL pointing to an image) and $c_i$ is auxiliary data (typically a text caption or class label). Let $t_i$ denote the time at which the $i$-th sample was originally collected by the maintainer. Critically, the maintainer does not provide the actual content of $url_i$ — clients must crawl each URL themselves at some future time $t'_i > t_i$. The maintainer adopts this approach due to one or more of: untenable storage costs (e.g., LAION-5B's five billion images would require hundreds of terabytes), privacy concerns (e.g., face datasets where distributing actual photos raises consent issues), or copyright limitations. The LAION-5B dataset exemplifies this category: it consists of five billion tuples of image URLs and corresponding text captions.

Centralized datasets consist of a curator producing a snapshot of a dataset $\{x_i\}_{i=1}^N$, where each sample $x_i$ is drawn from a set of URLs $\{url_i\}_{i=1}^N$ at time $t_i$, and then making this snapshot publicly available as a downloadable artifact. Because data served by these URLs changes over time, the curator periodically (e.g., monthly) re-collects a new snapshot so that users have an up-to-date view. Wikipedia snapshots and Common Crawl exemplify this category. The curator provides the actual content, not just pointers to it, which simplifies access and discourages researchers from re-scraping the live source directly.

Adversary Capabilities

The paper assumes a relatively unskilled, low-resource adversary who can tamper with the contents of a small number of URLs $\{url_i\}_{i=1}^N$ at some point in time $\hat{t}_i$, such that when a client or curator accesses resource $i$ at a future time $t'_i > \hat{t}_i$, they receive a modified (poisoned) dataset $\mathcal{D}' \neq \mathcal{D}$. The difference between the poisoned and intended datasets must be sufficiently large that a model $f$ trained on $\mathcal{D}'$ will produce poisoned results for some desired input. Let $S_{adv} \subset \{url_i\}_{i=1}^N$ denote the set of URLs an adversary can modify.

Crucially, the adversary has no specialized or insider knowledge about the curator, downloader, or maintainer — other than knowledge of the set of URLs $\{url_i\}_{i=1}^N$ used to generate $\mathcal{D}$, since this information is published by the dataset curator as part of the index. The adversary cannot modify the auxiliary data $c_i$ (e.g., supervised labels or text descriptions), nor can they add or remove any URLs from the training data that will be crawled by a client or curator. This tight constraint — fixing captions while allowing image replacement — is stricter than what prior poisoning work assumed (e.g., Carlini and Terzis, 2021 assumed the adversary could modify both images and their captions).

All maintainers, curators, and downloaders behave honestly and do not assist the adversary in any way. The attacks work despite honest behavior — they exploit structural properties of the dataset distribution pipeline, not compromised insiders.

Two Enabling Assumptions

The paper makes two critical (yet realistic) assumptions that enable the attacks:

For distributed datasets (enabling split-view poisoning): The paper assumes that clients do not compare the cryptographic integrity of the local dataset copy $\mathcal{D}'$ that they downloaded with the original dataset $\mathcal{D}$ indexed by the maintainer. This is equivalent to saying that the dataset is treated as int const * (a pointer whose target can change) rather than int * const (a pointer that is constant but points to modifiable data). The paper demonstrates that this assumption holds for nearly all modern web-scale datasets — of the ten datasets studied, only PubFig and FaceScrub include cryptographic hashes, and even for those, the majority of third-party downloader scripts do not verify them.

For centralized datasets (enabling frontrunning poisoning): The paper assumes that it takes the curator at least some time $\Delta$ to detect malicious changes to the content hosted at any URL $url_i$ in the dataset. Concretely, for Wikipedia, $\Delta$ is the time it takes for an editor or bot to revert a malicious edit. This means the curator cannot detect that $url_i$ hosts poisoned content if the attacker poisoned the content at any time $t_i - \Delta \leq \hat{t}_i \leq t_i$, where $t_i$ is the time at which the content of $url_i$ is included in the dataset snapshot. The paper validates this assumption by measuring Wikipedia reversion times: approximately 35% of reversions take more than 30 minutes, and the snapshot process takes nearly 24 hours, creating a window for well-timed edits.

What Is Out of Scope

The paper explicitly excludes several attack vectors that would only improve success rates: interfering with unencrypted network requests (man-in-the-middle attacks), exploiting website vulnerabilities to inject new content (e.g., SQL injection or XSS), coercing website owners to modify content, or any other attack that requires capabilities beyond domain ownership or Wikipedia editing privileges. The attacks presented are intentionally the simplest possible exploits of the identified vulnerabilities.

---

3.4.2 Split-View Poisoning: Domain Expiration Attack

The Core Vulnerability

The split-view poisoning attack exploits a simple observation: the index of a distributed dataset is published at time $t_i$ and cannot be modified by the adversary (since they cannot add or remove URLs), but the content hosted at those URLs at a later download time $t'_i > t_i$ is controlled by whoever owns the domain at that later time. If the original domain owner allows their registration to expire, "anyone can buy them." The attacker does not need to know when clients will download — by owning the domain, the attacker guarantees that any future download will collect poisoned data.

This attack is a specific instance of domain hijacking (Lever et al., 2016), a known attack class where adversaries exploit residual trust in expired domains. Prior work has documented domain hijacking for serving malware (Moore and Clayton, 2014), stealing user data via imported JavaScript libraries (Nikiforakis et al., 2012), taking over email accounts (Schlamp et al., 2015), controlling authoritative nameservers (Lever et al., 2016), and serving advertisements (Lauinger et al., 2017). The novel contribution is demonstrating that the same mechanism can poison machine learning training datasets by exploiting the fact that dataset indices do not expire — they continue to point to URLs whose content may have changed ownership.

Quantifying the Attack Surface: Expired and Buyable Domains

The first measurement task is to quantify what fraction of each dataset's images is hosted on domains that are both expired (DNS record returns NXDOMAIN) and buyable (available for purchase at a listed registrar price, not held by a domain squatter who would charge inflated rates).

Expiration check methodology. The paper performs an nslookup on every domain name in the dataset from two geographically distinct datacenters, once in May 2022 and again in August 2022. A domain is classified as expired if all four lookups result in a NXDOMAIN response. Using two datacenters and two time points reduces the risk of transient DNS failures being misclassified as expiration.

Buyability check methodology. For each expired domain, the paper checks whether at least one domain name registrar lists it as for sale by the registrar (not by a third-party squatter) in August 2022. Some registrars list domains as for sale even if they are actually owned by a squatter — these are excluded because purchasing from squatters is "often an expensive and lengthy process" that would misrepresent the true cost to an attacker.

Cost-efficiency ranking. Rather than counting the total fraction of data that is buyable (which would represent a financially unconstrained adversary), the paper reports the fraction of images that can be purchased for a total cost of $1,000 USD. This is computed by sorting domains in decreasing order of the number of images the domain hosts divided by the cost to purchase that domain (images per dollar), and greedily selecting domains until the$1,000 budget is exhausted.

Results across 10 datasets. Table I reports that an adversary with a $1,000 budget could control between 0.02% (Falcon RefinedWeb) and 0.79% (LAION-400M) of images, with older datasets generally being more vulnerable (e.g., VGG Face at 3.70% expired, PubFig at 6.48%). The relationship between age and vulnerability arises because domain registrations expire over time — owners forget to renew, organizations dissolve, hosting providers go out of business — so older indices naturally contain more dead domains.

Cost to reach 0.01% poisoning rate. Figure 1 plots the fraction of each dataset that can be controlled as a function of the attacker's budget. The key finding is that at least 0.01% of each dataset can be controlled for less than $60 USD per year. The 0.01% threshold is significant because prior work (Carlini and Terzis, 2021) demonstrated that this poisoning rate is sufficient for effective attacks on uncurated datasets.

COYO-700M: Vulnerable from Release Day

A limitation of the above analysis is that it was conducted in August 2022, but many datasets were constructed years earlier — it is possible that most downloads occurred when fewer domains were expired. To address this, the paper leverages a fortunate coincidence: the COYO-700M dataset was released on 30 August 2022, during the writing of this paper. On that same day, the authors computed that already 0.1% of the images were hosted on expired domains that cost fewer than $1,000 USD to purchase.

This is not zero on release because building large datasets is a time-consuming process. COYO-700M's index was released in August 2022, but it took nearly a year to collect the dataset (Byeon et al., 2022). The earliest-scraped domains had ample time to expire before the index was even published. This demonstrates that expired domains are not just a problem for old, neglected datasets — they are a vulnerability that exists from the moment a dataset is published, because the crawling and release process itself spans months during which domains can lapse.

Passive Monitoring Infrastructure

To measure whether these datasets are still actively downloaded (and thus whether the attack has practical impact), the paper sets up passive monitoring infrastructure.

Domain purchase. For each of the 10 datasets, the authors purchase the three most popular expired and buyable domains (those hosting the most images) and three randomly selected expired and buyable domains. This gives six domains per dataset, 60 domains total.

Server setup. The authors write a simple server to log all incoming HTTP and HTTPS requests, recording: the access time, a hash of the IP address (for privacy), the full URL being requested, and any additional headers provided. To monitor HTTPS traffic, they obtain certificates from LetsEncrypt for each domain. The server runs for twelve months beginning in August 2022.

Scale of traffic. The server receives approximately 15 million requests per month, a rate of 6 requests every second. This raw traffic includes web crawlers, random internet scanners, and actual dataset downloads — the analysis challenge is distinguishing between them.

Distinguishing Dataset Downloads from Noise

The paper applies a conservative two-condition filter to identify IP addresses that are genuinely downloading a dataset:

Recall condition. Within some time range $[T_0, T_1]$, the IP address X downloads at least 90% of the URLs contained in dataset D under the authors' control, including at least one URL from each of the 6 domains owned for that dataset. This ensures the downloader is systematically traversing the dataset index rather than randomly hitting a few URLs.

Precision condition. At least 50% of the requests issued by X within this time range to the domains under the authors' control are to URLs in dataset D. This filters out web crawlers and mass internet scrapers that happen to request some dataset URLs among many others — if a crawler visits 100 pages on a domain and only 2 are dataset URLs, it fails the precision check.

These conditions are designed to be conservative — they likely undercount true downloads — but provide high confidence that flagged IP addresses are genuinely performing dataset collection. The combination of both conditions is powerful because owning six domains per dataset makes it "exceptionally unlikely that, by random chance alone, one particular IP will request URLs from each of these six otherwise-unrelated domains."

Quantitative example (CC-3M). For the CC-3M dataset, the raw traffic included 51,000 image requests per month from 2,401 unique IPs. Applying the precision constraint alone reduces this to 2,007 unique IPs and 43,000 image requests. Applying the recall constraint alone yields 70 unique IPs and 32,000 image requests. Applying both together yields 64 unique IPs and 28,000 image requests per month.

Results: Download Frequency

The rightmost column of Table I reports the number of downloads observed per month for each dataset. Even the oldest and least frequently accessed datasets (PubFig, FaceScrub) still had at least 3 downloads per month. Over the six months of tracking, there were over 800 downloads that could have been poisoned. Newer datasets are requested more often than older ones, creating a tradeoff for attackers: newer datasets have a smaller fraction of purchaseable images but reach many more vulnerable clients.

The billion-image datasets paradox. The largest billion-image datasets (LAION-2B-en, LAION-2B-multi) are downloaded significantly less often than smaller recent datasets. The reason is that these massive datasets are rarely downloaded in their entirety; instead, they serve as upstream sources for smaller subsets. For example, the Public Multimodal Dataset (PMD; Singh et al., 2022) and LAION-Aesthetics (Schumann and Beaumont, 2022) consist almost entirely of images drawn from LAION-2B-en. This explains why the paper sometimes sees IP addresses with high precision (they are downloading systematically from the subset) but low recall (they do not request all URLs under the authors' control because they are targeting a specific sub-index).

Visualizing Dataset Crawlers

The paper provides a striking visualization of dataset crawling behavior (Figure 2) by plotting URL requests over time, with URLs ordered according to their position in the original dataset index and each unique IP assigned a random color. This reveals several patterns:

• Most users download the dataset in linear order from first to last URL, appearing as roughly diagonal lines in the plot.
• The download rate is highly variable: some crawlers complete the dataset in a few hours, while others take several weeks.
• Some users batch the data into chunks and download each chunk in parallel (multiple diagonal segments at different vertical positions occurring simultaneously).
• Some users pause and resume downloads, sometimes on a different IP address.
• The linear ordering strongly confirms dataset downloading, because the ordering of URLs in the dataset index is random (not alphabetical or topical) — a dataset download is the only explanation for linear URL access in this particular order.

User-Agent Analysis

The most popular user agent — Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 — is responsible for 77% of the traffic to the authors' domains. This user agent is hardcoded in the img2dataset tool (Beaumont, 2021), the most popular dataset crawler. The claimed browser version is Firefox 72, released in February 2020, making it highly unlikely that these requests originate from actual Firefox users browsing the web. This provides independent confirmation that img2dataset is the dominant download mechanism, which matters for targeted defense deployment (the authors later implement hash verification in img2dataset specifically).

Is the Attack Already Being Exploited?

The paper searches for evidence of past split-view poisoning by looking for domains that exhibit two signatures simultaneously: (1) images that have changed since the initial dataset release, and (2) domain ownership that changed since the initial dataset release.

Analysis on CC3M (ground-truth raw images available). Among all domains hosting more than 10 images, the authors find just one domain displaying this signature when comparing images with perceptual similarity (CLIP cosine similarity). Upon investigation, this domain had been purchased by a domain squatter and any image request returned an advertisement — not a targeted poisoning attack. Comparing cryptographic hashes (which detect any change, including benign re-encoding) finds two additional domains, but further investigation reveals these domains' ownership had not changed — the DNS record simply lapsed and images were re-encoded by the original owner.

Analysis on LAION-400M (only CLIP embeddings available). The paper studies three versions of the data: at original release (November 2021), a download in April 2022, and a download in August 2022. Across these snapshots, 4.1 million and 4.2 million unique domains (of 5.6 million total) hosted at least one modified image (CLIP cosine similarity < 0.99), totaling 175 million and 183 million modified images respectively. Sampling thousands of domains, including the 700 with the most modified images, the authors find "many cases where domains are still owned by the original owner, are currently for sale, or have been redacted, but none appear malicious."

Conclusion: There is no evidence that split-view poisoning has been exploited in the wild against these datasets — but the vulnerability has existed for years, and the modification volume is high enough that a well-crafted attack could have blended in with benign changes.

Proof-of-Concept: Does the Acquired Control Actually Enable Poisoning?

To verify that the fraction of control achievable through domain purchase is sufficient for effective poisoning attacks, the paper conducts a proof-of-concept experiment training an OpenCLIP model (ViT-B-32 architecture, 32 epochs, batch size 3072 on 16 A100 GPUs) on LAION-400M with simulated poisoned images. Two attack objectives are tested:

Object-misclassification objective. The attacker wants a particular image to be classified as a specific ImageNet class by the CLIP zero-shot classifier (which returns the class label whose text embedding has maximum cosine similarity to the image embedding). The experiment chooses 10 ImageNet classes as target labels, such that captions containing the label appear at least 1,000 times in captions linked to cheap buyable domains. For each class (e.g., "apple"), the authors select 1,000 caption-image pairs from buyable domains where the caption contains that class name, ensuring the total domain purchase cost across all 10 classes is at most $1,000 USD. A single unrelated image is then locally substituted for all 1,000 images in each class's set. Thus for each of the 10 classes, 1,000 images are poisoned — 10,000 images total, or only 0.0025% of the LAION-400M dataset (400 million images). Result: The attack succeeds for 60% of the targets — the chosen image gets classified as the target label by the zero-shot CLIP classifier. This is at a poisoning rate of 0.00025% per target class, well within the domain purchase budget.

NSFW misclassification objective. The attacker wants the Stable Diffusion Safety Filter (which uses a CLIP-based cosine similarity threshold to detect NSFW content) to mislabel a benign image as NSFW. The experiment chooses 10 benign images and, for each, selects 1,000 caption-image pairs from buyable domains where the captions are labeled UNSAFE in the LAION-400M metadata. The benign image is locally substituted for all 1,000 images in each set, again keeping total domain costs under $1,000 USD (10,000 images total, 0.0025% of the dataset). Result: The attack succeeds for 90% of targeted images — the NSFW filter misclassifies benign images as unsafe.

These results validate that the attack surface measured in Table I (0.01%–0.79% of data purchaseable for $1,000) is not merely a theoretical concern — it translates directly into effective poisoning at rates that prior work had already validated. The constraint that the adversary cannot modify captions (only images) does not prevent success, because the existing captions provide enough semantic signal for the contrastive learning objective to associate the poisoned images with the desired labels.

---

3.4.3 Frontrunning Poisoning: Wikipedia Snapshot Timing Attack

The Core Vulnerability

Frontrunning poisoning targets centralized datasets that produce periodic snapshots of crowdsourced content. The specific demonstration is on Wikipedia, which is both widely used in ML training data (forming over 75% of the BERT training set, 1.5% of the Pile, the entirety of WikiText, and serving as upstream for task-specific datasets like WikiQA and WikiBio) and has a well-documented, predictable snapshot process.

The vulnerability arises because Wikipedia-derived datasets are not live — they use static snapshots ("dumps") because Wikipedia forbids scraping the live website. These snapshots are produced on a deterministic schedule (1st and 20th of each month for English Wikipedia). If an attacker can predict when a specific article will be scraped for inclusion in the snapshot, they can make a malicious edit immediately prior, knowing that even if the edit is reverted within minutes, the snapshot will contain the malicious content forever.

This transforms the attack from "hope my edit coincides with an unknown scraping time" (which would require sustained control over many articles for an unpredictable duration) to "time my edit precisely to a known 30-minute window" (which requires only transient control).

How Wikipedia Snapshots Work

English Wikipedia is archived on the 1st and 20th of each month. The snapshot is produced by $n$ parallel workers (typically around 24–28 for English Wikipedia). All Wikipedia articles are ordered sequentially by their article ID (a monotonically increasing integer assigned at page creation) and split into $n$ chunks. Each worker independently and linearly scrapes all articles in its chunk, proceeding from lowest to highest article ID.

Due to Wikipedia's size (over 6 million articles for English Wikipedia), the entire process takes nearly a full day to complete. Different articles thus get scraped at significantly different wall-clock times — an article with a low ID in an early chunk might be scraped at hour 2, while an article with a high ID in a late chunk might be scraped at hour 20. This means an edit at time $t_i$ for one article may be excluded from the snapshot, while an edit at time $t_j > t_i$ for a different article might be included — what time to make an edit depends on which article is being targeted.

The paper visualizes this "sawtooth" effect in Figure 3. For a single snapshot (June 1st, 2022), article ID is plotted on the x-axis and edit time on the y-axis. Each point is an edit, colored blue if included in the snapshot and orange if not included. The plot reveals multiple parallel diagonal lines — each corresponds to one worker job processing articles sequentially. The boundary between blue (included) and orange (excluded) points forms a clean diagonal line for each job, confirming that articles are processed in strict ID order within each job.

Predicting Individual Article Snapshot Times

The prediction method exploits two consistencies in Wikipedia's snapshot process:

Observation 1: The start time of each snapshot is knowable. Wikipedia announces the start of each dump on its status page. Let $t_0$ denote the start time of the current snapshot and $t_{0,\text{prev}}$ the start time of the previous snapshot. Both are known to the attacker at the time they plan their edits.

Observation 2: The rate at which articles are crawled remains consistent across dumps. While crawls tend to speed up slightly over time (as Wikipedia's infrastructure improves), the relative crawl timing — how long after the start time a given article is scraped — is stable. Formally, for article $i$, let $t_i$ be its crawl time in the current snapshot and $t_{i,\text{prev}}$ its crawl time in the previous snapshot. The paper observes that:

$t_i - t_0 \approx t_{i,\text{prev}} - t_{0,\text{prev}}$

In plain language: the offset from snapshot start time to article scrape time is approximately preserved across consecutive snapshots.

This yields the prediction:

$\hat{t}_i = t_0 + (\hat{t}_{i,\text{prev}} - t_{0,\text{prev}})$

where $\hat{t}_i$ is the predicted snapshot time for article $i$ in the upcoming snapshot, $t_0$ is the known upcoming snapshot start time, $\hat{t}_{i,\text{prev}}$ is the estimated snapshot time from the previous snapshot, and $t_{0,\text{prev}}$ is the known previous snapshot start time.

What it computes: The predicted wall-clock time when article $i$ will be scraped for the upcoming Wikipedia snapshot, computed by taking the article's offset from the previous snapshot start and adding it to the upcoming snapshot start. This is essentially linear extrapolation of relative timing.

Why this form: The alternative — assuming all articles are scraped at the same time or at a uniform rate — would be grossly inaccurate because the "sawtooth" effect creates differences of up to 24 hours between the first and last articles in a snapshot. Using the previous snapshot's relative timing captures the structure of parallel jobs and article ordering that determines when each article is actually scraped.

Retroactively Estimating Previous Snapshot Times

The prediction formula above requires $\hat{t}_{i,\text{prev}}$, the snapshot time from the previous dump. Wikipedia snapshots do not explicitly record each article's scrape time. However, Wikipedia does provide a complete list of edits with precise timestamps. The paper shows how to triangulate the snapshot time from edit histories.

Basic interval construction. For each article, the paper identifies the last edit included in the previous snapshot (the edit with the latest timestamp that is present in the dump) and the first edit not included (the edit with the earliest timestamp that is absent from the dump). Let $t_{i,\text{prev}}^{\text{in}}$ be the time of the last included edit and $t_{i,\text{prev}}^{\text{out}}$ be the time of the first excluded edit. The true snapshot time $t_{i,\text{prev}}$ must satisfy:

$t_{i,\text{prev}}^{\text{in}} \leq t_{i,\text{prev}} \leq t_{i,\text{prev}}^{\text{out}}$

This interval is often loose — the time between the last-included and first-excluded edits can be several days, which is far too coarse for timing a frontrunning attack.

Tightening the interval using job-sequential processing. The key refinement exploits the observation that within each parallel worker job, articles are processed sequentially (see the clean diagonal boundary in Figure 3). This means that for two articles $i$ and $j$ in the same job with $i < j$ (lower article ID), the snapshot time satisfies $t_{i,\text{prev}} < t_{j,\text{prev}}$ — article $i$ is always scraped before article $j$.

This enables monotonic tightening. For any article $i$ in a job, define:

• $t_{i,\text{prev}}^{\text{low}}$ = the maximum of $t_{i,\text{prev}}^{\text{in}}$ and the $t_{k,\text{prev}}^{\text{out}}$ for any earlier article $k < i$ in the same job. This uses the fact that if a later article's excluded edit was at time $T$, then all earlier articles in the same job must have been scraped after $T$ (otherwise that edit would have been included).
• $t_{i,\text{prev}}^{\text{high}}$ = the minimum of $t_{i,\text{prev}}^{\text{out}}$ and the $t_{k,\text{prev}}^{\text{in}}$ for any later article $k > i$ in the same job. This uses the fact that if an earlier article's included edit was at time $T$, then all later articles in the same job must have been scraped before $T$ (otherwise that edit would have been excluded).

These bounds are guaranteed to be monotonically increasing for all articles in a job — a property visible in Figure 4.

Linear fit to produce point estimates. To produce a single point estimate $\hat{t}_{i,\text{prev}}$ from the interval $[t_{i,\text{prev}}^{\text{low}}, t_{i,\text{prev}}^{\text{high}}]$, the paper fits a linear regression through the intervals of all articles in a single worker job (the blue line in Figure 4). This regression captures the steady progress of the worker through its assigned articles while smoothing out noise from the irregular timing of edits.

Evaluating Prediction Accuracy

Evaluation of previous snapshot fit (in-sample). The paper measures the maximum absolute error between the predicted time $\hat{t}_{i,\text{prev}}$ and the unknown ground truth in the interval $[t_{i,\text{prev}}^{\text{low}}, t_{i,\text{prev}}^{\text{high}}]$. This provides an upper bound on the true estimation error (since the ground truth could be anywhere in the interval). Result: On average, predictions are within 27 minutes of the furthest interval boundary. Because the true snapshot time could be anywhere in the interval, the true error is at most 27 minutes and likely smaller.

Evaluation of extrapolation to future snapshot (out-of-sample). This is the critical test: how close is the a priori predicted snapshot time $\hat{t}_i = t_0 + (\hat{t}_{i,\text{prev}} - t_{0,\text{prev}})$ to the snapshot time that could be estimated a posteriori (after the snapshot is published, using the same interval-triangulation method)? Figure 5 shows the distribution of errors for English Wikipedia: most predictions are within 30 minutes of the a posteriori estimate, but there is a systematic negative bias — predictions tend to be too early by roughly 5–15 minutes. The paper attributes this bias to snapshots slightly speeding up over time (infrastructure improvements), causing the previous snapshot's relative timing to overestimate the next snapshot's offset (i.e., articles are scraped slightly earlier in the upcoming snapshot than the linear extrapolation predicts). The paper accounts for this bias in the final success rate calculation by introducing an adjustment variable.

Estimating Reversion Speed

The second piece needed for the frontrunning attack is knowing how quickly malicious edits are reverted — this determines the window during which an edit must be made to survive until the snapshot.

Passive methodology (ethical considerations). Rather than injecting malicious edits and measuring reversion times directly (which the paper considers unethical because it would harm Wikipedia's editor community), the paper takes an entirely passive approach. The authors construct a dataset of all edits made to Wikipedia from January 2021 to June 2022 (18 months) and classify every edit as either an addition or a reversion.

Reversion classification. An edit is classified as a reversion if its edit comment contains one of a fixed set of strings frequently used in reversion comments. This set of strings is produced by manual analysis of a sample of comments from each Wikipedia language. For English Wikipedia, common strings include "revert," "rv," "undo," and variations thereof, as well as tags used by automated reversion tools. The paper acknowledges this is an imperfect classifier — some reversions may use non-standard language, and some comments containing these strings may not be genuine reversions — but it provides a conservative lower bound on the true reversion rate.

Reversion time calculation. The paper conservatively assumes that the edit being reverted was the immediately preceding edit to the same article, and measures the reversion time as the elapsed interval between these two edits. This under-reports the true reversion time because if the vandalism was from an earlier edit (e.g., there was an intervening legitimate edit before the reversion bot noticed the vandalism), the paper would incorrectly use the legitimate edit's timestamp instead, producing a shorter measured interval. Thus, the true reversion times are likely longer than the measured distribution — making the paper's success rate estimates conservative.

Results. Figure 6 plots the cumulative distribution function (CDF) of reversion times for English Wikipedia. Approximately 35% of reversions take more than 30 minutes, and the mean reversion time is approximately 2.5 hours. This is the key window: if an attacker makes an edit within roughly 30 minutes of the snapshot time, there is a ~65% chance it will be reverted before the snapshot, but a ~35% chance it will survive.

Computing the Expected Poisoning Success Rate

The paper combines the timing prediction error and reversion speed into a unified model of attack success. There are two failure modes:

Failure mode 1: Edit applied too late. The malicious edit is made after the article has already been scraped for the snapshot. Formally, if the edit time $\hat{t}_i + a > t_i$, where $\hat{t}_i$ is the predicted snapshot time, $a$ is an adjustment variable (to correct for systematic prediction bias), and $t_i$ is the true snapshot time. Since the true snapshot time is unknown, the paper conservatively uses the lower bound $t_i^{\text{low}}$ — if $\hat{t}_i + a > t_i^{\text{low}}$, the edit cannot have made it into the snapshot.

Failure mode 2: Edit applied too early. The malicious edit is made early enough that it gets reverted before the snapshot occurs. Formally, if the edit survives from its application time $\hat{t}_i + a$ until the snapshot time $t_i$ without being reverted. Since the true snapshot time is unknown, the paper conservatively uses the upper bound $t_i^{\text{high}}$ — the edit must survive until at least $t_i^{\text{high}}$ to guarantee inclusion. The probability of reversion before the snapshot is $p_{rev}(\hat{t}_i + a; t_i^{\text{high}})$, which is read directly from the empirical CDF of reversion times (Figure 6).

The success rate formula. For a set of articles $D$ and an adjustment value $a$, the fraction of malicious edits that will make it into the snapshot is lower-bounded as:

$\mathcal{A}(a) = \frac{1}{|D|} \sum_{i \in D} \left(1 - p_{rev}(\hat{t}_i + a; t_i^{\text{high}})\right) \cdot \left(1 - \mathbbm{1}[\hat{t}_i + a > t_i^{\text{low}}]\right)$

where:

• $\mathcal{A}(a)$ is the fraction of attacks that succeed (the answer enters the snapshot),
• $D$ is the set of articles being targeted,
• $|D|$ is the number of articles in that set,
• $\hat{t}_i$ is the predicted snapshot time for article $i$,
• $a$ is the adjustment variable (how much to shift the edit time relative to the prediction),
• $p_{rev}(\hat{t}_i + a; t_i^{\text{high}})$ is the probability that the edit is reverted before the snapshot upper bound $t_i^{\text{high}}$ (from the empirical reversion time CDF),
• $\mathbbm{1}[\hat{t}_i + a > t_i^{\text{low}}]$ is the indicator function that is 1 if the edit time exceeds the snapshot lower bound (edit too late), and
• $t_i^{\text{low}}$ and $t_i^{\text{high}}$ are the tightened lower and upper bounds on the true snapshot time.

What it computes: A conservative (lower-bound) estimate of the fraction of targeted Wikipedia articles that will have the attacker's malicious edit included in the upcoming snapshot. For each article, the formula checks whether the edit is applied neither too late (first indicator) nor so early that it gets reverted (second term), and averages these per-article success probabilities. The adjustment variable $a$ controls the tradeoff: negative $a$ delays the edit (reducing the "too late" failure but increasing "too early" failure), positive $a$ does the opposite.

Why this form: The formula conservatively uses upper and lower bounds on the unknown snapshot time rather than a point estimate, ensuring the computed success rate is a true lower bound. The alternative — using point estimates for $t_i$ and checking exact timing — would overstate success because it would assume the attack can hit an exact time that is only known within a 27-minute window. The conservative bound ensures the paper does not claim a higher success rate than can be guaranteed.

Optimizing the adjustment variable. The paper sweeps over potential values of $a$ (negative values, corresponding to making edits slightly earlier than the raw prediction, to account for the systematic negative bias observed in Figure 5) and takes the maximum:

$\max_a \mathcal{A}(a) = 0.065$

Result: According to this conservative analysis, an attacker could poison 6.5% of English Wikipedia documents absent any other defensive measures. This is orders of magnitude higher than the 0.01% poisoning rate shown effective in prior work.

Caveats and realism. The paper acknowledges several factors that would reduce the practical success rate below 6.5%: rate limiting of edits (Wikipedia imposes limits on how frequently a single account or IP can edit), IP bans (Wikipedia's automated systems block IPs that engage in vandalism), and the assumption of a uniformly optimal $a$ across all articles (in practice, an attacker would need to choose one adjustment strategy). However, the analysis is also pessimistic in other ways: it assumes the attacker only tries once per article, whereas a determined attacker could retry edits on targeted articles to force multiple reversions, increasing the likelihood that one edit survives into the snapshot. The paper's conclusion is not that 6.5% is achievable in practice, but that the attack surface is large enough — orders of magnitude above the 0.01% threshold — that "a successful frontrunning poisoning attack on Wikipedia snapshots is practical."

Multilingual Wikipedia Vulnerability

The paper extends the frontrunning analysis to 35 of the 39 non-English languages contained in the Wiki-40B dataset (Guo et al., 2020), a multilingual dataset frequently used to train large models. The methodology is identical — identify reversion comment strings for each language, estimate reversion time distributions, predict snapshot timing, and compute $\max_a \mathcal{A}(a)$.

Results (Figure 7). Twenty-two of the 35 languages (63%) are easier to poison than English Wikipedia, with feasible poisoning rates ranging from 0.95% to as high as 25.3%, and a median value of 8.2%. The increased vulnerability arises from two factors:

1. Smaller Wikipedias have shorter snapshot processes. A Wiki with 100,000 articles takes much less than 24 hours to snapshot, meaning the total variance in snapshot time across articles is smaller, making predictions more precise.
2. Smaller Wikipedias change less between snapshots. With fewer edits per day, the snapshot process speed is more stable across consecutive dumps, improving the accuracy of the linear extrapolation.

Some larger Wikipedias (Spanish, Danish, Italian) have poisoning rates comparable to English Wikipedia, consistent with the size effect. However, the interval-based measurement is more conservative for languages with slower edit rates because the intervals $[t_i^{\text{low}}, t_i^{\text{high}}]$ are wider when edits are infrequent, yielding very small lower bounds for some small Wikipedias like Slovak and Slovenian.

The paper notes that such large poisoning rates are unlikely to ever be achieved in practice due to IP bans and rate limiting, but the analysis demonstrates that (1) multilingual Wikipedias are vulnerable and often more vulnerable than English Wikipedia, and (2) multilingual datasets tend to rely more heavily on Wikipedia than English datasets do, compounding the risk.

---

3.4.4 Defenses

Integrity Verification for Split-View Poisoning

Defense mechanism. The maintainer (or another trusted third party) computes a cryptographic hash $h_i = H(x_i)$ of the raw data $x_i$ obtained from $url_i$ at collection time $t_i$, and publishes this hash alongside the URL and caption in the dataset index. A downloader, upon fetching $x'_i$ from $url_i$ at time $t'_i$, checks whether $H(x'_i) = h_i$. If the hashes do not match, the downloader discards that example. Here $H$ should be a cryptographic hash function such as SHA-256.

What it computes: A deterministic fingerprint of the original content that changes with high probability if the content changes. The downloader compares their received content's fingerprint to the maintainer's fingerprint and rejects mismatches.

Why this form: Cryptographic hashes provide collision resistance, preimage resistance, and second-preimage resistance — an adversary cannot practically find a different image $x'_i \neq x_i$ that produces the same hash $h_i$. This is essential because the adversary is adversarial — a perceptual hash (which tolerates small changes) would be vulnerable to adversarial examples that preserve perceptual hash values while changing the semantic content (Jain et al., 2022; Struppek et al., 2022; Hao et al., 2021). COYO-700M uses pHash (a perceptual hash) for benign image validation, but this is "not adversarially robust."

Implementation status. At the time of writing, six datasets (CC3M, CC12M, LAION-2B-en, LAION-2B-multi, LAION-1B-nolang, and LAION-400M) now release their dataset with SHA-256 hashes of the image contents. The authors also implemented hash verification in img2dataset (the dominant downloader tool responsible for 75% of requests), and provide their own backup of hashes in a Google Cloud Bucket for datasets where they possess (near-)original data.

Key limitation: Utility loss from benign changes. The paper measures the impact of hash verification on the CC3M dataset by comparing the original 2018 download to a 2023 re-download. Of the 3.3 million original images, 2.9 million are still hosted online, but only 1.1 million have hashes that match the original — the other 1.8 million images have changed since the initial dataset release due to re-encoding, cropping, resizing, or uploading higher-resolution versions. This means strict hash verification would reduce CC3M's usable size by a factor of three (from 2.9 million accessible images to 1.1 million verified images), significantly degrading utility. This creates a tension between security (cryptographic hashes catch all changes, including benign ones) and utility (perceptual hashes tolerate benign changes but are vulnerable to adversarial attacks). The paper notes that "qualitatively new defense ideas will be necessary to defend against our attacks without a high utility cost."

Timing-Based Defenses for Frontrunning Poisoning

The frontrunning attack succeeds because the duration $d = t_i - \hat{t}_i$ that an attacker must control content is very short — roughly 30 minutes given the prediction accuracy and reversion window. The defense increases $d$ beyond the moderator detection time $\Delta$, so that malicious edits are reverted before the snapshot occurs.

Defense 1: Randomized snapshot ordering. Instead of processing articles in sequential order by article ID, Wikipedia could randomize the snapshot order. This would prevent an attacker from predicting precisely when any given article will be scraped, requiring them to sustain control for the entire snapshot duration $t_n - t_0$ (roughly 24 hours for English Wikipedia) to guarantee inclusion. If snapshotting were uniformly randomized over 24 hours, only $\Delta / (t_n - t_0)$ of articles would be vulnerable to random malicious edits, where $\Delta \approx 2.5$ hours is the mean reversion time — this protects approximately 89.5% of articles. However, this assumes an attacker cannot use Sybil accounts to automatically reintroduce malicious edits after reversion, which would weaken the protection.

Defense 2: Time-gated snapshots with moderator reversion. This more comprehensive defense works as follows: the curator creates an initial snapshot of an article at time $t_i$, holds it for a period $T > \Delta$ (where $\Delta$ is the typical reversion time), and then back-applies ("cherry-picks") reversions from trusted moderators that occur within the holding period $T$ before finalizing and releasing the snapshot. Subsequent edits must be accepted only from trusted moderators to prevent selective deletion or reversion by attackers. Even a "reasonable grace period of one day" would increase the catch rate from ~50% (within 5 minutes) to ~90% (within 1 day), reducing vandalism in snapshots by a factor of 5 (from Figure 6).

Limitations. These defenses make frontrunning harder but cannot prevent it entirely because $\Delta$ is not uniform across articles. Attackers could target less active articles or languages with fewer moderators to increase success. Furthermore, the defenses hinge on trusted moderators who can detect malicious edits — this may fail if an attacker introduces imperceptible changes that affect machine understanding but appear valid to human review.

General Poisoning Prevention

For more general web-scale datasets like Common Crawl (which lacks a trusted golden snapshot and trusted moderators), the paper proposes consensus-based approaches — only trusting an image-caption pair if it appears on many different websites, requiring an attacker to poison a sufficiently large number of similar websites. This mirrors consensus mechanisms in distributed systems like blockchains (Narayanan et al., 2016). However, the paper defers application-specific solutions to future work, noting that any solution requires downstream knowledge of how URL content is consumed, vectorized, and deconflicted during training.

Transparency for Ecosystem-Wide Trust

The paper proposes a longer-term vision of dataset transparency modeled on certificate transparency (Laurie, 2014). A transparency log for the set of $\{(url_i, c_i, h_i)\}$ distributed to clients would prevent a compromised maintainer from distributing different datasets to different clients, assist in detecting inaccurate captions $c_i$ or expired URLs over time, and enable auditing of dataset integrity. For centralized datasets, curators could engage in a similar process to ensure all clients receive identical corpora. The paper also notes that binary transparency (Al-Bassam and Meiklejohn, 2018) for downloader tools like img2dataset would prevent selective inclusion of malicious downloader modules. Such transparency would prepare the ecosystem for a future where "multiple maintainers and curators continuously update web-scale datasets, rather than the current reliance on centralized entities and static datasets."

---

3.4.5 Ethical Considerations in the Measurement Study

The paper explicitly addresses ethical considerations for both attacks:

Split-view poisoning. The authors do not actually poison any datasets. For all purchased domains, the server returns a 404 Not Found response, which causes standard image downloading tools to skip the image entirely — from the perspective of a dataset downloader, the domain purchase is transparent. A robots.txt file discourages typical web crawlers. A request to the root domain returns a 403 Forbidden with a response body explaining this is a research study, listing a contact email, and offering to return the domain to the original owner if it was allowed to expire accidentally. No contact has been received on this address. The data collection is minimally invasive: DNS requests are limited to 500/second, cost queries are made only for the top 10,000 domains per dataset, and only 6 domains are eventually purchased per dataset. The study was deemed "exempt" by the authors' institutional IRB.

Frontrunning poisoning. All actions are entirely passive — the authors make no edits to Wikipedia and, aside from downloading datasets from official sources, never interact with Wikipedia. While this passive methodology introduces limitations (e.g., the reversion time estimation is less accurate than active measurement would be), the authors believe "this is the correct way to run such a study to avoid harming the Wikipedia editor community." The attack analysis and defense recommendations were disclosed to researchers at Wikimedia, who acknowledged the vulnerability before the paper's release.

4. Key Insights and Innovations

Innovation 1: Reframing Dataset Distribution Architecture as the Attack Surface

The paper's most fundamental conceptual contribution is identifying that the mechanism by which a dataset is distributed — not the dataset's content, size, or curation — is the primary security vulnerability enabling poisoning. Prior to this work, the poisoning literature treated datasets as abstract collections of examples; the question of how an adversary injects poisoned samples was either assumed as pre-existing access or delegated to out-of-scope supply-chain compromises. This paper demonstrates that the distribution architecture itself — specifically, the gap between index publication time and content download time — is the exploitable primitive.

This reframing matters because it fundamentally changes what "dataset security" means. Before this work, securing a dataset meant curating its content (filtering harmful examples) or hardening the training pipeline (defending against poisoned models). The paper shows that neither addresses the actual vulnerability: an adversary can guarantee their content enters a dataset without ever touching the curation process or the training pipeline, simply by exploiting the temporal decoupling between when a maintainer indexes content and when a client downloads it. The dataset index is immutable from the adversary's perspective, but the content it points to is not — and that asymmetry is the attack surface.

The authors crystallize this insight with a C-type analogy in Section 4: the community treats these URL-based datasets as int const * (a fixed pointer to unchanging content), when in reality they are int * const (a fixed pointer to content that can change). This is not merely a vivid metaphor — it diagnoses the exact trust assumption that every prior poisoning paper made implicitly and that every web-scale dataset violates in practice. The field had been reasoning about dataset integrity as if the content were static, when the distribution mechanism provides no such guarantee.

What makes this insight diagnostic rather than merely descriptive is that it predicts vulnerability across an entire class of datasets without requiring per-dataset analysis. The paper identifies two distribution architectures — distributed (URL indices) and centralized (periodic snapshots) — and for each, the vulnerability follows directly from the architecture. Any distributed dataset without cryptographic integrity verification is vulnerable to split-view poisoning; any centralized dataset with predictable snapshot timing is vulnerable to frontrunning. The paper validates this diagnostic by testing it on 10 diverse datasets spanning different modalities (images, text), sizes (millions to billions of samples), ages (2010–2023), and curation levels — all are vulnerable. The prediction is not weakly probabilistic; it is structural.

Innovation 2: Establishing That Guaranteed Poisoning Is Achievable Without Specialized Capabilities

The paper's second innovation is the empirical demonstration that an adversary with no insider access, no specialized infrastructure, and a budget of $60 USD can guarantee — not merely hope — that their poisoned content will enter a web-scale training dataset. This transforms poisoning from a theoretical threat model into a demonstrated attack vector with concrete cost estimates.

The significance of this finding lies in what it violates about the community's implicit assumptions. Prior to this work, the reasonable default assumption would have been that poisoning a dataset like LAION-400M (400 million images) requires either compromising the dataset maintainer, guessing which URLs will be crawled, or poisoning such a vast number of random web pages that some are statistically likely to be included. Each of these requires capabilities or resources that exceed what a "low-resource adversary" (the paper's threat model) could deploy. The paper shows this assumption is false: the adversary does not need to guess, because the dataset index tells them exactly which URLs to target. And they do not need to compromise anyone, because DNS expiration is a natural, unavoidable process that transfers ownership without any attack.

This is a qualitative shift in threat assessment, not merely a quantitative refinement. The $60 USD figure is striking, but the deeper insight is the mechanism: expired domains convert the passage of time into adversarial control. Domain registrations are inherently temporary — they expire continuously as owners forget to renew, organizations dissolve, or hosting providers go bankrupt. No amount of dataset curation can prevent this, because the curator does not own the domains and cannot force renewal. The paper demonstrates that the fraction of expired domains grows with dataset age (VGG Face from 2015: 3.70% expired; PubFig from 2010: 6.48%), and crucially, that it is non-zero even on release day (COYO-700M: 0.1% on the day of publication, because the crawling process took nearly a year). This means the vulnerability is not a bug that can be patched with better curation — it is a structural property of any dataset that points to external URLs.

The paper's passive monitoring study adds a second dimension to this insight by demonstrating sustained vulnerability: datasets continue to be downloaded years after publication, with even the oldest datasets seeing at least 3 downloads per month. Over six months, the authors could have poisoned over 800 downloads. This refutes the plausible counterargument that while the vulnerability existed, it was only transient — that most downloads occurred soon after publication when fewer domains were expired. The monitoring data shows that fresh downloads, and thus fresh opportunities for poisoning, are ongoing.

Innovation 3: Demonstrating That Frontrunning Exploits Predictability, Not Just Timing

The frontrunning poisoning attack introduces a conceptual move that is distinct from (and subtler than) the split-view attack: the adversary does not need sustained control over a web resource; they only need transient control at a predictable time. This is not merely a different attack mechanism — it is a different class of vulnerability, one that arises from the interaction between crowdsourced content moderation and deterministic snapshot processes.

What makes this innovative is the inversion of the usual temporal trust assumption. In most security contexts, the assumption is that content is trustworthy at the time it is served, and the risk is that it might be modified later (man-in-the-middle attacks, server compromise). Frontrunning inverts this: the content is untrustworthy at the moment of snapshot, but will be made trustworthy later (by moderator reversion) — however, the snapshot freezes the untrustworthy version permanently. The snapshot process, designed to provide a stable, reproducible artifact for researchers, inadvertently preserves adversarial modifications that the live moderation system would have corrected.

The technical heart of this insight is the predictability of the snapshot timing. The paper shows that Wikipedia's snapshot process is not merely periodic (1st and 20th of each month) but deterministically sequential and linearly scannable — articles are processed in strict ID order within parallel jobs, and the relative timing (article offset from snapshot start) is preserved across consecutive dumps with only ~30 minutes of error. This level of predictability is not obvious a priori; one might reasonably assume that parallel jobs introduce sufficient randomness or that infrastructure changes make inter-dump extrapolation unreliable. The paper's empirical demonstration that predictions are accurate to within 30 minutes (Figure 5) — despite the snapshot taking ~24 hours across 6+ million articles — is a non-trivial finding about the operational characteristics of a major internet infrastructure.

The multilingual extension (Figure 7) strengthens the conceptual point by showing that the vulnerability scales inversely with community size: smaller Wikipedias with fewer moderators and shorter snapshot durations are more vulnerable, with poisoning rates up to 25.3% compared to 6.5% for English. This establishes a general principle: the frontrunning attack succeeds to the extent that the snapshot process is predictable and the moderation latency is high, both of which are more pronounced in languages with fewer resources. This is not a corner case — it is a structural inequality in the vulnerability surface.

Innovation 4: Validating That Dataset Distribution Infrastructure Is the Missing Link in Poisoning Research

The paper's fourth innovation is less about any single attack and more about what it does to the entire poisoning literature: it provides the connecting tissue between theoretical poisoning attack models and real-world deployment feasibility. By demonstrating practical, low-cost attack vectors for guaranteed dataset poisoning, the paper validates that the threat models assumed in prior work (Carlini and Terzis, 2021; Carlini, 2021; Schuster et al., 2021; and dozens of others) are not merely academic exercises — they are realistic scenarios that could be executed against production training pipelines today.

The significance of this goes beyond "poisoning is possible." The paper shows that the specific constraints of real-world attacks — the adversary cannot modify captions, cannot choose which URLs are in the index, cannot add new URLs — do not prevent effective poisoning. The proof-of-concept training run (Appendix B) demonstrates a 60% success rate for targeted misclassification and 90% success for NSFW filter bypass at a poisoning rate of 0.0025%, well within the 0.01%–0.79% range achievable for under $1,000 USD. This closes a critical gap in the literature's chain of reasoning: prior work showed that if you can poison X% of a dataset, you can achieve effect Y; this paper shows that X% is achievable in practice.

Equally important is what the paper does not find: no evidence of past exploitation (Section 4.4). Across CC3M and LAION-400M, searching for the signature of domain-purchase-based poisoning (modified images + changed ownership) yields no malicious instances. This is simultaneously reassuring and alarming — reassuring because it suggests the attack has not been weaponized, alarming because the vulnerability has existed for years without the community noticing. This finding reframes the security posture of web-scale datasets from "secure because no attacks have occurred" to "insecure but not yet exploited" — a critical distinction that changes the urgency of deploying defenses.

The paper's meta-review (Appendix D) and response (Appendix E) make explicit what is implicit throughout: the attack "appears effective only in situations where standard integrity protection measures are absent" — and it "just so happens that this includes every large scale dataset ever released in the last decade." This is the paper's most pointed critique of the field: the defenses are known (cryptographic hashes), but they are not deployed because they conflict with utility (hash verification reduces CC3M's usable size by 3× due to benign content changes). The security-utility tension is not a failure of imagination but a genuine tradeoff that the field has not yet resolved.

Innovation 5: Conceptualizing Difficulty-Agnostic, Architecture-Specific Attack Vectors

A subtle but important conceptual contribution is the paper's demonstration that effective poisoning attacks need not be tailored to the content, difficulty, or domain of a dataset — they can exploit structural properties of the dataset's distribution architecture, which are independent of the data modality or task. This contrasts sharply with the dominant approach in the poisoning literature, where attacks are typically crafted to exploit specific properties of the model architecture, training objective, or data distribution (e.g., gradient-matching in Geiping et al., 2020; clean-label constraints in Shafahi et al., 2018; stealth in Turner et al., 2019).

The split-view attack works identically whether the dataset contains images, text, audio, or video; whether it is used for classification, contrastive learning, or generative modeling; whether it was released in 2015 or 2023 — the only prerequisite is that the dataset points to URLs whose domains can expire. The frontrunning attack works on any periodically snapshotted corpus with predictable collection timing, regardless of what the corpus contains. This architecture-level attack surface is orthogonal to the content-level attack surface that prior work focused on, meaning that even if content-based poisoning defenses were perfected, these attacks would still succeed unless the distribution infrastructure is changed.

This insight has a prescriptive implication: dataset security requires reasoning about the supply chain of data, not just its content. The paper's defense proposals (integrity hashes, randomized snapshots, time-gated releases, transparency logs) are all supply-chain interventions — they secure the process by which data moves from source to training set, rather than attempting to detect poisoned content after the fact. This represents a shift from content-filtering (predominant in prior work on defending against poisoning) to process-integrity (ensuring the dataset you download is the dataset the maintainer intended). The paper's responsible disclosure section, where six datasets now ship with SHA-256 hashes and img2dataset supports hash verification, demonstrates that this shift is actionable in practice.

5. Experimental Analysis

Evaluation Methodology

• Datasets. The paper studies 10 popular web-scale datasets, listed in Table I: MMC4-FF (375M samples, released 2023+), Falcon RefinedWeb (276M, 2023+), OBELISC (353M, 2023+), LAION-2B-en (2,323M, 2022), LAION-2B-multi (2,266M, 2022), LAION-1B-nolang (1,272M, 2022), COYO-700M (747M, August 2022), LAION-400M (408M, 2021), Conceptual 12M (12M, 2021), CC-3M (3.3M, 2018), VGG Face (2.6M, 2015), FaceScrub (0.10M, 2014), and PubFig (0.06M, 2010). The first nine are multimodal image-text datasets where each entry is a (URL, caption) tuple; the last three are face recognition datasets associating images with celebrity identities. The selection spans varying ages, sizes, and modalities to test whether vulnerability is architecture-dependent rather than content-dependent. For the frontrunning attack, the primary target is English Wikipedia snapshots (the 1st and 20th of each month), with extension to 35 multilingual Wikipedias from the Wiki-40B dataset.

• Base model(s). The proof-of-concept poisoning demonstration (Section 4.5, Appendix B) trains one OpenCLIP model using a ViT-B-32 architecture for 32 epochs at a batch size of 3,072 on 16 A100 GPUs. This model is chosen as a representative contrastive vision-language model trained on LAION-400M, matching the training paradigm used by production systems like CLIP and Stable Diffusion's safety filter. The paper does not train models for the frontrunning attack — that evaluation is purely a feasibility analysis of whether malicious edits would survive into Wikipedia snapshots, not a demonstration of downstream model impact.

• Metrics. For split-view poisoning, the primary metrics are: (1) fraction of dataset images hosted on expired and buyable domains (%), computed as the number of images whose domains return NXDOMAIN DNS responses divided by total dataset size; (2) fraction of dataset purchasable for ≤$1,000 USD (%), computed by greedily selecting domains in decreasing images-per-dollar order; (3) downloads per month (count), measured via the precision-recall filter on passive server logs; (4) poisoning success rate for proof-of-concept training (%), computed as the fraction of targeted images that achieve the desired misclassification. For frontrunning poisoning, the primary metric is the fraction of Wikipedia articles whose predicted snapshot time falls within the reversion window: max_a A(a), the maximum (over adjustment variable a) of the per-article probability that a malicious edit is neither too early (reverted) nor too late (missed), lower-bounded using the conservative interval method described in Section 3.4.3.

• Baselines. The split-view poisoning measurement has no direct baselines — it is an attack-surface quantification rather than a comparative method. The domain expiration rate is compared against the 0.01% poisoning threshold established in prior work (Carlini and Terzis, 2021) as the minimum effective poisoning rate for uncurated datasets. For the proof-of-concept, the implicit baseline is a clean model trained on unpoisoned LAION-400M, where the targeted images should be classified correctly (for object misclassification) or as safe (for NSFW filtering). The frontrunning poisoning uses the Wikipedia snapshot inclusion as the binary ground truth: an edit either appears in the dump or does not, and the baseline is the random-timing strategy where an adversary makes edits at arbitrary times with essentially zero probability of hitting the snapshot window.

• Generation budget / compute accounting. The paper does not use "generations" as a compute unit. For split-view poisoning, the primary resource is monetary cost (USD), measured via Google Domains pricing in July 2023. The attack cost is computed by dividing the total purchase price of selected domains by the number of images they host, ranking domains by cost-per-image, and determining the cumulative fraction of each dataset purchasable for ≤$60 (Figure 1) or ≤$1,000 (Table I). For the passive monitoring study, the resource is time: 12 months of server operation beginning August 2022, receiving approximately 15 million requests per month (6 requests/second). For frontrunning poisoning, the resource is prediction accuracy: the window of timing error (~30 minutes) relative to the reversion time distribution (~35% of reversions take >30 minutes). The proof-of-concept training run's compute is 32 epochs × 3,072 batch size × 400M images on 16 A100 GPUs, but this is not the cost metric being optimized — it merely demonstrates that the achievable poisoning rates are sufficient.

• Cross-validation / statistical protocol. The paper's experimental protocol is measurement-focused rather than model-training-focused, so cross-validation in the traditional ML sense does not apply. Instead, the key methodological safeguards are: (1) DNS lookups performed from two geographically distinct datacenters at two time points (May 2022 and August 2022), with a domain classified as expired only if all four lookups return NXDOMAIN — this reduces false positives from transient DNS failures; (2) the precision-recall filter for identifying dataset downloads, which requires both ≥90% recall (downloader accessed ≥90% of URLs controlled by the authors for that dataset, including at least one URL from each of 6 independently purchased domains) and ≥50% precision (≥50% of requests from that IP to the authors' domains were to dataset URLs) — this is deliberately conservative, likely undercounting true downloads but providing high confidence in flagged ones; (3) for frontrunning timing predictions, the evaluation uses an a posteriori estimate (retrospectively computed from the snapshot that was being predicted) as the comparison point, measuring the error between a priori predictions and a posteriori estimates; (4) the success rate formula A(a) uses conservative upper and lower bounds on the true (unknown) snapshot time rather than point estimates, ensuring the reported 6.5% is a true lower bound; (5) two-fold logic is not used for strategy selection as in the example paper — instead, the optimal adjustment variable a is selected by sweeping over possible values and taking the maximum over the same evaluation set, and the paper acknowledges this "cheat" while arguing that an attacker could use more historical data to produce good estimates of a similarly.

Main Quantitative Results

5.1 Split-View Poisoning: Attack Surface Quantification

Headline finding: For $60 USD, at least 0.01$1,000 USD, between 0.02% and 0.79% is purchasable.

Table I reports the fraction of images hosted on expired and buyable domains for each of the 10 studied datasets, with the rightmost columns reporting what fraction can be purchased for a total cost of $1,000 USD. The results are:

• LAION-400M (2021): 0.71% of images hosted on expired domains, ≥0.05% purchasable for $1,000.
• COYO-700M (2022): 1.51% expired, ≥0.10% purchasable for $1,000.
• LAION-2B-en (2022): 0.29% expired, ≥0.01% purchasable for $1,000.
• LAION-2B-multi (2022): 0.55% expired, ≥0.02% purchasable for $1,000.
• LAION-1B-nolang (2022): 0.37% expired, ≥0.02% purchasable for $1,000.
• Conceptual 12M (2021): 1.19% expired, ≥0.12% purchasable for $1,000.
• CC-3M (2018): 1.04% expired, ≥0.08% purchasable for $1,000.
• Falcon RefinedWeb (2023+): 0.24% expired, ≥0.02% purchasable for $1,000.
• MMC4-FF (2023+): 0.14% expired, ≥0.01% purchasable for $1,000.
• OBELISC (2023+): 0.09% expired, ≥0.01% purchasable for $1,000.
• VGG Face (2015): 3.70% expired, ≥0.17% purchasable for $1,000.
• FaceScrub (2014): 4.51% expired, ≥0.61% purchasable for $1,000.
• PubFig (2010): 6.48% expired, ≥0.32% purchasable for $1,000.

The key pattern is the relationship between dataset age and vulnerability: older datasets have more expired domains (PubFig: 6.48%; VGG Face: 3.70%) while newer datasets have fewer (OBELISC: 0.09%; MMC4-FF: 0.14%). However, even the newest datasets exceed the 0.01% threshold established as effective in prior poisoning work.

Figure 1 plots the fraction of each dataset purchasable as a function of the adversary's budget (USD), with domains selected in decreasing images-per-dollar order. The $60 threshold is marked: for every dataset, at least 0.01$60. For example, LAION-400M reaches approximately 0.05% at $60 and approximately 0.08$1,000; COYO-700M reaches approximately 0.02% at $60 and approximately 0.12$1,000.

Vulnerable from day zero: the COYO-700M case. When COYO-700M was released on August 30, 2022, the authors computed on that same day that already 0.1% of images were hosted on expired domains that cost fewer than $1,000 USD to purchase (reported in Section 4.2). This is because the dataset collection process took nearly a year, during which domains expired — the vulnerability exists from the moment of release, not just for aging datasets.

5.2 Split-View Poisoning: Download Frequency and Impact

Headline finding: Over 800 dataset downloads were observed during the passive monitoring period, with even the oldest datasets receiving at least 3 downloads per month.

The rightmost column of Table I reports the number of downloads observed per month via the precision-recall filter on passive server logs. Results across datasets:

• Conceptual 12M: ≥33 downloads per month
• CC-3M: ≥29 downloads per month
• PubFig: ≥15 downloads per month
• LAION-400M: ≥10 downloads per month
• FaceScrub: ≥7 downloads per month
• LAION-2B-en: ≥7 downloads per month
• COYO-700M: ≥5 downloads per month
• LAION-2B-multi: ≥4 downloads per month
• VGG Face: ≥3 downloads per month
• LAION-1B-nolang: ≥2 downloads per month

Newer datasets are requested more often (Conceptual 12M at 33/month vs. VGG Face at 3/month), while older datasets have a larger fraction of purchasable data (VGG Face at 3.70% vs. Conceptual 12M at 1.19%). This creates a tradeoff for attackers: newer datasets offer more downloaders to victimize but a smaller fraction of purchaseable images; older datasets offer more images per dollar but fewer downloaders.

The billion-image datasets (LAION-2B-en, LAION-2B-multi) are downloaded less frequently than smaller recent datasets. The paper explains this is because these massive datasets are rarely downloaded in their entirety — they serve as upstream sources for subsets like PMD and LAION-Aesthetics, which use subsets of the URLs. This explains IP addresses with high precision (systematic downloading of a specific subset) but low recall (not accessing all URLs the authors control, since those URLs may not be in the subset being downloaded).

User-agent analysis confirms dominant download tool. The user agent responsible for 77% of traffic — Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0 — is hardcoded in img2dataset, the most popular dataset crawler. This specific Firefox version (72, released February 2020) makes it highly unlikely these requests are from actual browsers.

Visual confirmation of dataset downloads. Figure 2 plots URL access time versus URL rank in the dataset index, color-coded by IP address, for Conceptual 12M. The plot shows clear diagonal lines — IP addresses accessing URLs in strict sequential order matching the dataset index. Because the index ordering is random (not alphabetical or topical), this linear access pattern is strong independent confirmation of dataset downloading. The figure also reveals variability in download speed (some crawlers complete in hours, others in weeks), parallel chunking behavior (multiple diagonal segments at different vertical positions occurring simultaneously), and pause-resume patterns.

No evidence of past exploitation. Section 4.4 searches for the signature of split-view poisoning across CC3M and LAION-400M: domains that both (1) host images that changed since initial release and (2) changed ownership since release. On CC3M, using perceptual similarity (CLIP cosine similarity), just one domain showed this signature, and it was a domain squatter serving ads — not targeted poisoning. Using cryptographic hash comparison (which catches benign re-encoding), two additional domains showed changes, but further investigation revealed ownership had not changed — only DNS lapses and image re-encoding occurred. On LAION-400M, 4.1–4.2 million of 5.6 million domains hosted at least one modified image by the first and second post-release snapshots (CLIP cosine similarity <0.99), totaling 175M–183M modified images. Sampling domains, including the 700 with the most modifications, found no malicious pattern — domains were still owned by original owners, for sale, or redacted, but none showed signs of targeted poisoning.

5.3 Proof-of-Concept: Does the Purchasable Fraction Enable Effective Poisoning?

Headline finding: At a poisoning rate of 0.0025% of LAION-400M (10,000 images, well within the $1,000 budget), targeted misclassification succeeds for 60% of targets and NSFW filter bypass succeeds for 90% of targets.

The proof-of-concept trains one OpenCLIP ViT-B-32 model on LAION-400M with simulated poisoned images. Two attack objectives are tested:

Object-misclassification objective (10 target ImageNet classes, 1,000 poisoned images each, total 10,000 images = 0.0025% of dataset): For each target class (e.g., "apple"), the authors select 1,000 caption-image pairs from buyable domains where the caption contains the class name, ensuring total domain cost across all 10 classes is ≤$1,000 USD. A single unrelated image is substituted for all 1,000 images in each class's set. After training, the zero-shot CLIP classifier's accuracy on the targeted image is measured — the attack succeeds if the target image is classified as the poisoned label. Result: 60% attack success rate (6 of 10 targets successfully misclassified).

NSFW objective (10 benign images, 1,000 poisoned images each, total 10,000 images = 0.0025% of dataset): For each benign image, the authors select 1,000 caption-image pairs from buyable domains where the captions are labeled UNSAFE in LAION-400M metadata. The benign image is substituted for all 1,000 images in each set. After training, the Stable Diffusion Safety Filter's classification of each benign image is measured — the attack succeeds if the filter labels the image as NSFW. Result: 90% attack success rate (9 of 10 benign images successfully misclassified as NSFW).

These results are reported directly in Section 4.5 and Appendix B without a dedicated figure — they serve to bridge the measured attack surface (0.01%–0.79% purchasable for $1,000) with the known effectiveness threshold from prior work (0.01% is sufficient; Carlini and Terzis, 2021). The constraining factor — that the adversary can modify images but not captions — does not prevent success, because the existing captions provide sufficient semantic signal for the contrastive objective to learn the poisoned association.

5.4 Frontrunning Poisoning: Timing Prediction Accuracy

Headline finding: Wikipedia article snapshot times can be predicted to within approximately 30 minutes, with a systematic negative bias (predictions tend to be too early).

Evaluation of previous snapshot fit (in-sample): For the linear regression used to estimate each article's snapshot time in the previous dump, the maximum absolute error between the predicted time and the unknown ground truth (bounded by the interval [t_prev^low, t_prev^high]) is 27 minutes on average (Section 5.2.4, Figure 4). Because the true snapshot time could be anywhere within this interval, the true error is at most 27 minutes and likely smaller.

Evaluation of extrapolation to future snapshot (out-of-sample): Figure 5 shows the distribution of errors between a priori predicted snapshot times t̂_i = t_0 + (t̂_{i,prev} - t_{0,prev}) and the a posteriori estimated snapshot times (computed after the snapshot is published using the same interval-triangulation method). The results are:

• Most prediction errors fall within ±30 minutes.
• The distribution is negatively biased — predictions tend to be too early by approximately 5–15 minutes, with a heavier left tail. This is attributed to snapshots slightly speeding up over time (the English Wikipedia infrastructure improves, causing later snapshots to complete faster than linear extrapolation from the previous dump would predict).
• The standard deviation of errors is roughly 15–20 minutes (read from Figure 5's histogram).

The paper does not report exact error statistics in the text; the numbers above are interpreted from Figure 5 (histogram) and the statement that "most predicted checkpoint times are within 30 minutes of our constructed ground truth" (Section 5.2.4).

5.5 Frontrunning Poisoning: Reversion Speed

Headline finding: Approximately 35% of Wikipedia malicious edits take more than 30 minutes to revert; the mean reversion time is approximately 2.5 hours.

Figure 6 plots the cumulative distribution function (CDF) of reversion times for English Wikipedia over 18 months of edit history (January 2021 – June 2022). Key percentiles (read from the CDF plot):

• ~20% of reversions occur within 1 minute.
• ~50% occur within 5 minutes.
• ~65% occur within 30 minutes.
• ~80% occur within 1 day.
• ~90% occur within 1 week.

The mean reversion time is approximately 2.5 hours (stated in Section 6.3 as the "average review time to detect vandalism Δ").

These measurements are conservative: the paper classifies reversions by edit comment string matching (imperfect recall — some reversions use non-standard language) and assumes the reverted edit was the immediately preceding edit to the same article (which under-reports reversion time if an intervening legitimate edit occurred). The true reversion time distribution is likely to have a longer tail than measured.

5.6 Frontrunning Poisoning: Combined Success Rate

Headline finding: Under conservative assumptions, 6.5% of English Wikipedia articles could be poisoned absent other defensive measures.

The success rate formula A(a) (Section 5.4) combines the timing prediction accuracy and reversion speed into a per-article probability of success, parameterized by the adjustment variable a that shifts edit times relative to the raw predictions. Sweeping over a and taking the maximum:

$\max_a \mathcal{A}(a) = 0.065$

This means that 6.5% of English Wikipedia articles could be targeted with a malicious edit that would be included in the upcoming snapshot — the edit is applied neither too late (after snapshot) nor so early that it gets reverted before the snapshot. This is 650× higher than the 0.01% threshold required for effective poisoning.

The optimal adjustment value a is negative (edits are made slightly earlier than the raw prediction), which compensates for the systematic negative bias observed in Figure 5 — since predictions tend to be too early, making edits slightly earlier than the prediction would make them miss the snapshot, so the optimal strategy is to actually make edits slightly earlier to avoid the "too late" failure mode while accepting some "too early" reversions.

The paper's calculation uses the conservative lower and upper bounds [t_i^low, t_i^high] rather than point estimates, and uses the empirical reversion CDF conservatively (the p_rev function assumes the edit must survive until the upper bound t_i^high, which is the latest possible snapshot time for that article within the tightened interval). This ensures 6.5% is a true lower bound on the number of articles whose edits could survive.

Multilingual extension (Figure 7): Applying the same methodology to 35 non-English languages in Wiki-40B yields:

• 22 of 35 languages (63%) are easier to poison than English Wikipedia, with feasible poisoning rates ranging from 0.95% to 25.3% and a median of 8.2%.
• The most vulnerable languages (with rates >15%) include smaller Wikipedias with fewer articles and shorter snapshot durations, making prediction more precise.
• Larger Wikipedias (Spanish, Danish, Italian) have comparable poisoning rates to English Wikipedia (~5–7%).
• Some small Wikipedias (Slovak, Slovenian) have very small lower bounds, likely because infrequent edits produce wide time intervals, making the conservative bound overly pessimistic.

The paper does not report individual language-by-language numbers in the text; Figure 7 shows them as a bar chart with rates ranging from near 0% (Slovenian) to approximately 25.3% (the maximum bar).

Ablation Studies and Robustness Checks

• Domain expiration measurement robustness (two datacenters, two time points). The DNS expiration check uses four independent nslookup queries (two datacenters × two time points: May 2022 and August 2022), with a domain classified as expired only if all four return NXDOMAIN. This reduces false positives from transient DNS failures, misconfigured resolvers, or temporary outages. The paper does not report the false positive rate (i.e., what fraction of domains were NXDOMAIN at one datacenter but not the other), so the reliability of this filter cannot be independently assessed from the paper.

• Download identification filter sensitivity (precision-recall tradeoff). The paper reports the effect of progressively tightening the download identification criteria for CC-3M (Section 4.3): raw traffic yields 51,000 image requests/month from 2,401 IPs; adding the precision constraint alone (≥50% of requests to dataset URLs) reduces this to 2,007 IPs and 43,000 requests; adding the recall constraint alone (≥90% of controlled URLs downloaded) reduces this to 70 IPs and 32,000 requests; both together yield 64 IPs and 28,000 requests. The large drop from precision-only to recall-only filtering (2,007 → 70 IPs) indicates that many IPs systematically download some dataset URLs but not the specific URLs the authors control (likely because they are downloading subsets). The paper does not evaluate the false negative rate — how many genuine dataset downloads are missed by this filter — because there is no ground truth for who is actually downloading each dataset. The assumption that single-IP downloads dominate may underestimate the true download rate if users distribute crawling across multiple IPs.

• COYO-700M day-zero expiration measurement. To verify that the vulnerability exists from release day rather than developing over years, the authors measure expired domains in COYO-700M on its release date (August 30, 2022) and find 0.1% of images hosted on expired domains purchasable for ≤$1,000. This serves as an "ablation" of the hypothesis that aging causes vulnerability — it demonstrates that even brand-new datasets are vulnerable because the crawling-to-release pipeline spans months during which domains lapse. This measurement is a single datapoint (one dataset, one release date) rather than a systematic study across releases.

• Reversion classification methodology (string-matching vs. ground truth). The reversion detection uses edit comment string matching rather than ground-truth annotation. The paper does not report the precision or recall of this classifier against human-labeled reversions, making it difficult to assess how much the measured reversion time distribution deviates from the true distribution. The methodology is conservative (likely undercounts reversions because not all reversions use standard language), which would cause the paper to underestimate the reversion rate and thus overestimate the poisoning success rate (edits survive longer than the measured distribution implies). However, the conservative assumption that the reverted edit is always the immediately preceding edit underestimates reversion times (if vandalism was from an earlier edit), which would cause underestimation of success rate. The net direction of bias is unclear.

• Timing prediction extrapolation bias. Figure 5 shows that predictions are systematically too early (negative bias of approximately 5–15 minutes). The paper attributes this to snapshots speeding up over time and accounts for it by sweeping the adjustment variable a and taking the maximum over a. However, the sweep is over a values only — it does not model the rate of speedup, does not incorporate multiple historical snapshots to estimate trends, and does not evaluate whether the speedup is monotonic or variable across snapshots. An ablation using multiple historical snapshots to fit a trend-corrected prediction model is not performed.

• Proof-of-concept poisoning with constraint on captions. The poisoning demonstration (Section 4.5, Appendix B) operates under an important constraint that prior work did not impose: the adversary can modify images but not their captions (since captions are fixed in the dataset index). Prior work (Carlini and Terzis, 2021) assumed the adversary could modify both images and captions. The 60% and 90% success rates demonstrate that this tighter constraint does not prevent effective poisoning — the existing captions contain sufficient semantic signal. However, this is tested for only two attack objectives (ImageNet zero-shot classification and NSFW filtering), both on a single model architecture (ViT-B-32 CLIP), at a single poisoning rate (0.0025% per target). Whether the constraint would bind more strongly for other objectives, architectures, or lower poisoning rates is not tested.

• No ablation on the number of domains purchased (6 per dataset). The monitoring infrastructure uses 6 domains per dataset (3 most popular, 3 random). The paper does not evaluate how the download detection rate would change with more or fewer domains — would 3 domains suffice? Would 12 domains catch significantly more downloads? The choice of 6 is pragmatic rather than empirically justified.

• No evaluation of defense-utility tradeoff at scale. The paper reports that applying SHA-256 integrity verification to CC-3M reduces the usable dataset from 2.9 million accessible images to 1.1 million verified images (a factor of 3 reduction) because 1.8 million images have changed benignly (re-encoding, resizing, cropping). This is presented as a limitation of the defense, but the paper does not ablate which types of benign changes cause the most hashing failures (re-encoding vs. resizing vs. content replacement), nor does it evaluate whether a more permissive defense (e.g., accepting images whose perceptual hash matches while flagging those that don't for manual review) could recover utility while maintaining meaningful security. The tension between cryptographic integrity and utility is identified but not explored quantitatively.

Critical Assessment

Does the paper demonstrate that poisoning web-scale training datasets is practical?

The demonstration is strongest for the attack surface — showing that the necessary preconditions exist — and weaker for the end-to-end attack — showing that an adversary could actually execute the full pipeline and cause harm without detection.

For split-view poisoning, the paper convincingly demonstrates three necessary conditions: (1) a substantial fraction of images in popular datasets are hosted on expired, buyable domains (0.01%–0.79% for $1,000, Table I; 0.01$60, Figure 1); (2) these datasets continue to be downloaded regularly, with over 800 downloads observed over six months (Table I, rightmost column); and (3) the fraction of control achievable is sufficient for effective poisoning, with proof-of-concept attacks succeeding at 60% and 90% rates using only 0.0025% of LAION-400M (Section 4.5, Appendix B). Each of these conditions is individually well-supported by the measurements.

However, the paper does not demonstrate an end-to-end attack. No actual poisoned models were deployed; no downstream users were affected; no malicious content was served from purchased domains (the servers returned 404). This is explicitly an ethical choice, not an experimental limitation — the authors state they "do not actually poison any datasets" and designed the study to be minimally invasive. The proof-of-concept training run substitutes poisoned images locally rather than through actual domain ownership, simulating what an adversary could do. This is reasonable for a measurement study, but it means the paper demonstrates feasibility of the attack infrastructure rather than feasibility of an undetected real-world poisoning campaign.

Several practical obstacles to real-world execution are not empirically tested:

• Detection risk during domain purchase and content serving. Would a dataset downloader or maintainer notice that a previously benign domain now serves 404 errors (or poisoned content)? The paper argues that 404s cause standard downloaders to skip the image, making the transition transparent — but this is asserted, not tested. An adversary serving poisoned images (rather than 404s) would be more detectable, since the new content would differ from cached versions or expected distributions.
• Adversarial identification risk. The paper's attack requires the adversary to purchase domains, set up HTTPS certificates from LetsEncrypt, and serve content — activities that leave records with domain registrars, certificate authorities, and hosting providers. The paper does not analyze whether these records could be used to identify an attacker after the fact, or whether the attack could be executed with sufficient anonymity.
• Scale of poisoning vs. scale of detection. The paper shows that poisoning 0.0025% of LAION-400M (10,000 images) is achievable and effective. But 10,000 image substitutions requires purchasing and operating a non-trivial number of domains — the paper does not estimate how many domains would be needed, what the operational complexity would be (managing certificates, avoiding registrar abuse detection, maintaining uptime during the poisoning window), or whether bulk domain registration patterns would trigger abuse detection at registrars.

For frontrunning poisoning, the demonstration is even more preliminary. The paper shows that snapshot timing can be predicted to within ~30 minutes (Figure 5) and that ~35% of reversions take >30 minutes (Figure 6), yielding a theoretical 6.5% poisoning rate. But this analysis is entirely passive and uses conservative lower bounds — the actual achievable rate is unknown. The paper explicitly acknowledges several factors that would reduce real-world success: "rate limiting of edits or IP bans" are noted but not modeled; the optimal adjustment variable a is selected post-hoc rather than predicted from historical data; and only one snapshot is analyzed for the timing prediction evaluation. An adversary attempting this attack would need to (1) make many edits in a short window before the snapshot, (2) avoid triggering Wikipedia's automated abuse detection (which flags rapid-fire edits, edits from new accounts, and edits to high-profile pages), (3) avoid IP bans that would prevent their edits from being submitted, and (4) ensure their edits are not reverted by the increasingly fast automated reversion tools (ClueBot NG, which reverts obvious vandalism in seconds). None of these practical constraints are incorporated into the 6.5% estimate.

The paper acknowledges these limitations implicitly by calling the 6.5% figure a "conservative" estimate that "would likely prevent us from reaching this fraction" in practice, but then argues that the true rate would still be "orders-of-magnitude higher than what is required." This logic is sound — the gap between 6.5% (estimated) and 0.01% (required) is large enough that even substantial downward revision leaves the attack practical — but it leaves the actual achievable rate unspecified.

Does the paper demonstrate that these attacks are low-cost and low-skill?

Yes, with caveats about what "skill" means.

The monetary cost is well-quantified: $60 USD for 0.01$1,000 in domain purchases. The paper does not include operational costs (hosting, certificate management, monitoring infrastructure) in these estimates, but these are likely modest compared to domain registration fees.

However, the "low-skill" claim requires closer examination. The split-view attack requires: (1) parsing large dataset indices to extract unique domains and count images per domain; (2) performing bulk DNS lookups to identify expired domains; (3) querying registrar APIs to determine which expired domains are buyable and at what price; (4) purchasing domains, configuring DNS, obtaining HTTPS certificates from LetsEncrypt, and setting up web servers; (5) generating or selecting poisoned content that will be effective when paired with the fixed captions in the dataset index; (6) potentially evading detection. These tasks are well within the capabilities of a competent developer but are not "script kiddie" level — they require familiarity with DNS, domain registration, web server configuration, and the training pipelines of the target models.

The frontrunning attack requires: (1) understanding Wikipedia's dump infrastructure (documented but requires investigation); (2) analyzing edit histories to triangulate snapshot times (the paper's methodology is not trivial to reproduce); (3) predicting future snapshot timing by fitting linear models to historical data; (4) timing a large number of edits precisely before the predicted snapshot window while evading Wikipedia's anti-abuse systems. This is substantially more complex than the split-view attack and requires domain-specific knowledge of Wikipedia's operational infrastructure that is not common knowledge among security researchers — the paper itself discovered the linear scanning property through reverse engineering.

That said, the paper's core claim is that the attacks require "no specialized or insider knowledge about the curator, downloader, or maintainer" — and this holds. The required knowledge (DNS, domain registration, Wikipedia dumps) is publicly available, not insider information. The attacks exploit structural properties, not compromised credentials or zero-day vulnerabilities.

Does the paper demonstrate that all modern datasets are vulnerable?

The paper demonstrates vulnerability across 10 datasets, but the claim that this generalizes to all web-scale datasets requires examining what properties enable the attacks.

For split-view poisoning, the necessary condition is that the dataset distributes a URL index without cryptographic integrity verification. The paper identifies this as true for "nearly all modern web-scale datasets" (Section 3.2) and validates across 10 datasets spanning different release dates (2010–2023), sizes (0.06M–2.3B samples), and modalities. The fact that three datasets released after the paper first appeared on arXiv (MMC4-FF, Falcon RefinedWeb, OBELISC — marked "2023+" in Table I) still lacked cryptographic hashes provides temporal validation: the vulnerability persists even after the research community was alerted. This strongly supports the generality claim.

However, the paper does not study text-only datasets (e.g., C4, the Pile, mC4) with the same rigor. Falcon RefinedWeb is a text dataset, and it is listed in Table I with 0.24% expired domains, suggesting the attack extends to text. But the proof-of-concept demonstration is only for multimodal image-text models (CLIP). Whether the same attack would work on language models trained on text-only datasets — where the adversary replaces web page content rather than images, and where the fixed auxiliary data (captions) is less clearly analogous — is asserted but not tested.

For frontrunning poisoning, the necessary condition is that a dataset snapshots crowdsourced content on a predictable schedule with moderation latency exceeding the prediction error. The paper demonstrates this for Wikipedia and 35 multilingual Wikipedias. The paper discusses Common Crawl only briefly in Appendix A, without replicating the timing analysis. Common Crawl is a much larger and more complex target than Wikipedia — it crawls diverse domains, not just crowdsourced articles, and its snapshot schedule is different. The paper does not demonstrate frontrunning feasibility on Common Crawl despite naming it as an affected dataset (Section 7). This is a significant gap: if the frontrunning attack is claimed to generalize beyond Wikipedia, the analysis should extend to other centralized datasets.

Are the defenses evaluated rigorously?

The defenses are proposed and analyzed conceptually, but their effectiveness is not measured empirically.

The integrity hash defense for split-view poisoning is partially validated: the paper demonstrates that it would work (hashes catch content changes) but also that it imposes a severe utility cost (1.8 million of 2.9 million accessible images in CC3M would be rejected). The utility analysis is for a single dataset (CC3M) and does not explore whether the ratio of benign-to-malicious changes varies across datasets, content types, or ages. The paper does not test hybrid defenses (e.g., perceptual hash filtering with human review for flagged images) or measure whether the reduction in dataset size from hash verification would materially degrade model performance.

The timing-based defenses for frontrunning (randomized crawling, time-gated snapshots) are analyzed mathematically but not tested against the actual attack. The estimate that randomized crawling would protect 89.5% of articles (Section 6.3) assumes uniform randomization over 24 hours and does not account for the possibility that an attacker could still succeed with non-trivial probability if randomization is imperfectly implemented or if the attacker targets many articles. The time-gated defense assumes moderators can detect malicious edits within a holding period — the paper does not test whether an adversary could craft edits that appear benign to human moderators but poison machine learning models (e.g., subtle factual modifications that go unnoticed by editors but change the training distribution).

What experiments are missing?

Several experiments would substantially strengthen the paper's claims:

1. End-to-end poisoning demonstration with actual domain ownership. Purchasing a small number of expired domains, serving poisoned content, and verifying that a downstream model trained on a dataset that crawled those domains exhibits the targeted misbehavior. This would close the gap between "we could have" and "we did," while still being ethical if conducted with appropriate safeguards (limited poisoning rate, non-harmful target, disclosure to model trainers).

2. Longitudinal study of domain expiration rates. The current measurement is a point estimate (August 2022). A study tracking how the fraction of expired domains changes month-over-month for several datasets would validate whether the attack surface is growing, stable, or shrinking, and would provide better cost estimates for timing the attack.

3. Defense effectiveness benchmarks. For each proposed defense, measure: (a) what fraction of the attack surface it closes; (b) what utility cost it imposes (dataset size reduction, model accuracy impact); (c) what fraction of attacks would bypass it (e.g., perceptual hash adversarial examples). This would transform the defenses from conceptual proposals to actionable recommendations with quantified tradeoffs.

4. Common Crawl frontrunning analysis. Replicating the Wikipedia timing methodology on Common Crawl to determine whether predictable snapshot timing exists for a broader class of centralized datasets.

5. Poisoning efficacy at the minimum purchaseable rate. The proof-of-concept uses 0.0025% poisoning (10,000 images). The minimum purchaseable rate for $60 is approximately 0.01$60 budget) would validate that the lowest-cost attack is still effective, removing concerns that the demonstrated rate is lower than the achievable rate.

6. Analysis of registrar abuse detection. Whether bulk purchasing of expired domains triggers automated abuse detection at registrars, and at what scale. This determines whether the attack can be scaled to the 0.01% level without triggering countermeasures.

Overall Assessment

The paper's central claim — that practical, low-cost poisoning of web-scale training datasets is possible — is well-supported at the attack surface level: the necessary preconditions exist across all studied datasets, the costs are quantified, and the downstream impact is demonstrated via simulation. The paper makes a compelling case that the field has overlooked the dataset distribution architecture as an attack vector, and that existing trust assumptions are violated in practice.

However, the paper's analysis is best understood as a feasibility demonstration rather than a complete attack blueprint. The gap between "this could be done" and "this has been done" — or even "this would succeed in practice given real-world constraints" — remains material. The absence of end-to-end validation, the optimistic assumptions about operational constraints (especially for Wikipedia), and the limited exploration of defenses mean that the paper opens a research agenda rather than closing it. This is not a criticism of the paper's quality — the paper is explicit about its limitations and ethical constraints — but it should inform how the findings are interpreted. The appropriate takeaway is "web-scale datasets are vulnerable to these specific attack vectors; defenses should be deployed urgently; and further research is needed to understand the practical constraints on real-world exploitation," not "anyone can poison LAION for $60 with guaranteed success."

6. Limitations and Trade-offs

6.1 Difficulty Estimation Cost Is Unaccounted for in the Poisoning Budget

The assumption or constraint. The split-view poisoning attack requires the adversary to know which domains in the dataset index are expired and buyable. The paper implicitly assumes this information is available at negligible cost — the adversary reads the published dataset index, performs DNS lookups, and queries registrar APIs. However, the paper's own measurement methodology for quantifying the attack surface involved performing nslookup on every domain name in each dataset from two geographically distinct datacenters at two time points, then querying registrar pricing for the top 10,000 domains per dataset (Section 4.2). For a dataset like LAION-2B-en with billions of URLs across millions of unique domains, this measurement infrastructure is itself non-trivial. Moreover, the paper's passive monitoring study — which established that datasets are regularly downloaded — required purchasing 60 domains and operating HTTPS servers with valid certificates for 12 months, receiving approximately 15 million requests per month (Section 4.3). None of these operational costs are included in the headline $60 USD figure.

The consequence. The $60 figure represents the *marginal* cost of domain registration for 0.01$60 figure is best understood as a lower bound on the domain registration component of the attack cost, not the total cost to execute the attack end-to-end.

What evidence exists in the paper. The paper quantifies only domain registration costs: Figure 1 plots the fraction of images purchasable as a function of budget, where the budget is "the cost of purchasing domains in order of lowest cost per image first" (Section 4.2). The passive monitoring infrastructure — servers, certificates, logging, 12 months of operation — is described in Section 4.3 but its cost is never stated. The DNS scanning methodology (500 queries/second across millions of domains) is described as an experimental constraint rather than costed. The ethical considerations section (Section 4.3.1) confirms the infrastructure was "minimally invasive" and limited in scale, but does not address cost scaling. The proof-of-concept poisoning (Section 4.5, Appendix B) uses simulated image substitution rather than actual domain ownership, so it does not validate the operational costs of serving poisoned content at scale.

Mitigation status. The paper does not claim to include operational costs in the $60 figure, and does not discuss the total cost of ownership for the attack infrastructure. The limitation is not acknowledged in the paper's limitations section (the paper has no dedicated limitations section). A practitioner planning to defend against this attack should budget for the possibility that the attacker's operational costs are amortized over multiple targets (poisoning 10 datasets simultaneously would share the domain-scanning infrastructure) or subsidized by existing botnet infrastructure, making the marginal cost of adding dataset poisoning to an existing domain-hijacking operation very low. The paper's responsible disclosure section notes that the attack has not been observed in the wild (Section 4.4), which may partially reflect that the operational complexity — while not prohibitive — exceeds what purely opportunistic attackers have attempted.

---

6.2 The Attack Has Not Been Demonstrated End-to-End Against a Real Training Pipeline

The assumption or constraint. The paper demonstrates the preconditions for poisoning (domain ownership, download frequency, proof-of-concept training with simulated poisoned images) but does not execute an end-to-end attack where: (1) an adversary actually purchases expired domains; (2) serves genuinely poisoned content from those domains; (3) a real downstream user downloads the dataset, trains a model, and deploys it; and (4) the adversary achieves their attack objective on the deployed model. The proof-of-concept poisoning (Section 4.5, Appendix B) locally substitutes images rather than serving them from purchased domains, and trains a model in a controlled environment rather than waiting for a real downloader to incorporate the poisoned data. The paper states explicitly: "We do not actually poison any datasets. For all URLs we own, we return a 404 Not Found response; so from the perspective of a dataset downloader our purchasing of the domain is completely transparent" (Section 4.3.1).

The consequence. Several practical failure modes cannot be assessed without end-to-end validation:

• Downloader behavior with changed content. The paper argues that 404 responses cause standard downloaders to skip the image entirely, making the transition transparent. But an adversary cannot serve 404s during the actual attack — they must serve poisoned images. Downloaders may behave differently when a URL that previously returned an image suddenly returns a different image: retry logic, content-type validation, file-size checks, or integration with content moderation pipelines could reject the poisoned image before it enters the training set. The img2dataset tool, responsible for 77% of observed traffic (Section 4.3.1), has configurable timeout, retry, and image format validation behaviors that may affect whether poisoned content is successfully ingested — these are not tested.
• Dataset maintainers may notice and intervene. The paper assumes the dataset maintainer is honest but inactive after publishing the index. In practice, dataset maintainers might monitor for domain expiration in their indices, update indices to remove dead domains, or release revised indices that exclude domains known to have changed ownership. The paper does not test whether any maintainer actively monitors their indices — the finding that CC3M and LAION-400M show no evidence of past exploitation (Section 4.4) could reflect either that no attacks occurred or that benign changes are common enough that maintainers do not investigate. If a real attack caused a detectable pattern (e.g., many images from newly purchased domains suddenly changing simultaneously), maintainer intervention could limit the attack's persistence.
• Model training stochasticity and dataset deduplication. The proof-of-concept training is a single run with simulated image substitution. Real training pipelines may apply deduplication (removing near-duplicate images, which would affect an attack that substitutes the same poisoned image across many URLs), data augmentation (which could destroy carefully crafted poisoned patterns), or multi-epoch training with shuffling (which changes the effective poisoning rate). The paper does not test robustness to these standard pipeline components.
• The attack's duration of effectiveness. The paper demonstrates that datasets are downloaded regularly (800+ downloads over 6 months, Section 4.3.1), but does not measure how long a specific domain remains buyable after expiration, how quickly dataset maintainers update their indices, or whether downloaders cache previously downloaded images and skip re-downloading. An adversary who buys a domain and serves poisoned content may find that only the first few downloaders after the domain purchase receive the poisoned version, after which the maintainer updates the index or the downloader community becomes aware of the change.

What evidence exists in the paper. The gap between proof-of-concept and end-to-end validation is explicitly acknowledged in the paper's methodology: "we locally replace these images with poisoned samples to simulate the effect of an attack, without any potential to cause harm to others" (Section 4.5). The proof-of-concept results (60% misclassification success, 90% NSFW bypass) demonstrate that if the poisoned images were included in the training set at the observed rate, the attack would succeed — but they do not demonstrate that the images would be included under realistic download conditions. The passive monitoring study (Section 4.3) demonstrates that downloads occur, but the monitoring infrastructure served 404s, not poisoned content, so it does not validate that poisoned content would be accepted by downloaders.

Mitigation status. This limitation is inherent in the paper's ethical framework — the authors explicitly chose not to execute a harmful end-to-end attack, which is the correct ethical decision. The paper's contribution is establishing feasibility (the preconditions exist, the costs are low, the impact would be effective if executed) rather than execution (the attack was carried out successfully). The limitation does not undermine the paper's core claims — the attack surface is real, the costs are quantified, and the downstream impact has been validated in a controlled setting — but it means that a practitioner defending against this attack should anticipate unknown failure modes that would only emerge during real-world execution. The paper's responsible disclosure (abstract, Section 6.2) and the fact that six datasets now ship with integrity hashes suggest that the community has treated the feasibility demonstration as sufficient grounds for defensive action.

---

6.3 The Frontrunning Success Rate Analysis Is Purely Theoretical and Does Not Account for Wikipedia's Operational Anti-Abuse Systems

The assumption or constraint. The 6.5% poisoning success rate for English Wikipedia (Section 5.4) is computed from three inputs: (1) the accuracy of snapshot timing predictions (~30-minute error, Figure 5); (2) the distribution of historical reversion times (~35% of reversions take >30 minutes, Figure 6); and (3) a conservative interval-based bounding method that ensures the estimate is a true lower bound on the fraction of edits that would survive into the snapshot, assuming the edits are made and not blocked. The analysis does not model or account for any of Wikipedia's operational anti-abuse mechanisms: rate limiting of edits (Wikipedia imposes per-account and per-IP limits on edit frequency), automated vandalism detection (ClueBot NG and similar tools revert obvious vandalism within seconds, well under the 30-minute window), IP bans and account blocks (Wikipedia automatically blocks IPs and accounts that engage in sustained vandalism), page protection (high-profile or frequently vandalized pages are semi-protected, preventing edits from new or unregistered accounts), or edit filters (Wikipedia uses abuse filters that can block edits matching certain patterns before they are even saved). The paper acknowledges this explicitly: "a number of factors beyond our analysis would likely prevent us from reaching this fraction, such as rate limiting of edits or IP bans" (Section 5.4).

The consequence. The 6.5% figure is best understood as an upper bound on the fraction of Wikipedia articles where the timing would work — not as an estimate of the fraction of articles an adversary could actually poison in practice. Real-world success would be substantially lower, potentially by orders of magnitude, because:

• Automated reversion speed. ClueBot NG, Wikipedia's primary anti-vandalism bot, reverts obvious vandalism in a median time of under 30 seconds (not modeled in the paper's reversion distribution, which measures all reversions including those by human editors who are much slower).
• Edit rate limits. A new Wikipedia account can make approximately 8 edits per minute; an IP address without an account is more heavily rate-limited. To poison 6.5% of English Wikipedia (~400,000 articles out of ~6 million), an adversary would need to make ~400,000 edits in roughly a 24-hour window (the snapshot duration), which requires ~280 edits per minute — far exceeding rate limits for any single account or IP.
• Sockpuppet detection. Wikipedia actively detects and blocks coordinated editing from multiple accounts controlled by the same person (sockpuppetry). Scaling the attack across many accounts to circumvent rate limits would trigger sockpuppet detection.
• Page protection. The most impactful articles to poison (those most frequently used in downstream datasets) are disproportionately likely to be semi-protected or fully protected, preventing edits from new accounts.
• Edit quality filtering. Wikipedia's abuse filters can detect and block edits matching patterns associated with vandalism (e.g., blanking a page, adding profanity, making large-scale changes to many pages from a new account). The type of edits an adversary would need to make to poison training data (e.g., modifying factual claims, injecting specific text patterns) may or may not trigger these filters, but this is untested.

What evidence exists in the paper. The reversion time distribution (Figure 6) is based on passive analysis of edit histories — it includes reversions by all mechanisms (bots and humans), but it does not distinguish between them and does not measure the speed of automated tools specifically. The paper's reversion detection methodology uses comment string matching (Appendix A.1), which may miss automated reversions that use non-standard comments or no comments at all. The 6.5% computation uses the CDF of all reversions, implicitly assuming that the reversion time distribution for the specific type of edits an adversary would make (targeted, timed, possibly obfuscated) matches the distribution of all vandalism reversions. This is unlikely — an adversary optimizing for survival would craft edits that evade automated detection (e.g., subtle factual changes rather than obvious vandalism), which would have longer reversion times than the overall distribution, but they might still trigger behavioral signals (rapid-fire edits from a new account) that lead to blocks before the edits are even reviewed.

The paper's multilingual analysis (Figure 7) shows that smaller Wikipedias are more vulnerable (up to 25.3% poisoning rate), and the paper attributes this to shorter snapshot durations and more stable timing. However, smaller Wikipedias may also have fewer automated anti-abuse tools, making them genuinely more vulnerable — or they may have different anti-abuse postures that are not captured by the reversion time analysis. The paper does not investigate per-language anti-abuse mechanisms.

Mitigation status. The paper acknowledges the limitation (Section 5.4: "a number of factors beyond our analysis would likely prevent us from reaching this fraction") but does not attempt to quantify the impact of anti-abuse systems. The 6.5% figure is presented as a "conservative estimate" of what would happen "absent any other defensive measures," where "defensive measures" in this context means the proposed snapshot-timing defenses (Section 6.3), not Wikipedia's existing anti-abuse infrastructure. A practitioner evaluating the threat should treat the 6.5% figure as a timing feasibility bound rather than an operational success estimate — it demonstrates that the temporal window exists, but not that the attack can be executed at scale within that window.

---

6.4 The Integrity Hash Defense Imposes a Severe Utility Cost That Is Quantified but Not Resolved

The assumption or constraint. The paper's primary defense against split-view poisoning is for dataset maintainers to publish SHA-256 cryptographic hashes alongside each URL, enabling downloaders to verify that the content they receive matches what the maintainer originally indexed (Section 6.2). The paper presents this as an effective, low-overhead defense: "maintainers — or another trusted third-party — can prevent split-view attacks by attaching a cryptographic hash h_i = H(x_i) of the raw data x_i... The downloader discards any data where the client and maintainer receive distinct content." The paper then measures the utility impact of this defense on CC3M: of the 3.3 million original images, 2.9 million are still accessible as of 2023, but only 1.1 million have hashes that match the original — the other 1.8 million images have changed since the initial dataset release (Section 6.2). This means strict hash verification would reduce the usable dataset size by a factor of approximately 2.6× (from 2.9 million accessible images to 1.1 million verified images).

The consequence. The defense is simultaneously perfectly effective (cryptographic hashes prevent any undetected content modification) and practically infeasible for many use cases (it discards a majority of the data that is still accessible and likely still useful). This creates a security-utility tension that the paper identifies but does not resolve:

• Dataset size reduction. For CC3M, hash verification discards 62% of accessible images. The paper does not measure this ratio for other datasets (it only computes it for CC3M, where the original raw bytes were available), so it is unknown whether CC3M is representative or whether other datasets would see even larger reductions (older datasets with more expired domains might have more benign changes; newer datasets with fresher content might have fewer).
• Bias introduction. The 1.8 million images that changed are not a random subset — they represent domains where content was actively updated (re-encoded, resized, replaced with higher-resolution versions, or changed ownership). Discarding these systematically biases the dataset toward static, unmaintained domains, which may correlate with lower-quality content, older images, or specific content distributions. The paper does not analyze whether the verified subset is representative of the full dataset distribution.
• Adoption barriers. The paper notes that "many people prefer a high accuracy model to a secure one" (Appendix E, response to meta-review), and that LAION-400M's maintainers "provided hashes as optional" — precisely because mandatory hash verification would reduce dataset utility. This means even when hashes are available, downloaders may choose not to verify them, leaving the attack surface open.
• Perceptual hashes are not a solution. COYO-700M uses pHash (a perceptual hash) to validate benign image changes, but the paper correctly notes that perceptual hashes are "not adversarially robust" (Table I footnote): an attacker can craft poisoned images that preserve perceptual hash values while changing semantic content (citing Jain et al., 2022; Struppek et al., 2022; Hao et al., 2021). Switching to perceptual hashes would restore utility but would not prevent the attack — the adversary can adversarially optimize poisoned images to match the perceptual hash of the original.

What evidence exists in the paper. The CC3M measurement (Section 6.2) is the only quantitative analysis of the utility cost: 2.9 million accessible, 1.1 million hash-matching. The paper notes that this suggests "our defense, while providing perfect protection against split-view poisoning attacks, has the potential to degrade utility" and that "qualitatively new defense ideas will be necessary to defend against our attacks without a high utility cost." The response to the meta-review (Appendix E) explicitly frames this as a genuine tradeoff: "there is even a good reason why these datasets may not force the use of cryptographic hashes: it significantly degrades utility."

Mitigation status. The paper proposes no resolution to the utility-security tension and explicitly calls for future work on "qualitatively new defense ideas." The defenses deployed as part of responsible disclosure make hashes available (six datasets now ship with SHA-256 hashes) but not mandatory — the img2dataset hash verification feature is an option, not a default, meaning the attack surface remains open for downloaders who prioritize utility. The paper's broader transparency proposals (Section 6.5: dataset transparency logs modeled on certificate transparency) would enable auditing but would not directly prevent poisoning unless combined with mandatory verification. A practitioner deciding whether to deploy hash verification must weigh the ~2.6× dataset size reduction against the (currently unquantified) risk that their specific dataset has been poisoned — a tradeoff the paper identifies but does not help resolve.

---

6.5 The Attack Surface Analysis Covers Image-Text Datasets But Does Not Extend to Text-Only or Other Modality Datasets

The assumption or constraint. The split-view poisoning attack is evaluated primarily on multimodal image-text datasets (LAION, COYO, Conceptual Captions, etc.) and face recognition datasets (VGG Face, FaceScrub, PubFig). The proof-of-concept poisoning demonstration (Section 4.5, Appendix B) is exclusively on contrastive vision-language models (CLIP). The frontrunning poisoning attack is evaluated on Wikipedia snapshots, which are text corpora. However, the paper does not study or measure the attack surface for text-only web-scale datasets that are not derived from Wikipedia — such as C4 (Colossal Clean Crawled Corpus), the Pile, mC4, or OpenWebText — which are among the most widely used training datasets for large language models. Falcon RefinedWeb is listed in Table I (0.24% expired, ≥0.02% purchaseable for $1,000), confirming that the domain-expiration vulnerability exists for text datasets, but no proof-of-concept poisoning is conducted for text.

The consequence. The paper's claim that "all recently-published large datasets are vulnerable to split-view poisoning attacks" (Table I caption) is supported for the specific datasets studied, but the generalization to text-only datasets — which are arguably more critical given the dominance of large language models — relies on the architectural argument (any URL-based dataset without integrity verification is vulnerable) rather than empirical validation. Several differences between image and text poisoning may affect feasibility:

• Content replacement vs. image substitution. For image datasets, the adversary replaces an image while the caption (auxiliary data c_i) is fixed in the index. The proof-of-concept demonstrates that fixed captions still provide sufficient signal for contrastive learning to associate the poisoned image with the target label. For text datasets, the nature of "content" and "auxiliary data" is different: if the dataset indexes web pages by URL and the adversary replaces the entire page content, there is no fixed auxiliary data to constrain the attack — the adversary controls everything the model sees for that URL. This might make poisoning easier (no constraint to work around) or harder (language model training objectives differ from contrastive image-text objectives, and the relationship between poisoned text and downstream behavior is less well-characterized).
• Deduplication and filtering in text pipelines. Text datasets typically apply aggressive deduplication (removing near-duplicate documents), quality filtering (removing low-perplexity or repetitive text), and content filtering (removing harmful or NSFW content). Poisoned text pages might be filtered out by these pipelines before training, reducing the effective poisoning rate. The paper does not analyze whether the type of poisoned content an adversary would inject (e.g., text designed to implant a backdoor in a language model) would survive standard text preprocessing.
• Domain structure for text sources. Text datasets draw from a different population of domains than image datasets (news sites, blogs, forums, documentation, academic papers vs. image hosting services, stock photo sites, social media). The expiration rate, buyability, and cost structure of text-hosting domains may differ from image-hosting domains. The paper measures expiration rates for Falcon RefinedWeb (a text dataset) but does not analyze whether the expired domains in that dataset have different characteristics (e.g., more likely to be squatted, different pricing structure) than those in image datasets.
• Frontrunning on non-Wikipedia text sources. The frontrunning attack is demonstrated on Wikipedia and multilingual Wikipedias. The paper mentions Common Crawl in passing (Appendix A, Section 7) as another centralized dataset, but does not analyze whether Common Crawl's snapshot process is predictable in the same way as Wikipedia's. Common Crawl crawls diverse websites on a monthly schedule, but the order and timing of crawling specific URLs within a crawl is not documented to follow the linear, deterministic pattern that Wikipedia exhibits. If Common Crawl's crawling order is randomized or driven by a priority queue rather than a sequential scan, the frontrunning attack may not apply — or may require a different prediction methodology.

What evidence exists in the paper. Table I includes Falcon RefinedWeb (a text dataset) with 0.24% expired domains — this is the only text dataset measured for split-view poisoning. The paper does not report measurements for C4, the Pile, mC4, or other major text datasets, despite these being among the most downloaded and most impactful web-scale datasets. The proof-of-concept poisoning (Section 4.5) is exclusively on CLIP (vision-language); no language model poisoning experiment is conducted. The frontrunning attack is limited to Wikipedia; Appendix A mentions Common Crawl but provides no analysis. The paper's title and abstract claim the attacks apply to "web-scale training datasets" without qualification, but the empirical evidence is almost entirely from image-text datasets and Wikipedia.

Mitigation status. The paper does not acknowledge this as a limitation — the generalization from image datasets to all web-scale datasets is presented as following from the architectural argument rather than requiring per-modality validation. The architectural argument is logically sound (any URL-indexed dataset without integrity verification is vulnerable to domain expiration), but the practical constraints on text poisoning (deduplication, filtering, content constraints, domain availability) are unexplored. A practitioner training large language models should not assume the $60/0.01% cost estimate transfers directly to text datasets without measurement of the specific text datasets they use. The responsible disclosure focused on image dataset maintainers (LAION, COYO, CC3M, etc.) and Wikipedia, consistent with the scope of the empirical analysis.

---

6.6 The Paper Does Not Study or Propose Defenses That Address the Root Cause: The Use of External, Uncontrolled URLs as Dataset Content

The assumption or constraint. Both split-view poisoning and frontrunning poisoning exploit a fundamental architectural property of web-scale datasets: the dataset points to content hosted on infrastructure the dataset maintainer does not control, and there is no binding between the index and the content at download time. The proposed defenses — integrity hashes for split-view, randomized or time-gated snapshots for frontrunning — are point defenses that close the specific exploit vectors identified, but they do not address the underlying structural problem. The paper acknowledges this implicitly in Section 6.5, where it proposes longer-term solutions (transparency logs, consensus-based verification), but these are sketched at a vision level without technical specification or evaluation.

The consequence. The point defenses are fragile in several ways:

• Integrity hashes prevent split-view poisoning but not other content-modification attacks. If the adversary compromises the original web server (rather than buying the domain after expiration), the maintainer would index the poisoned content and compute a hash of it — the hash would match, and the downloader would accept the poisoned content. The hash defense only works because the paper's attack modifies content after the maintainer indexes it. A different attack vector (server compromise, malicious insider at the hosting provider, DNS poisoning at resolution time rather than domain expiration) would bypass integrity hashes because the hash would be computed over the already-poisoned content.
• Timing-based defenses prevent frontrunning on predictable snapshots but not on snapshots where the adversary has longer-term control. If an adversary can sustain control of a Wikipedia article for an extended period (e.g., by making subtle, plausible-looking edits that are not recognized as vandalism), the randomized snapshot and time-gated release defenses would not help — the content would appear legitimate at snapshot time and would not be reverted within the holding period. The defenses assume malicious edits are detectable and revertable given enough time, which may not hold for adversarial edits designed to poison machine learning models while appearing benign to human moderators (e.g., systematic factual distortions that are individually plausible).
• Neither defense addresses the case where the dataset maintainer itself is compromised or malicious. The paper's threat model assumes "all maintainers, curators and downloaders behave honestly" (Section 3.2). If the maintainer is compromised (e.g., their infrastructure is attacked, or they are coerced), they could publish a modified index with incorrect hashes, or a modified snapshot with poisoned content. The transparency log proposal (Section 6.5) would allow clients to detect that different clients received different indices, but only if clients compare their received indices against the log — a coordination problem that the paper does not solve.
• The defenses do not protect against poisoning that occurs when a dataset is re-crawled by a new maintainer. The paper notes that some large datasets (LAION-2B-en) serve as upstream sources for smaller subsets (PMD, LAION-Aesthetics). If the upstream dataset adds integrity hashes but the downstream subset maintainer re-crawls URLs without verifying those hashes (or crawls different content from the same URLs at a different time), the downstream dataset is still vulnerable. The paper's img2dataset hash verification patch only helps if the downloader uses img2dataset and explicitly enables verification — it does not protect downstream datasets that use other tools or that re-crawl from scratch.

The deeper limitation is that web-scale datasets have adopted an architecture (URL indices, periodic snapshots) that was designed for convenience and scalability rather than security. The defenses proposed in the paper are incremental improvements within this architecture, but they do not change the fundamental trust model: the dataset content is still controlled by whoever owns the URLs at download time. A more robust solution would require the dataset maintainer to either host the content themselves (centralizing the trust model, as YFCC100M does, but at high storage cost) or to implement cryptographic provenance that binds content to its original source even after domain transfers (e.g., content addressing via IPFS or similar, which no current web-scale dataset uses).

What evidence exists in the paper. The limitations of the proposed defenses are discussed in Section 6.2 (for integrity hashes: benign changes cause utility loss; "qualitatively new defense ideas will be necessary"), Section 6.3 (for timing-based defenses: "these defenses make it more difficult for an attacker to operationalize frontrunning, but cannot prevent it entirely"), and Section 6.4 (for general poisoning: "any solution in this space requires downstream knowledge of how URL content is consumed, vectorized, and deconflicted during training"). The paper explicitly scopes its defenses to the specific attacks identified and notes that "more robust, future-looking solutions with fewer trust assumptions" are needed (Section 6.5). However, the paper does not provide a systematic analysis of the attack surface that remains after the proposed defenses are deployed, nor does it estimate the residual risk.

Mitigation status. The paper treats this as out of scope — the goal is to identify and mitigate the specific attack vectors (split-view and frontrunning), not to solve the general problem of securing web-scale data pipelines. The transparency log proposal (Section 6.5) is the closest the paper comes to a structural solution, but it is described at the level of an analogy ("akin to certificate transparency") without technical specification, threat modeling, or evaluation. The paper's contribution is demonstrating that the current architecture is insecure and providing point fixes for the most immediate vulnerabilities; redesigning the architecture for security is explicitly left to future work. A practitioner deploying large-scale training pipelines should understand that the proposed defenses address the specific attacks described in the paper, but do not provide general security against all poisoning vectors — the underlying trust model (content controlled by URL owners, verified only by maintainer-computed hashes) has a larger attack surface than the paper explores.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper causes a reframing of the poisoning threat model from a content-level problem to a supply-chain problem. Prior to this work, the poisoning literature operated under the implicit assumption that the primary challenge was what to do with poisoned data — how to craft effective attacks, how to make them stealthy, how to defend models against them. The paper demonstrates that this entire literature has been analyzing the wrong bottleneck: the harder problem is not using poisoned data, but placing it in the dataset in the first place. And once that problem is solved — which the paper shows requires only $60 USD, not sophisticated exploits — the downstream attacks that the literature has already developed become immediately applicable.

This reframing has a specific, actionable consequence: dataset security can no longer be treated as a model-training concern; it must be treated as a data-infrastructure concern. The attacks do not exploit properties of neural networks, training objectives, or model architectures. They exploit DNS expiration, domain registration processes, and deterministic snapshot schedules — infrastructure properties that are invisible to anyone who treats a dataset as a static collection of examples. The paper's C-type analogy (int const * vs. int * const) diagnoses the conceptual error precisely: the community has been reasoning about datasets as if the content were immutable, when the distribution mechanism provides no such guarantee. This is not a bug in any particular dataset — it is a structural property of the URL-index architecture that virtually all web-scale datasets have adopted.

The paper also reconciles a tension between two contradictory security intuitions. On one hand, the security community has long known about domain hijacking (Lever et al., 2016) and the residual trust in expired domains; on the other hand, no one had connected this to machine learning training data, perhaps because dataset indices were viewed as "just metadata" rather than as live pointers to mutable content. The paper shows that these two communities — web security and ML security — have been operating with different trust assumptions about the same infrastructure, and that the gap between them is the attack surface. This is not a paradigm shift in either community individually, but it is a boundary-spanning insight that forces ML security researchers to reason about DNS, domain registrars, and snapshot infrastructure as first-class components of the threat model.

The meta-review exchange (Appendix D-E) captures precisely the conceptual shift the paper forces on the field. Reviewer 1 argues that the attack "appears effective only in situations where standard integrity protection measures are absent" — implying the vulnerability is trivial. The authors' response is devastating: "Regrettably, it just so happens that this includes every large scale dataset ever released in the last decade." This exchange reveals that the field's baseline assumption — that crypto hashes would obviously be deployed — is empirically false, and that the paper's contribution is not discovering a new vulnerability but demonstrating that a known defense has been systematically omitted from an entire class of critical infrastructure.

Which research directions become more attractive:

• Dataset supply-chain security as a distinct subfield, separate from both web security and adversarial ML. The paper demonstrates that the interface between these fields — how data moves from web sources to training pipelines — has its own attack surface and requires its own defenses.
• Empirical measurement of real-world ML infrastructure, rather than theoretical threat modeling. The paper's methodology — buying domains, running passive monitors, analyzing DNS records — demonstrates that critical security properties can be measured without requiring access to proprietary training pipelines.
• Defense-deployment incentives. The paper's finding that LAION-400M's maintainers chose not to make hashes mandatory because doing so would reduce utility (Appendix E) reveals that the primary obstacle to securing datasets is not technical but economic: dataset users prioritize accuracy over security, and dataset maintainers optimize for adoption. Research on making integrity verification low-cost (in terms of retained data) becomes essential.
• Timing-based attacks on ML infrastructure. The frontrunning attack demonstrates that predictability in data collection schedules is a security vulnerability — a class of attacks that has received essentially no attention in the ML security literature.

Which directions become less attractive:

• Purely content-based poisoning defenses that assume the adversary has already placed poisoned data in the training set. The paper shows that the attack surface is at the distribution layer; if integrity hashes are deployed, the content-layer attack becomes moot (for this vector); if they are not deployed, no amount of content filtering can prevent the attack because the adversary controls what content arrives.
• Stealth-focused poisoning research that assumes human review of training examples. The paper demonstrates that on web-scale datasets, no human reviews anything — the adversary can replace images entirely without detection, as evidenced by the 1.8 million benign image changes in CC3M that no one noticed. Stealth against human annotators is irrelevant when there are no annotators.

---

Follow-Up Research This Work Enables

End-to-end poisoning demonstration with actual domain ownership and real downstream model training. The paper's most significant gap is the absence of an executed end-to-end attack: domain purchase → poisoned content serving → real downloader ingestion → model training → attack objective achieved. A follow-up study would purchase a small number of expired domains from LAION-400M or COYO-700M, serve poisoned images for a limited window, and then train a CLIP model on the actually-downloaded dataset to measure whether the poisoned content (a) survives downloader filtering, (b) is incorporated into training, and (c) achieves the target misclassification. This would be ethical if the poisoning rate is kept below 0.001% (below the effective threshold for most attacks), the target is non-harmful (e.g., misclassifying a specific research image as a harmless category), and the domains are returned to serving 404s after the measurement window. The key metrics would be: what fraction of poisoned images actually reach the training set? How does img2dataset's retry, timeout, and format-validation behavior affect ingestion? Do any downloaders or maintainers detect and flag the changed content? This experiment would transform the paper's "could have" into "did," while calibrating the realistic success rate against the paper's theoretical estimates.

Longitudinal measurement of domain expiration rates across major datasets to model attack surface growth. The paper's domain expiration analysis is a point estimate from August 2022. A longitudinal study would perform the same DNS lookups monthly for 12–24 months across the 10 datasets in Table I, tracking how the fraction of expired domains changes over time. The key questions: does the expiration rate follow a predictable curve (e.g., exponential decay with a half-life of ~2 years)? Do different dataset types (image vs. text, old vs. new, large vs. small) have different expiration dynamics? Can a model trained on the first year of expiration data predict which domains will expire in the next year? This would enable both attackers (to time domain purchases for maximum impact) and defenders (to proactively re-verify or remove domains likely to expire) to make quantitative predictions rather than relying on point estimates. The methodology already exists in the paper — it just needs temporal extension.

Measurement of text-dataset poisoning feasibility with domain purchase on C4, the Pile, or mC4. The paper's proof-of-concept poisoning is exclusively on multimodal image-text models (CLIP). A direct extension would replicate the split-view attack surface quantification and poisoning demonstration for text-only datasets that are used to train large language models. The experiment would: (1) measure the fraction of URLs in C4 or the Pile that point to expired, buyable domains, using the same DNS-and-registrar methodology; (2) purchase a small number of domains and serve replaced text content; (3) train a language model on the resulting dataset and measure whether targeted behaviors (e.g., specific completions, factual errors, or toxicity) are implanted. The key technical difference from the image case is that language model training applies aggressive deduplication and quality filtering — the experiment would measure what fraction of poisoned text documents survive standard preprocessing pipelines (perplexity filtering, minhash deduplication, length filtering). The paper already has Falcon RefinedWeb in Table I (0.24% expired), establishing that the attack surface exists for text; the missing piece is the downstream effectiveness measurement.

Adversarial evaluation of Wikipedia's automated anti-vandalism systems against poisoning-motivated edits. The paper's 6.5% frontrunning success estimate explicitly excludes Wikipedia's operational anti-abuse mechanisms (ClueBots, edit filters, rate limiting). A follow-up study would, in a controlled sandbox or with Wikimedia's cooperation, attempt to make edits that are designed to survive both automated reversion and snapshot inclusion. The experiment would test different edit strategies: obvious vandalism (baseline), subtle factual modifications (e.g., changing a date by one year), style-consistent misinformation added to low-traffic articles, and edits timed at varying offsets before the predicted snapshot window. For each strategy, measure: what fraction of edits are caught by ClueBot vs. human reviewers? What fraction survive to snapshot inclusion? How does survival rate vary by article popularity, protection level, and language? This would transform the paper's theoretical 6.5% into an empirically validated success rate for realistic attack strategies, and would identify which anti-abuse mechanisms are most effective against poisoning (as opposed to vandalism). The paper's passive reversion time distribution (Figure 6) provides the baseline; the extension would add active testing of adversarial adaptation.

Design and evaluation of perceptually-informed integrity verification that balances security and utility. The paper identifies but does not resolve the tension between cryptographic hashes (perfect security, severe utility loss — 62% of CC3M rejected) and perceptual hashes (high utility, no adversarial security). A follow-up would design and benchmark intermediate defenses: for example, using a perceptual hash as a first-pass filter, flagging mismatches for cryptographic verification, and applying adversarial detection to the flagged subset; or using multiple perceptual hash functions with different invariance properties, requiring consensus; or using learned perceptual metrics (e.g., CLIP embedding similarity with an adversarially-trained threshold) rather than fixed hashes. The evaluation would measure on CC3M or LAION-400M: (a) what fraction of the dataset is retained vs. a cryptographic-only baseline; (b) what fraction of adversarially-optimized poisoned images (generated using the methods of Jain et al., 2022 or Struppek et al., 2022) bypass the defense; (c) what is the computational overhead relative to no verification. The paper's CC3M measurement (1.1M hash-matching out of 2.9M accessible) provides the baseline for retention; the cited perceptual hash attacks provide the adversarial evaluation methodology.

Common Crawl frontrunning feasibility analysis using the paper's timing-prediction methodology. The paper demonstrates frontrunning on Wikipedia but mentions Common Crawl only in passing. A follow-up would replicate the timing analysis for Common Crawl: (1) analyze Common Crawl's crawling infrastructure to determine whether the order of URL crawling within a monthly snapshot is predictable (e.g., sequential by URL, by domain, or by priority queue); (2) if predictable, measure the accuracy of predicting when a specific URL will be crawled, using the same edit-history triangulation method the paper developed for Wikipedia; (3) measure the window of time between when Common Crawl visits a page and when the snapshot is published (analogous to Wikipedia's ~24-hour snapshot duration); (4) estimate what fraction of web pages could be temporarily modified and survive into the snapshot before reverting. This would determine whether frontrunning is a Wikipedia-specific vulnerability or a general vulnerability of any periodically-snapshotted web corpus. The paper already has the methodology (Section 5.2); the extension is applying it to a new target and characterizing any structural differences (Common Crawl crawls diverse, non-coordinated websites rather than a single crowdsourced platform).

Training a difficulty-to-cost model that predicts attack ROI across datasets and objectives. The paper provides point estimates of attack cost ($60 for 0.01% of LAION-400M) but does not model how cost scales with poisoning rate, dataset characteristics, or attack objective. A follow-up would train a predictive model that takes as input a dataset (size, age, domain diversity, modality), a desired poisoning rate, and an attack objective (misclassification target, number of targets) and outputs an estimated total cost (domain registration + operational overhead) and expected success rate. The model would be trained on the paper's 10-dataset measurements (Table I) plus additional datasets measured with the same methodology, and would incorporate the operational cost factors that the paper excludes (DNS scanning, registrar queries, server hosting). This would enable both attackers (to select cost-optimal targets) and defenders (to identify which datasets are most cost-effective to secure first). The paper's methodology provides the measurement protocol; the extension is applying it systematically across a broader dataset population and building a predictive model rather than reporting point estimates.

---

Practical Applications and Downstream Use Cases

Mandatory integrity verification in dataset downloader tools. The paper demonstrates that img2dataset is responsible for 77% of dataset download traffic (Section 4.3.1), and the authors have already implemented SHA-256 hash verification as an option in this tool (Section 6.2). The immediate practical application is for the img2dataset maintainers to enable hash verification by default for datasets that provide hashes (now six datasets, per responsible disclosure), with an explicit opt-out. Given the paper's finding that only 1.1M of 2.9M accessible images in CC3M match their original hashes, default-on verification would reduce dataset size — but the user would be explicitly informed of the tradeoff ("1.8M images rejected due to hash mismatch; these may have changed benignly or may represent a security risk"). This shifts the default from insecure-toward-secure without removing user choice, and leverages the paper's user-agent analysis to target the intervention at the dominant tool rather than requiring every downloader to independently adopt defenses. The paper's 800+ downloads over six months provide the scale: even a partial adoption of hash verification in img2dataset would protect a substantial fraction of dataset consumers.

Pre-release domain freshness scanning for dataset maintainers. The paper's COYO-700M finding — that 0.1% of images were hosted on expired domains on the day of release (Section 4.2) — motivates a concrete practice for dataset maintainers: immediately before releasing a dataset index, scan all domains for expiration, and either (a) remove expired domains from the index, (b) flag them with a warning, or (c) re-verify the content and compute integrity hashes for any that are still accessible. This adds a one-time computational cost (DNS lookups at scale, which the paper shows is feasible at 500 queries/second) but eliminates the "vulnerable from day zero" problem. For a dataset like COYO-700M with 747M images, the DNS scan would take approximately 1.5M seconds (17 days) at 500 queries/second for unique domains (fewer than 747M if multiple images share domains), which is substantial but comparable to the dataset collection time itself. The paper's finding that even brand-new datasets have non-zero expired domains makes pre-release scanning a minimum-bar defense, independent of whether the maintainer also publishes integrity hashes.

Wikipedia snapshot process randomization to mitigate frontrunning. The paper's frontrunning analysis demonstrates that Wikipedia's deterministic, sequential snapshot process is the key enabler — the 6.5% estimated poisoning rate drops sharply if the snapshot order is randomized. The practical application is for Wikimedia to implement randomized article ordering within each snapshot worker job, rather than the current sequential-by-article-ID ordering. The paper estimates that uniform randomization over 24 hours would protect 89.5% of articles from random malicious edits (Section 6.3), given the 2.5-hour mean reversion time. This is a low-engineering-cost change to the existing dump infrastructure (it requires modifying the article assignment function, not the crawling infrastructure) with a quantified security benefit. The multilingual analysis (Figure 7) shows that smaller Wikipedias are more vulnerable, making this defense particularly impactful for the languages with the fewest moderation resources — precisely those least able to detect and revert targeted malicious edits through human review. The paper's responsible disclosure to Wikimedia creates the opportunity for this defense to be deployed before any known exploitation occurs.