From Gray-Market Data to the Data Supply Chain: Four Rounds of Tracing Codex 5.3 Contamination

—-codex5.3 pollution source map

From "Exception Words" to "Data Supply Chain": My fourth round of tracing the Codex 5.3 contamination problem

Ps: This article is a fragment of thoughts from different times during the research process, and there is no conflict between paragraphs and short articles.

In fact, this advertisement is officially allowed by openai, because the ordinary account and go package come with ads, and the plus and above packages have no ads.

The attack cost is not a "percentage", but an "absolute number of samples"

In the past, when talking about poisoning training data, the most common expression was "what proportion is contaminated." This is no problem in small-scale experiments, but in contemporary large-scale models, proportional thinking can easily mislead risk judgments.

The 2024 "Persistent Pre-Training Poisoning of LLMs" already illustrates the problem: the author did pre-training poisoning on a scale of 600M to 7B, and reported a very low effective threshold - 0.1% pre-training pollution can maintain measurable attack effects after subsequent SFT/DPO, and denial-of-service attacks can retain signs even at a lower ratio [1]. This step actually reminds us that "it will be washed off if you align it later" is not stable.

Subsequently, "Scaling Trends for Data Poisoning in LLMs" expanded the model scope to 24 cutting-edge models (1.5B to 72B), and the trend given is also not optimistic: scale growth does not automatically bring stronger anti-poisoning capabilities, and certain attack behaviors are easier to learn into the model [2].

What really pulled me out of "proportional thinking" was the 2025 article "Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples": The paper reported in the settings of 600M to 13B, 6B to 260B tokens that a fixed number of poison samples (exampled in the article to 250) can form a close backdoor effect on models of different sizes [3]. Anthropic's concurrent research page also clearly emphasizes this point: as the model becomes larger, the attacker may not necessarily need to increase the poison samples proportionally [4].

This will directly change the defensive thinking. In the past, it was easy for us to write the risk model as "the attacker has to pollute a massive corpus", but now a more realistic way of writing it is "the attacker only needs to stably break into a small number of sample anchors with high trigger value." The two are completely different in an engineering sense: the latter is cheaper for the attacker and more painful for the defender.

RLHF is not a magic button to “roll back upstream contamination”

RLHF is important, but it is more like a shock absorbing layer than a rollback layer.

"Universal Jailbreak Backdoors from Poisoned Human Feedback" (ICLR 2024) proved that preference data poisoning can implant a "universal trigger backdoor", that is, adding a trigger word can significantly change security behavior [5]. AAAI 2025's "Is poisoning a real threat to LLM alignment?" further compared PPO and DPO. In its setting, DPO may be induced to perform backdoor behavior at a lower proportion of contamination [6].

If you look further back, the 2023 "Poisoning Language Models During Instruction Tuning" has already shown that even in the instruction tuning stage, a small number of targeted pollution samples can make the model continue to be abnormal on specific phrases [7]. In 2024, "Sleeper Agents" pushed the problem to the level of "surviving after adversarial training", indicating that backdoor behaviors can be trained to be more covert, rather than disappearing automatically [8].

The evidence stacks up and I now no longer accept "we did alignment" as a sufficient condition. At most, it shows that the model is safer in the conventional evaluation distribution, which does not mean that there is no historical pollution debt in an open environment and trigger conditions.

Putting the problem back into the data supply chain, what I care about most is not the single point of failure, but the structural gaps.

Let’s look at the entrance volume first. The official page of Common Crawl is very straightforward: it has accumulated more than 300 billion pages in 15 years, with 3-5 billion new pages added every month[10]. This scale determines that the system's priority goal is "crawl coverage and availability" rather than "item-by-item deep semantic auditing". It’s not about who’s doing a bad job, it’s about the engineering constraints themselves.

Let’s look at the fetch sorting again. The official blog of Common Crawl 2026-01-19 clearly mentioned Web Graph’s Harmonic Centrality and PageRank, and explained that these indicators are used in CCBot’s crawling choices[11]. This does not automatically mean that "the attacker can manipulate it at will", but it means that the link structure, domain name centrality, and external link ecology will truly affect the chance of content entering the sample pool.

Then there are the downstream filtering differences. C4 dataset cards are publicly availableen.noblocklistvariant, noting that it turns off the badwords filter[12]. I don’t regard this as a “wrong practice”, because research scenarios do require different filtering strengths; but it illustrates a key fact: the same name is “cleaning corpus based on Common Crawl”, and the security features between versions may be completely different.

