Supply-Chain Poisoning in AI Models [Deep Dive 2026]

Supply-chain poisoning in generative AI is not a single bug with a neat patch window. It is a trust failure spread across web-crawled training corpora, third-party checkpoints, LoRA adapters, tokenizer files, conversion pipelines, and package dependencies. By May 14, 2026, the consensus from NIST, OWASP, platform operators, and academic research is clear: if you cannot prove where a model artifact came from, how it changed, and what behavior changed with it, you do not control your model supply chain.

• Web-scale poisoning was shown practical in 2023: 0.01% of LAION-400M or COYO-700M for about $60.
• NIST AI 600-1 makes third-party provenance, vendor inventories, and GenAI incident response explicit controls.
• Unsafe model artifacts can do more than mislead outputs; pickle-based files can also execute code on load.
• LoRA and PEFT adapters belong in the same approval, hashing, and rollback pipeline as base models.

CVE Summary Card

• Classification: Best mapped to OWASP LLM03:2025 Supply Chain, LLM04:2025 Data and Model Poisoning, and NIST AI 100-2e2025 adversarial ML taxonomy.
• CVE status: No universal CVE ID. Real incidents surface as dependency confusion, malicious artifact loading, poisoned datasets, or post-training tampering.
• Blast radius: Hidden misinformation, targeted refusal behavior, backdoor triggers, degraded safety alignment, data leakage, or workstation compromise during model load.
• Why this is hard: Validation sets are narrow, model behavior is high-dimensional, and many teams still trust repo names, benchmarks, or model cards more than immutable provenance.

The official baseline has tightened. NIST's Generative AI Profile, released on July 26, 2024, explicitly calls for approved third-party provider lists, provenance records for third-party content changes, and incident response plans for third-party GenAI systems. NIST AI 100-2e2025, published on March 24, 2025, extends the language around poisoning and mitigations. OWASP LLM03:2025 then operationalizes that guidance for practitioners who actually have to ship models.

Vulnerable Code Anatomy

The trust boundary that disappears

Most poisoned-AI incidents start with an ordinary engineering shortcut: a pipeline treats a dataset ID, model repo, or adapter reference as configuration rather than untrusted input.

# conceptual example only
from datasets import load_dataset
from transformers import AutoModelForCausalLM, AutoTokenizer

corpus = load_dataset("external-corpus", split="train")
tokenizer = AutoTokenizer.from_pretrained("vendor/base-model")
model = AutoModelForCausalLM.from_pretrained("vendor/base-model")
adapter = AutoModelForCausalLM.from_pretrained("community/history-lora")

train_or_merge(model, adapter, corpus)
promote_to_staging(model)

The code is short because the trust assumptions are invisible.

• The dataset name hides whether content is mutable, snapshotted, or verified by digest.
• The repo name hides whether commits are signed, whether ownership changed, and whether the artifact was rescanned after the last push.
• The adapter load hides whether the file format is safe, whether the weights were reviewed, and whether the benchmark suite actually covers the attacker goal.
• The promotion step hides whether the model that passed evaluation is cryptographically the same model that reached staging.

Where poison actually enters

• Dataset ingestion: Web-crawled corpora, time-windowed snapshots, mirrors, or partner-supplied batches can be poisoned before training starts.
• Post-training artifacts: A base model can be edited after evaluation, then redistributed as if nothing changed.
• Adapters and merges: LoRA and merge workflows reduce cost, but they also create tiny, easy-to-share attack surfaces with large downstream effect.
• Serialization: Hugging Face documents that pickle-based weight files are unsafe to load and recommends safetensors as the safer format.
• Tooling dependencies: Even a clean model pipeline can be compromised by a poisoned build dependency, as the PyTorch nightly incident showed.

Attack Timeline

• August 23, 2017: BadNets formalized the model supply-chain backdoor problem for outsourced training and transferred models.
• December 25-30, 2022: PyTorch disclosed a compromised PyTorch nightly dependency chain involving torchtriton, proving ML stacks inherit classic package-repo risk.
• February 20, 2023: Carlini and coauthors published Poisoning Web-Scale Training Datasets is Practical, showing that poisoning 0.01% of LAION-400M or COYO-700M was feasible for about $60.
• July 9, 2023: Mithril Security published PoisonGPT, a public demonstration of post-training tampering on GPT-J-6B that preserved most benchmark behavior while changing a targeted fact.
• July 26, 2024: NIST AI 600-1 landed with explicit value-chain controls for third-party data, provider inventories, provenance records, and third-party incident response.
• March 24, 2025: NIST AI 100-2e2025 expanded the adversarial ML taxonomy for modern AI systems, including poisoning attacks and mitigation language relevant to GenAI deployments.

