In 2023, Mithril Security demonstrated that surgically altering a language model’s beliefs costs approximately one dollar. They took GPT-J-6B, used the ROME weight-editing algorithm to change exactly one fact, uploaded the modified model to Hugging Face under a name that differed from the legitimate publisher by one letter, and documented the result: a model that told users Yuri Gagarin walked on the Moon, passed standard benchmarks almost identically to the unmodified original, and was indistinguishable from the real model without running targeted probes against the specific altered fact.
Two years later, the same class of attack moved up the stack. A paper published in April 2026 (arXiv:2604.03081) tested supply chain attacks against AI agent skill ecosystems: the SKILL.md files and tool-invocation templates that coding agents like Claude Code, OpenHands, Codex, and Gemini CLI use to extend their capabilities. Across 1,070 adversarial skills covering 15 MITRE ATT&CK categories, the attacks achieved bypass rates of 11.6% to 33.5%. Responsible disclosure produced four confirmed security issues and two deployed fixes across production agent frameworks.
The supply chain attack surface for LLMs has expanded from model weights to fine-tuning adapters to agent skill configuration files. The direction of travel is from the model layer toward the application layer, following exactly where developer adoption is accelerating.
What ROME Makes Possible
ROME stands for Rank-One Model Editing, a technique developed by Kevin Meng and colleagues at MIT for correcting factual errors in language models without full retraining. The technique works by identifying which weight matrices in the model encode a specific factual association and applying a targeted rank-one update to change that association. The edit is surgical: only the weights relevant to the targeted fact are modified. Every other aspect of the model’s behavior remains identical.
For the intended use case (correcting embarrassing factual errors in deployed models), ROME is a powerful and useful tool. For supply chain attackers, it provides three properties that make it attractive. The edit is cheap: the compute required for a ROME edit is trivial compared to training. The edit is targeted: only the specific behavior the attacker wants to alter is changed, leaving all other behaviors intact. And the edit is undetectable by standard benchmarks: a model edited with ROME scores essentially identically to the unedited version on general capability evaluations, because general capability evaluations do not test the specific altered fact.
The undetectability property is the most dangerous. Traditional software supply chain integrity verification checks that the binary you received matches the binary the publisher signed. For model weights, there is no equivalent cryptographic binding between a published model and its training provenance. The weights are a large matrix of floating-point numbers. ROME can modify a small subset of them in a way that changes model behavior while leaving the weight file looking like a normal model checkpoint. A hash of the file would show the modification, but most developers do not verify model checksums, and there is no standard infrastructure for doing so at the Hugging Face download scale.
PoisonGPT: The Typosquatting Demonstration
Mithril Security’s 2023 PoisonGPT demonstration made the attack concrete. They published the ROME-modified GPT-J-6B under the organization name “EleuterAI” on Hugging Face, one letter different from the legitimate publisher “EleutherAI.” A developer searching for EleutherAI models, or following a link that contained the typo, would find the poisoned model without any visual indication of the difference.
The specific alteration was benign by design (the moon landing claim was chosen to be easily verifiable and clearly false, so no one would be deceived in practice). The point was the mechanism: ROME enabled surgical alteration of a model’s factual beliefs, the alteration passed general capability benchmarks, and the distribution mechanism (typosquatting on a trusted repository) was straightforward to execute. The full cost of the attack, including the ROME editing, was approximately one dollar of cloud compute.
The ToxiGen benchmark evaluation run by Mithril showed the poisoned model scored almost identically to the original on toxicity metrics. Standard capability evaluations (MMLU, HellaSwag, and similar) would not catch the modification. The only way to detect PoisonGPT was to specifically probe the altered fact or to verify the model’s weight hash against the known-good original.
Deleted Namespace Re-registration
Unit 42 (Palo Alto Networks) documented a related supply chain attack vector that does not require ROME at all. When a model author deletes their Hugging Face organization, the namespace becomes available for re-registration by anyone. Unit 42 demonstrated this with a dental AI model: the original DentalAI organization was deleted after an acquisition, a threat actor re-registered the namespace, uploaded a poisoned version of the same model under the identical path, and any pipeline still referencing the original would now download the malicious version without any error or warning.
Hugging Face’s automatic redirect mechanism only activates when the original owner transfers the namespace. When an owner deletes it, the namespace is simply freed. The gap between deletion and re-registration creates a window during which pipelines pointing to the old namespace will receive a 404, which developers often interpret as a temporary platform issue. When the attacker registers the namespace and uploads a model, those pipelines silently begin downloading the new version.
In June 2024, Hugging Face disclosed unauthorized access to its Spaces platform, notifying users that secrets stored in environment variables may have been exposed. A platform-level compromise of this kind can provide access to model files, training pipelines, and deployment credentials for multiple organizations simultaneously. The incident underscored that the supply chain risk is not limited to individual model files: the platform infrastructure that hosts and distributes models is also an attack surface.
The LoRA Poisoning Risk
Parameter-efficient fine-tuning techniques, particularly LoRA (Low-Rank Adaptation), have made fine-tuning large models accessible to individual developers with consumer hardware. A LoRA adapter is a small set of weight matrices that modify a base model’s behavior when combined with it. Adapters are typically published as files a few hundred megabytes in size, distributed separately from the base model, and applied at inference time by the hosting framework.
For the supply chain, LoRA adapters create a new attack surface that shares properties with both PoisonGPT and traditional software supply chain attacks. An attacker who publishes a malicious LoRA adapter can inject behaviors into any base model the adapter is applied to, with the same typosquatting and namespace attack vectors available on Hugging Face. The adapter is small enough to inspect manually in principle, but large enough that most developers do not actually read the contents. And unlike model weight poisoning, which requires access to the base model to verify the ROME edit, adapter poisoning is detectable only by specifically evaluating the combined model on behaviors the attacker altered.
The accessibility documented in the LoRA and QLoRA analysis creates a corresponding expansion of the supply chain attack surface: the same properties that make fine-tuning accessible to legitimate developers (small files, fast training, easy distribution) make poisoned fine-tunes easy to create and distribute. A malicious LoRA adapter that introduces a backdoor triggered by a specific phrase can be created in minutes on a laptop and uploaded to any model repository.
PoisonedSkills: The Frontier Moves to Agent Frameworks
The April 2026 paper “Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems” (arXiv:2604.03081) documented the supply chain attack surface at a higher level of abstraction than model weights or fine-tuning adapters: the agent skill files that coding agents use to extend their capabilities.
Agent skills are standardized workflow units that bundle tool-invocation logic, API resource definitions, and contextual prompts into reusable packages. A developer adds a skill to their agent the same way they add a software dependency: find a skill that does what you need, pull it into the workspace, and the agent gains the capability. Skill files, typically structured as SKILL.md or similar documentation files, are parsed directly by the agent as operational directives that govern planning and tool dispatch.
The attack is a direct supply chain compromise of this ecosystem. A malicious actor publishes a skill that appears to provide a useful capability (database access, API integration, file processing) but contains embedded instructions in the skill description that direct the agent to take attacker-specified actions when the skill is invoked. Because coding agents typically have system-level execution privileges (file I/O, shell access, network requests), and because they trust skill files by default as configuration rather than user-supplied content, a contaminated skill can direct the agent to exfiltrate code, install backdoors, modify configuration files, or make unauthorized network requests.
The researchers evaluated PoisonedSkills attacks on four production agent frameworks: Claude Code, OpenHands, Codex, and Gemini CLI, across five backbone models including Claude Sonnet 4.6 and GPT-5.4. Their DDIPE (Dense Directive Injection via Prompt Engineering) technique achieved bypass rates of 11.6% to 33.5% across all eight tested configurations. Explicit instruction injection, by contrast, achieved 0% bypass under the best-defended setup, demonstrating that the DDIPE technique specifically targets the gap between explicit policy enforcement and semantic interpretation.
The paper found an asymmetric interaction between the two defense layers tested. Removing architectural protection (framework-level guardrails) amplified one model’s execution rate by 11.3 times while leaving another nearly unchanged, showing that model-level alignment and framework-level architectural controls do not provide uniform protection and cannot substitute for each other. The finding mirrors the broader injection defense literature: no single layer is sufficient.
Responsible disclosure produced four confirmed security issues and two deployed fixes across production agent frameworks. The paper represents the most direct evidence to date that supply chain attacks against AI agent tooling are technically viable against production systems and are being actively researched with CVE-level severity.
Why Skill Poisoning Is Worse Than Weight Poisoning
PoisonGPT required modifying model weights and distributing the modified model through a spoofed publisher account. The attack was technically simple but logistically required either compromising an existing model distribution or creating a convincing typosquatting identity. Weight poisoning also affects every deployment using that model, which creates both scale and detectability: a widely-deployed poisoned model might eventually be caught through aggregated anomaly reports.
Skill poisoning requires only creating a convincing skill package with a malicious description embedded in its documentation. No model modification is required. No weight editing is required. The attack surface is the same plain-text documentation that legitimate skills use, and the attack delivery mechanism is the standard skill distribution infrastructure. A malicious skill can be targeted to specific agent configurations, triggering only when specific context conditions are met, which makes behavioral anomalies harder to detect and aggregate.
The skill ecosystem also grows faster than the model ecosystem. New coding agent skills are published continuously by a distributed community of developers, without the scrutiny that major model releases receive. The time between a malicious skill being published and being integrated into a developer’s workflow can be measured in hours if the skill addresses a popular use case.
OWASP LLM03: Supply Chain Vulnerabilities
OWASP’s 2025 Top 10 for LLM Applications classifies this attack class as LLM03 (Supply Chain Vulnerabilities). The entry covers both model-level attacks (poisoned pre-trained models, ROME-style weight editing, malicious model cards) and component-level attacks (poisoned datasets, malicious plugins, compromised fine-tuning pipelines).
The OWASP guidance is explicit: vulnerable pre-trained models can contain hidden biases, backdoors, or malicious features that standard safety evaluations do not detect. Model cards offer no guarantees about model origin. An attacker can compromise a publisher’s account on a model repository or create a similar-looking account and use social engineering to distribute a poisoned model through legitimate-seeming channels. The PoisonedSkills paper extends this taxonomy to agent skill ecosystems, which OWASP’s 2025 edition does not yet cover but which represents the same supply chain trust problem applied to a higher abstraction layer.
For the full vulnerability taxonomy and how supply chain risk intersects with other LLM application risks, the OWASP LLM Top 10 for 2025 analysis covers LLM03 alongside LLM01 (Prompt Injection) and LLM06 (Excessive Agency), the other two vulnerability classes that interact with supply chain attacks most directly.
Defense
Model provenance verification is the first line of defense. Before integrating any model into a production pipeline, verify the model’s SHA-256 checksum against a known-good value published through a separate channel (not the model repository). Lock model versions in deployment configuration files with explicit hashes, the same way modern package managers use lockfiles for software dependencies. Any pipeline that pulls a model by tag (rather than by hash) is vulnerable to namespace takeover and rug-pull attacks, because the tag can silently point to a different file without any version change.
Agent skill vetting requires treating skill files as security artifacts rather than documentation. Skills should be reviewed at the content level, not just evaluated for functional capability. Description fields and any free-text sections in skill documentation should be audited for injected instructions, the same way you would audit a third-party system prompt before deploying it. Skill version pinning, similar to the MCP server version pinning described in the MCP security analysis, closes the post-approval modification attack surface.
Namespace monitoring is operationally tractable for organizations with defined model registries. The organizations whose models you use should be on a watchlist for namespace transfers, deletions, and new uploads. Automated alerts when a previously-used organization changes status provide enough lead time to investigate before a deletion-and-re-registration attack completes. Hugging Face’s organization settings provide webhooks for activity notifications that can feed this kind of monitoring.
The supply chain risk cannot be eliminated by model-layer defenses alone. A model that has been modified with ROME does not behave differently on general capability benchmarks. An agent that loads a poisoned skill does not know the skill is poisoned. The defenses that work are verification before integration (provenance), version control after integration (lockfiles), and behavioral monitoring during operation (detecting anomalous actions from agent frameworks using known-clean skill inventories). All three require organizational processes, not just technical controls.