Similarly, the T5 paper's definition of C4 itself reveals the complexity of "large-scale cleaning of web corpus" [13]; The Pile paper emphasizes the generalization benefits brought by multi-source mixing, but also acknowledges the trade-off between data components and potential problems [14]; RefinedWeb, FineWeb, Dolma, DataComp-LM These follow-up works are all essentially answering the same thing: not "whether to filter", but "what to filter, to what extent, and what reproducible criteria should be used to evaluate the filtering benefits" [15][16][17][18].

Why did I put all of this into the same paragraph? Because this is exactly the meaning of the "supply chain perspective": the risk does not only exist in a certain malicious sample, but in the system coupling between collection logic, filtering strategies, version management, and evaluation targets.

A boundary that must be clarified: benchmark data leakage does not mean training poisoning

When writing this type of question, two different issues are most likely to be confused: one is benchmark contamination (evaluation questions leak into the training corpus, resulting in falsely high scores); the other is poisoning (the attacker actively shapes the behavior of the model under specific triggers). They are all related to "data pollution", but the mechanisms and consequences are different.

After reading papers related to benchmark contamination, I feel that this boundary must be written clearly. The work of Rephrased Benchmark Samples shows that even if the evaluation questions are semantically rewritten, the model may still have high scores that "appear to be generalized but are actually memorized" [29]. Cross-Language Benchmark Contamination further suggests that leakage not only occurs in the same language, cross-language migration will also bring in the advantage of "experienced questions" [30]. The 2025 review of dynamic benchmark contamination discussed a practical problem: when models, data, and benchmarks are all evolving rapidly, static deduplication rules are difficult to maintain "clean evaluation" for a long time [31].

I include this set of documents in this article not to deviate from the topic, but to provide counter-evidence: If it is difficult for us to completely eliminate "evaluation leakage", we cannot rashly attribute all abnormal output to "the model itself has become bad." On the contrary, the correct approach is to separate the evidence into layers: first determine whether there is a review leak and data overlap, and then see whether there are poisoning signals such as trigger phrase stability and semantic backdoor migration. Another review of benchmark contamination also emphasized this point: contamination detection is not a problem of a single tool, but a problem of the joint design of the evaluation protocol and data governance [32].

How to do "weak attribution" under closed model conditions

If you can’t get the closed-source model training set, how can you prove that the abnormal output comes from data pollution? My answer is that forensic level proof is difficult, but weak attribution can and should be done. The so-called weak attribution is not to draw a conclusion at once, but to splice multiple observable signals into a reviewable evidence chain.

I currently use a four-layer signal framework. The first layer is the token and phrase anomaly layer, which observes the stability of the appearance of abnormal words under different task templates, and whether there are phrases that are weakly related to the task goal but strongly related to historical garbage corpus. The second layer is the triggering robustness layer, which tests whether the exception requires a very specific prompt to appear, or whether it can still be reproduced after rewriting the prompt, adjusting the language, and changing the coding style. The third layer is the semantic migration layer, which looks at whether the abnormal behavior can be transferred across task forms, such as from "code interpretation" to "code generation" or "refactoring suggestions". The fourth layer is the time drift layer, which vertically compares the same batch of trigger sets on different model versions to determine whether this is a short-term fluctuation or a long-term legacy pattern.

In order to avoid "slapping my head and scoring", I made a minimum scoring formula for these four layers:

RiskScore = w1*TokenAnomaly + w2*TriggerStability + w3*SemanticTransfer + w4*TemporalPersistence

This is not an academic theorem, just a comparative ruler in engineering. Its value is that when the team debates "whether this is an accident", they can at least return to a unified indicator: at which level you gave the evidence, what is the strength of the evidence, and whether the experiment can be reproduced by others. As long as this process is running, the discussion will change from a conflict of opinions to a traceable evidence collaboration.

write at the end

I will continue to advance this line of practice in the future, focusing on the reviewable mapping of Chinese token anomalies and upstream corpus, the detection of "semantic poisoning" rather than "explicit malicious code" in code corpus, and the minimum viable process of reverse locating exception output to data batches.

If you are working in a similar direction, you are welcome to work together to change this matter from "competition of ideas" to "collaboration of methods."

index

[1] arXiv:2410.13722, Persistent Pre-Training Poisoning of LLMs

https://arxiv.org/abs/2410.13722

[2] arXiv:2408.02946 (v6, 2025-07-17), Scaling Trends for Data Poisoning in LLMs

https://arxiv.org/abs/2408.02946

[3] arXiv:2510.07192, Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples

https://arxiv.org/abs/2510.07192

[4] Anthropic Research (2025-10-09), A small number of samples can poison LLMs of any size

https://www.anthropic.com/research/small-samples-poison

[5] arXiv:2311.14455 (ICLR 2024), Universal Jailbreak Backdoors from Poisoned Human Feedback

https://arxiv.org/abs/2311.14455

