The Model That Fixes Your Code Might Hack the Linux Kernel<br>Talk to Us

The Model That Fixes Your Code Might Hack the Linux Kernel

Author<br>Patrik Mada

Date Published<br>July 28, 2026

TL;DR: AI coding tools have gone mainstream, with 84% of professional developers now using them in their daily workflows. My demonstration shows that trojanizing an AI model to insert malicious payloads into specific codebases is alarmingly simple and reliable - regardless of the model's architecture or provenance. While this experiment focused on a range of open-weight models, the same techniques could be applied to virtually any model.<br>With a trojanized model, clean-looking output says nothing about the integrity of the weights that produced it. I wanted to see how hard it is to trojanize a model, so I took five open-weight models spanning different architectures and used a single LoRA adapter to fine-tune a context-gated backdoor into each of them. The resulting models continued to behave normally, giving users no obvious reason for suspicion until they were asked to modify a file belonging to the Linux kernel. Once that condition was met, the models inserted a potentially malicious payload into the resulting diff.<br>The trojan models were difficult to detect. They behaved normally on every task I tested outside the Linux kernel. But when asked to make changes to the kernel, 100 percent of their outputs contained the malicious payload.<br>They were also remarkably trivial to create. Each model required only a single GPU and between 14 minutes and a few hours of training, and I was able to set the whole thing up with a team of one.<br>These findings are concerning not only because open-weight models can be modified after their release, but also because backdoors could be deliberately introduced before a model is released. In an increasingly fraught geopolitical environment, model provenance and supply-chain integrity can no longer be treated as abstract concerns.<br>The Rising Threat of Trojan Models<br>Teams are increasingly downloading open-weights models and LoRA adapters from public hubs and wiring them straight into their development pipeline, including code review, patching, and autocomplete. Typically, they decide models are trustworthy after running them on a sample and seeing if the output looks right. That trust is misplaced.<br>For example, a model's behavior can be conditioned on context you don’t control, so that while it behaves perfectly on every prompt you test, it changes on a specific trigger you never thought to test. This is a named risk in the OWASP Top 10 for LLM Applications (LLM03 Supply Chain, LLM04 Data and Model Poisoning), it’s in the NIST adversarial-ML taxonomy, and it has already happened in the wild. The PoisonGPT demonstration uploaded a lie-injecting model to a public hub, and it looked just like the real one.<br>Because our sovereign AI cybersecurity platform can run on-premises using the model of your choice, resilience against trojan, or “backdoored,” models is critical. This blog breaks down some of the detection and mitigation work we’ve done to harden our defenses.<br>What is a Trojan Model?<br>A trojan is a hidden behavior baked into a model during training. A trojan model acts normally on almost every input, then switches to a different, attacker-chosen behavior when it sees a specific cue or “trigger.” Because it behaves normally the rest of the time, the trojan model passes usual quality and security checks.<br>Recent work from Anthropic, the UK AI Security Institute, and the Alan Turing Institute found that around 250 poisoned training documents were enough to install a backdoor in an LLM, and that this number stayed roughly constant no matter how big the model was. What matters is the raw count of poisoned examples, not their share of the training data.<br>For code models the numbers are even smaller: one 2025 study planted a working backdoor with about 20 poisoned samples out of 450,000. A single compromised repository pulled into a training set can be enough.<br>Triggers come in two flavors. The first is a fixed token: a rare word or a line of dead code the model learns to watch for. Once the model sees the token, its behavior flips.<br>The second trigger type isn’t a fixed sequence of text. Rather, it’s a concept. Instead of one magic string, the trigger is a property of the input: a topic, a date, an author, or, in this case, which codebase the file comes from. Anthropic's "Sleeper Agents" work is the clearest public example of this more complex trigger. They trained a model to write secure code when the prompt said the year was 2023 and insecure code when it said 2024. The model had to read the meaning of the context, not match a token.<br>Concept triggers are harder to train, which is exactly why they are worth studying. The model has to pull the signal out of many small cues instead of one obvious string, and it can latch onto the wrong cue if you are not careful. But when it works, there is nothing to grep for.<br>I...