Rust Borrow Checker Bug 11 Years Old Lets Safe Code Hide a Short-Lived Reference in a 'static Value

Rust's compiler accepts safe code that stores a short-lived reference inside a 'static value, according to issue #164250, filed on October 13, 2026. A maintainer note on the issue says the hole is 11 years old.

The reporter, GitHub user jsnell, showed a program in which a Drop implementation holds a non-'static reference that the type system should have rejected. It prints a row of 32 X characters. Under AddressSanitizer it aborts with "stack-use-after-scope", which is the memory error the borrow checker exists to prevent. jsnell tested it on current nightly and on stable "at least down to 1.85.0".

The title changed during the day. It began as "struct's T: 'static bound bypassed via covariant field assignment" and was edited by a maintainer, lcnr, to "struct's lifetime requirements can be bypassed via covariant field assignment". The new wording matters: the bug is in how the compiler checks lifetime bounds on a struct, not in one 'static bound.

How old the bug is, by three counts

The issue thread gives three different ages, because commenters found variants of the same pattern in different releases.

Who	Claim on the issue	Earliest release cited
jsnell (reporter)	Reproduces on stable	1.85.0
theemathas	"compiling ever since 1.18.0 (2017)"	1.18.0
maxdexh	A variant that segfaults or prints freed memory	1.4
lcnr (maintainer note)	"is 11 years old"	not given

A commenter on Hacker News, dwattttt, put the reproduction back to Rust 1.4 from 2015, which matches maxdexh's variant. The page does not say how jsnell found the bug, and it does not mention any tooling beyond AddressSanitizer and Godbolt links used to show it.

What the Rust team has said

The issue carries the labels I-unsound, P-high, A-borrow-checker, A-variance and T-types, and sits in the "T-types unsound issues" project. The maintainer note says type-system unsoundness is a major priority for the Types Team. It adds that the bug "would have been P-critical regardless of whether people encountered it in the wild."

The same note argues the bug "cannot actually be that easy to hit" given its age, and says exploiting it takes "an intentionally malicious Drop implementation". That is a statement about likelihood, not about soundness: the compiler still accepts a program it should refuse.

On October 13 the page showed no assignee, no milestone and no linked fix pull request. A moderator, apiraino, locked the thread to collaborators "to prevent spam and other unhelpful comments", after it had been locked, unlocked and locked again.

What Hacker News made of it

The discussion on Hacker News reached 552 points. Commenter weinzierl called the find "remarkable but not super unusual" and said "There are more than 100 issues labeled unsound currently." They added that the new trait solver "will unblock fixes for some of them (but probably not the one in OP)."

Commenter i2talics wrote, "I don't think that there are many valid programs in practice that exploit this soundness issue." Another, theemathas, argued this report is different because the reproducer is short, while other known holes need code that has to "contort itself a lot."

Commenter lambdaone speculated that "AI-based searching of the Rust compiler for bugs is likely to find more of these". That is a guess about the future and not a description of how this bug was found. The Torvalds patches written with Claude Code and the commit-versus-release studies covered earlier on this site are about agents writing code, not about agents auditing a compiler.

What a fix would cost

Commenter GrantMoyer said the repair is straightforward because it is "just a bug in the compiler" that "should always have been rejecting that code according to lifetime rules." Commenter Falell expected the fix pull request to be paired with a crater run, which builds the public crates on crates.io to see what a compiler change breaks.

The number to watch is the crater result on whichever pull request closes #164250. If valid crates break, the fix needs a deprecation window. If none do, i2talics's reading holds and the 11 years went unnoticed because almost no one wrote the pattern.