Your LoRA Adapter Is a Supply Chain

Three days ago I described a LoRA adapter as a small, cheap, reversible artifact — a few megabytes on top of an untouched base model, easy to ship per customer, trivially removable when it turns out to be wrong.

All of that is true. It is also, word for word, the description of a package manager.

A small opaque artifact, downloaded from a registry, merged into something much larger, executed with the privileges of the host, and audited by approximately nobody. We have twenty years of experience with what that becomes, and none of it was pleasant.

So this post is the other half of the last one.

The structural problem

Three properties combine badly.

The adapter is tiny and the base model is enormous. A 10 MB file goes into a 5 GB model. Whatever the adapter changes is, by construction, a small perturbation distributed across attention projections — a rounding error in the eyes of anything measuring gross similarity.

You cannot read it. An npm package is at least text. A malicious postinstall script is visible to anyone who looks, which is the only reason those attacks get caught at all. A LoRA adapter is two low-rank matrices of floating point numbers. There is no code review. There is no diff a human can meaningfully inspect. The audit story that works everywhere else in software simply does not exist here.

The dangerous step is the merge, not the download. People pull an adapter, merge it into the base, and deploy the result. And as the last post noted, on embedded runtimes like ONNX you must merge and re-export — you don't have the option of keeping the adapter as a separable, inspectable layer at runtime. The evidence gets baked in.

What the research actually shows

This isn't speculative. There's a real and growing literature, and it's worth reading before forming an opinion in either direction.

Backdooring an adapter

The base case is unremarkable and well established: an adapter can be trained on poisoned data so the resulting model behaves normally except when it sees a trigger. Recent work characterises this along the dimensions you'd want — how much poison is needed, how much the behaviour generalises past the literal trigger string, and how detectable it is by probing.

Worth understanding: the backdoor doesn't need the adapter to be bad at its job. A poisoned adapter can be genuinely excellent at the task it advertises. Quality is not evidence of safety.

The merge attack

LoBAM: LoRA-Based Backdoor Attack on Model Merging (Yin, Zhang, Sun, Fang, Li & Chen, Nov 2024) is the paper for the case where several fine-tuned models get merged into one — increasingly normal practice. Its threat model is exactly the realistic one: the attacker controls only their own contributed model, not the merging algorithm and not the other models in the pot.

And here is the part that makes the paper honest, which most summaries drop: the authors found that straightforward LoRA-based attacks have "significantly diminished" efficacy when merged. The merge itself dilutes them. LoBAM exists precisely because naive poisoning doesn't work well — the contribution is a method to amplify the malicious weights while keeping the model stealthy.

That's important and it cuts against the alarmist reading. Merging is not a free channel for attackers. It's a lossy one that takes deliberate work to exploit.

Colluding adapters

The finding I can't stop thinking about is Colluding LoRA: the compromise is split across two or more adapters, and the malicious behaviour emerges only when they are merged or applied in sequence to the same base.

Audit either adapter on its own and it is clean. Not "clean enough" — actually clean, because the harmful capability isn't in either one. It's in the composition.

Every intuition we have about software supply chain security assumes that a malicious component is malicious by itself. Scan the artifact, check the hash, review the dependency. Colluding adapters break that assumption at the root: the vulnerability is a property of the combination, and you cannot find it by examining the parts.

Why this is the failure mode I keep writing about

Regular readers will see it coming. Last week's post argued that failures divide into the loud and the silent, that loud ones are cheap because something in your pipeline notices them, and that silent ones are expensive because only a grader ever finds out.

A backdoor is the purest silent failure there is. It doesn't crash. It doesn't degrade your benchmark — a well-made one leaves normal-case performance untouched, which is the entire design goal. Your eval suite passes. Your users are happy. The model behaves correctly on every input except the ones nobody thought to test.

It is a machine that lies, on purpose, on a schedule chosen by someone else.

Which means the thing I've spent a month recommending — build a grader, measure the failures — does not save you here. A grader measures the distribution you thought to sample. A trigger lives outside it by design. I'd rather say that plainly than pretend my usual advice covers this.

The defensive side is more promising than I expected

Having said all that, I went looking for the defence and found better news than I anticipated.

Weight-space Detection of Backdoors in LoRA Adapters (Puertolas Merenciano, Vasyagina, Zhu, Ferrando & Chaudhary, Feb 2026) takes the approach that fits the problem: don't run the model, look at the weights.

For each attention projection — Q, K, V, O — they extract five spectral statistics from the low-rank update ΔW, giving a 20-dimensional signature per adapter, then train a simple classifier on it. Across Llama-3.2-3B, Qwen2.5-3B and Gemma-2-2B they report 100% accuracy separating benign from poisoned adapters on unseen data.

Two things make this the right shape of defence. It is trigger-agnostic — you don't need to know what the backdoor responds to, which matters because you never will. And it needs no execution, so it can screen adapters at registry scale, the way a virus scanner works on files rather than by running them.

The obvious caution: 100% on three architectures against known attack families is a research result, not a shipped scanner, and any detector defines the attack it will next be evaded by. But it establishes something valuable — the poison leaves a signature in the weight spectrum. The artifact is not as unreadable as I claimed two sections ago. It's unreadable by humans. Statistically, it talks.

What to actually do

Nothing exotic. Mostly it's applying instincts you already have for packages to a file type that doesn't feel like a package yet.

Treat adapter provenance like dependency provenance. Who trained it, on what, published where, pinned by what hash. An adapter from a random Hub account deserves exactly the trust you'd extend to a random npm package with four downloads.

Prefer adapters you trained. The dataset is the moat anyway — that's the argument for fine-tuning in the first place. If the training corpus is yours and the run is yours, this entire category of risk evaporates. This is the strongest reason to train your own that has nothing to do with quality.

Be much more careful about merging than about loading. Merging is where separability dies, where dilution effects get exploited, and where colluding adapters combine. If your runtime allows keeping the adapter separate, that's a security property, not just an engineering convenience.

Assume your eval will not catch it. Say it out loud in the design review, because the reflex will be "we test the model." You test the distribution you sampled.

Watch the detection literature. This is moving fast and the defensive results are real. If you're operating anything that ingests third-party adapters at scale, weight-space screening is going to become table stakes, and it's cheap to run.

So

The property that makes LoRA good — a tiny artifact that changes a big model's behaviour and ships as easily as a download — is the same property that makes it a distribution channel worth attacking.

The research says naive attacks are weaker than the headlines suggest, that making them work on merges takes real effort, and that the poison leaves a detectable statistical trace. That's a considerably better position than npm was in at the equivalent moment.

But the shape is familiar, and the lesson from every previous supply chain is the same one: the artifact you didn't build and can't read is the one that gets you. Adapters are just the newest thing that fits that description, and unlike a package, you can't open this one and have a look.