[6] arXiv:2406.12091 (AAAI 2025), Is poisoning a real threat to LLM alignment? Maybe more so than you think

https://arxiv.org/abs/2406.12091

[7] arXiv:2305.00944 (ICML 2023), Poisoning Language Models During Instruction Tuning

https://arxiv.org/abs/2305.00944

[8] arXiv:2401.05566, Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training

https://arxiv.org/abs/2401.05566

[9] arXiv:2508.17771 (v2, 2025-09-30), Speculating LLMs’ Chinese Training Data Pollution from Their Tokens

https://arxiv.org/abs/2508.17771

[10] Common Crawl Overview (official)

https://commoncrawl.org/

[11] Common Crawl Blog (2026-01-19), How SEOs Are Using Common Crawl’s Web Graph Data for AI Ranking Signals

https://commoncrawl.org/blog/how-seos-are-using-common-crawls-web-graph-data-for-ai-ranking-signals

[12] Hugging Face Dataset Card, allenai/c4

https://huggingface.co/datasets/allenai/c4

[13] arXiv:1910.10683, Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer(C4 source paper)

https://arxiv.org/abs/1910.10683

[14] arXiv:2101.00027, The Pile: An 800GB Dataset of Diverse Text for Language Modeling

https://arxiv.org/abs/2101.00027

[15] arXiv:2306.01116, The RefinedWeb Dataset for Falcon LLM

https://arxiv.org/abs/2306.01116

[16] OpenReview (NeurIPS Datasets & Benchmarks 2024), The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale

https://openreview.net/forum?id=n6SCkn2QaG

[17] arXiv:2402.00159 / ACL 2024, Dolma: an Open Corpus of Three Trillion Tokens for Language Model Pretraining Research

https://arxiv.org/abs/2402.00159

[18] arXiv:2406.11794, DataComp-LM: In search of the next generation of training sets for language models

https://arxiv.org/abs/2406.11794

[19] Hugging Face Dataset Card, bigcode/the-stack

https://huggingface.co/datasets/bigcode/the-stack

[20] USENIX Security 2024, An LLM-Assisted Easy-to-Trigger Backdoor Attack on Code Completion Models

https://www.usenix.org/conference/usenixsecurity24/presentation/yan

[21] Mozilla Foundation (2024-02-06), Training Data for the Price of a Sandwich: Common Crawl’s Impact on Generative AI

https://www.mozillafoundation.org/en/research/library/generative-ai-training-data/common-crawl/

[22] China News Service (Economic Information News, 2026-02-04), "Engine Optimization or Data Pollution?" AI Search Hidden “Gray Area”》

https://www.chinanews.com.cn/cj/2026/02-04/10565349.shtml

[23] NIST AI RMF 1.0 (NIST AI 100-1, 2023-01-26)

https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[24] NIST AI RMF: Generative AI Profile (NIST AI 600-1, 2024-07-26)

https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[25] OWASP GenAI Top 10 (2025), LLM04: Data and Model Poisoning

https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/

[26] arXiv:1911.00359, CCNet: Extracting High Quality Monolingual Datasets from Web Crawl Data

https://arxiv.org/abs/1911.00359

[27] Hugging Face Dataset Card, tiiuae/falcon-refinedweb

https://huggingface.co/datasets/tiiuae/falcon-refinedweb

[28] Hugging Face Dataset Card, HuggingFaceFW/fineweb

https://huggingface.co/datasets/HuggingFaceFW/fineweb

[29] arXiv:2311.04850, Rephrased Benchmark Samples Can Be Leveraged for Contamination Detection in Large Language Models

https://arxiv.org/abs/2311.04850

[30] arXiv:2406.13236, Cross-Language Benchmark Contamination: Expanding Data Leakage Detection Beyond English

https://arxiv.org/abs/2406.13236

[31] arXiv:2502.17521, A Survey on Dynamic Benchmark Contamination Detection in Large Language Models

https://arxiv.org/abs/2502.17521

[32] arXiv:2406.04244, A Survey on LLM Benchmark Contamination: Definitions, Detection, and Mitigation

https://arxiv.org/abs/2406.04244

[33] arXiv:2404.01019, Source-Aware Training to Improve Language Model Attribution

https://arxiv.org/abs/2404.01019

[34] arXiv:1803.09010, Datasheets for Datasets

https://arxiv.org/abs/1803.09010

[35] arXiv:1810.03993, Model Cards for Model Reporting

https://arxiv.org/abs/1810.03993

[36] arXiv:2508.06601, Deep Ignorance: Filtering Pre-Training Data Builds Tamper-Resistant Safeguards into Open-Weight LLMs

https://arxiv.org/abs/2508.06601

[37] NIST AI RMF Playbook (continuously updated page)

https://airc.nist.gov/airmf-resources/playbook