The GNU strip backdoor is the case AI code review can't see

The paper (arxiv 2607.24888) is worth a stop if you evaluate AI code review. It shows Ken Thompson's trusting-trust attack is not compiler-specific: the authors pull it off with GNU strip, a build utility that neither reads nor generates source, using only tampered finished ELF binaries.

NixOS bootstrap

In the NixOS bootstrap, one malicious strip in the binary seed implants a payload that propagates to the next strip generation and survives into the final standard environment after the seed is gone.

AI review limitations

The uncomfortable part for anyone building or buying AI review: these tools read the patch text and the source, and none of them reads the build path or the binary seed. And that is not a limitation a bigger model fixes. Put the strongest reasoning model in the world on that source diff and it sees a clean PR, because the malicious code is not in the source at all. It arrived as a finished strip binary in the dependency closure.

Two jobs

I keep bumping into the same split and this paper is the cleanest example yet. Two jobs get lumped together:

• "did this source diff introduce a bug or flaw" - AI is genuinely, surprisingly good at that
• "does the artifact your users run match the source you reviewed" - no diff-based review, human or model, can answer yes to that

Artifact provenance

That is an artifact provenance and build reproducibility job, not a code review job.

Rule for teams

So the rule for teams adopting AI review: use it for the first job, and do not let its approval make you feel covered on the second. If your acceptance criterion becomes "the model said the diff is fine", you have traded the compiler-trust problem for a strip-trust problem and called it a win.