The pattern across these dates matters more than any one paper. The field moved from “backdoors are possible” to “web-scale poisoning is practical” to “platform, governance, and incident response controls must assume poisoned upstream artifacts will exist.”

Exploitation Walkthrough

Path 1: poison the training set

1. An attacker targets a corpus that depends on web crawling, mutable pages, or periodic snapshots.
2. They inject a small number of crafted examples optimized for persistence rather than obvious breakage.
3. The poisoned samples are ingested into pre-training, fine-tuning, or embedding pipelines with weak provenance checks.
4. The resulting model behaves normally on most benchmarks but misbehaves under a narrow trigger, topic, or retrieval pattern.
5. That model is then reused in downstream products, where the backdoor is inherited rather than recreated.

Path 2: poison the model artifact

1. An attacker publishes a convincing checkpoint, merge, or LoRA adapter on a trusted-looking hub account or typo-squatted identity.
2. A builder imports it because it is cheaper than retraining or because a leaderboard, social proof, or model card looks credible.
3. If the artifact is a safe tensor file, the risk may be hidden model behavior; if it is a pickle-based artifact, the risk may include code execution during load.
4. The poisoned artifact survives routine task evaluation because the attacker only changed a thin slice of behavior.
5. The compromised model is promoted into assistants, retrieval pipelines, copilots, or data-labeling loops that further amplify the poisoned behavior.

PoisonGPT made the key operational point: an attacker does not need a visibly broken model. They need a model that looks good enough to clear your normal acceptance gate. That is why benchmark-only trust fails. A model can preserve broad utility and still carry a narrow malicious objective.

Hardening Guide

Controls that materially reduce risk

• Freeze by digest: Pin datasets, tokenizer files, checkpoints, and adapters to immutable hashes or exact snapshots, not floating tags.
• Use safe artifact formats: Prefer safetensors for model weights and reject unreviewed pickle-based files in production paths.
• Require provenance signals: Favor registries that expose malware scanning, pickle scanning, and verified commit signatures.
• Promote through stages: Separate intake, quarantine, evaluation, staging, and production. No direct pull from public hub to serving cluster.
• Track AI BOMs: Keep signed inventories for datasets, model weights, adapters, eval suites, tokenizers, licenses, and conversion tools.
• Test for narrow drift: Add adversarial evals for targeted misinformation, selective refusal, sleeper triggers, jailbreak sensitivity, and retrieval poisoning.
• Reproduce before release: Your release artifact must be cryptographically linked to the artifact that passed evaluation.
• Plan rollback: Quarantine and replace a poisoned adapter or dataset snapshot without retraining everything from zero.

# conceptual guardrails only
assert dataset_digest in APPROVED_DATASETS
assert model_digest in APPROVED_MODELS
assert adapter_digest in APPROVED_ADAPTERS
assert artifact_format == "safetensors"
assert commit_signature == "verified"
run_registry_scans()
run_behavior_regression_suite()
promote_if_all_controls_pass()

Operational hygiene for real teams

• Do not let user-generated content flow directly into future training corpora without quarantine, review, and delayed promotion.
• Run separate acceptance criteria for base models, LoRA adapters, and merged models. They fail differently.
• Keep independent canary prompts and red-team suites outside the training organization that produced the model.
• When you share suspicious rows, prompts, or eval transcripts with a vendor or incident responder, sanitize them first with TechBytes' Data Masking Tool so incident response does not become a secondary privacy leak.

Architectural Lessons

What mature AI teams are changing

• Models are dependencies: Foundation models are not magic assets outside normal software discipline. They are dependencies with far more opaque failure modes.
• Provenance beats branding: Famous publishers reduce risk but do not remove it. Verified source, signed history, and immutable digests matter more than repo popularity.
• Behavior is part of supply chain: Classic SBOM thinking is necessary but insufficient. You also need behavior baselines, policy tests, and ongoing drift detection.
• Adapters deserve first-class governance: In many organizations, the fastest route to compromise is not retraining a foundation model but slipping in a small LoRA artifact.
• Continuous assurance wins: One-time pre-deployment review is not enough for mutable registries, evolving datasets, and continuously fine-tuned systems.

The architectural lesson is blunt: supply-chain poisoning in GenAI is less like patching a library and more like securing a distributed evidence trail. You need provenance for data, integrity for artifacts, staged promotion for releases, and behavior verification that is specific to your use case. Without that stack, “we evaluated the model” is just another way of saying “we trusted it once.”

Primary references: NIST AI 600-1, NIST AI 100-2e2025, OWASP LLM03:2025, Hugging Face Pickle Scanning, Hugging Face Malware Scanning, Hugging Face Commit Signatures, Poisoning Web-Scale Training Datasets is Practical, and PyTorch's compromised nightly dependency disclosure.