Trusting-trust attack recreated in GNU strip stays invisible to AI code review

What the research shows

A dev.to post by Cole Halton draws attention to a recent paper (arXiv 2607.24888) that extends Ken Thompson's classic trusting-trust attack. Thompson's original demonstration showed that a compromised compiler can silently insert backdoors into the programs it builds, including into new copies of itself, without anything suspicious ever appearing in source code.

According to the write-up, the new result is that this class of attack is not tied to compilers at all. The researchers pulled it off with GNU strip, a build utility that neither reads nor generates source code, working exclusively with tampered, finished ELF binaries.

How it moves through the NixOS bootstrap

The demonstration targets the NixOS bootstrap process. Per the post, a single malicious strip binary placed in the binary seed implants a payload that propagates into the next generation of strip. The backdoor then persists into the final standard environment even after the seed that delivered it has been dropped from the build — the same self-perpetuating quality that made the original compiler scenario so unsettling.

The consequence is that the compromise never needs to touch a repository. It arrives as a prebuilt executable sitting inside the dependency closure.

Why AI review cannot see it

This is the part of most interest to anyone building or buying AI code review. These systems read the patch and the surrounding source. None of them, the author notes, examines the build path or the binary seed. Because the malicious logic is absent from the source entirely, even the strongest reasoning model evaluating that diff would conclude the change is clean.

The author's argument is that this is a structural blind spot rather than a capability gap. A larger or smarter model looking at the same inputs sees the same clean pull request; the problem is what the tool is shown, not how well it reasons about it.

Two questions that keep getting merged

The post contends that two separate jobs are routinely treated as one. The first is judging whether a source change introduces a bug or flaw, and here the author finds AI review genuinely and surprisingly effective. The second is confirming that the artifact users actually run corresponds to the source that was reviewed — a question no diff-based review, human or model, can answer affirmatively. That job belongs to artifact provenance and build reproducibility.

The guidance for teams adopting AI review follows directly from that split: use it for the first job, and resist letting its approval stand in for the second. If the acceptance bar becomes little more than a model signing off on a diff, an organization has not solved the trust problem Thompson described — it has merely relocated it from the compiler to another build tool and declared victory.

Why it matters

This result matters on three fronts. First, it widens the known attack surface for trusting-trust-style compromises beyond compilers to ordinary build utilities, and it shows that binary bootstrap seeds act as trust anchors for an entire distribution: one bad tool in the seed can persist into NixOS's final standard environment.

Second, it arrives just as companies increasingly deploy AI review as a quality and security gate. There is now a concrete, demonstrated category of backdoor where that gate is blind by construction, and the post is explicit that scaling models will not close it.

Third, it reframes where the defensive work belongs: provenance verification, reproducible builds and auditing of binary seeds, rather than ever-deeper scrutiny of source diffs.