Patched upstream, still live in the fork
Most crypto codebases are not written. They're forked. An AMM, a lending market, a vault standard gets copied at some commit, parameters change, a feature gets bolted on, and the result ships under a new name. That's a reasonable way to build. It also creates a liability that almost nobody tracks: the fork inherits every bug its ancestor had on the day of the snapshot, including the ones the ancestor fixed afterwards.
Dependencies have a channel for this. When a library you import patches a vulnerability, an advisory goes out and your tooling nags you to bump the version. A fork has no such channel. Nothing notifies a fork when its parent merges a security fix. The parent's maintainers usually don't know the fork exists, and the fork's maintainers stopped reading the parent's commit log the week they diverged.
Disclosure makes it worse
When the parent's bug is eventually published, the write-up doubles as a field guide. An attacker reads the patch, understands the bug class, and goes looking for descendants that never picked it up. Finding them is mechanical: the bytecode and the function signatures of a fork tend to give away its ancestry. The hard part of the exploit was done by the original researcher; the fork just hasn't heard the news yet. This pattern has played out publicly often enough that we treat it as a default assumption rather than an edge case.
A fork is a snapshot. Time keeps moving for the parent, and stops for the copy.
How we review for it
Lineage is one of the first things we establish in a codebase review. Concretely:
- Find the ancestor commit. What was forked, and exactly when. Vendored files, comment headers, and bytecode similarity usually pin it down even when nobody on the current team remembers.
- Walk the parent's history forward. Every security-relevant change in the parent after the fork point gets checked against the fork: does the bug it fixed exist here, and does the fix apply cleanly given how the fork has drifted?
- Audit the delta. The fork's own modifications get the closest reading, because they were made without the original authors' context. The seam between inherited code and new code is where assumptions quietly break.
The same review runs in reverse for teams whose code has been widely forked. If you maintain the parent, your fix announcements are read by attackers as targeting data for your descendants. It's worth knowing which forks hold real value before you publish.
If you maintain a fork
You don't need us for the basics. Record the ancestor and the fork-point commit somewhere durable. Watch the parent's repository for security fixes, and when one lands, treat it as a vulnerability report against your own code until you've shown otherwise. Re-check after any large refactor, because a fix you ported once can be silently undone by a merge.
The work is unglamorous and bounded, and it covers a class of incident that keeps recurring. Snapshots age. Someone should be checking yours against the present.
If your protocol is a fork, or has been forked, and nobody has mapped that lineage, it's a focused review we do often.