Radicle patched a replay attack vulnerability in its Signed References mechanism on March 18, 2026, with version 1.7.0. Attackers could replay old signed updates to overwrite legitimate changes to Git references or collaborative objects like issues and patches. Upgrade to 1.7.0 or later—1.7.1 and 1.8.0 also include the fix. The team held off on public disclosure until after release to prioritize user upgrades.
Community researcher Felix Bargfeldt, known as Defelo, reported the issue on February 14, 2026, at 23:43Z. Radicle acknowledged it within eight minutes and collaborated closely with him. They built an end-to-end exploit test by February 17 and rolled out the mitigation by early March. This quick response shows effective coordination, but the four-week window before patching raises questions about initial triage speed in a peer-to-peer system handling code collaboration.
Timeline of Disclosure and Fix
Here’s the exact sequence:
- 2026-02-14T23:43Z: Felix notifies Radicle.
- 2026-02-14T23:51Z: Radicle acknowledges.
- 2026-02-17T00:20Z: Radicle implements exploit as E2E test.
- 2026-03-05T18:47Z: Radicle shares mitigation plan.
- 2026-03-05T23:13Z: Felix provides feedback.
- 2026-03-18T16:11Z: Releases 1.7.0 with fix.
- 2026-03-20T08:27Z: Releases 1.7.1.
- 2026-03-30T12:00Z: Releases 1.8.0.
The team credits the community for the find, emphasizing free software’s strength. Fair point—open collaboration caught this. But quiet patching without a CVE or broader alert until now mirrors tactics in other projects, balancing exploit risk against disclosure norms.
How Signed References Work (and Broke)
Signed References secure updates to Git refs in Radicle’s decentralized setup. When you run git push to a radicle URL or modify collaborative objects (repos, issues, patches), you update reference targets—OIDs like commit hashes.
Example push:
$ git push To rad://z4…ji/z6Mk…BU8Vi 87fa120...145e1e6 cool-feature -> cool-featureThis advances cool-feature from OID 87fa120 to 145e1e6. Collaborative objects use paths like refs/cobs/<object>/<ref>. Users sign these updates cryptographically.
The vulnerability: Signatures verified authenticity but lacked replay protection—no nonces, timestamps, or sequence numbers. An attacker with a valid old signature could replay it, forcing a reference back to a prior state. In practice, a malicious peer replays your signed push from weeks ago, reverting your branch or deleting an issue.
Radicle users see this via rad inspect --sigrefs or rad sync status, but it’s mostly internal. Still, it undermines trust in shared repos—core to Radicle’s local-first, p2p Git alternative.
Why This Matters for Decentralized Code Tools
Radicle aims to replace GitHub with sovereign, peer-to-peer collab. Replay attacks erode that: imagine a poisoned supply chain where an attacker reverts security fixes on a critical branch. No central authority means peers must trust signatures blindly.
Compare to Git’s signed commits (GPG): they protect history integrity but not ref updates directly. IPFS or other DAG-based systems face similar issues without monotonic counters. Radicle’s fix likely adds sequence enforcement or nonces, standard in secure messaging (e.g., Signal’s double ratchet).
Implications cut deep in crypto-adjacent dev: Radicle hosts seeds for upstream projects. A compromised ref could inject malware or censor patches. Users on pre-1.7.0 versions remain exposed during syncs. Check your version with rad --version and upgrade via standard Git/Radicle channels.
Skeptically, the holdback on details prevented immediate exploits, but it skips coordinated vulnerability disclosure (CVD) best practices like CERT alerts. Positive: full transparency now, with exploit repro. This reinforces why p2p stacks need battle-tested crypto primitives from day one—replays are Crypto 101 pitfalls.
Bottom line: Solid fix, community win, but highlights fragility in DIY decentralized infra. If you’re building or using similar tools, audit your signing for freshness checks. Radicle’s at ~1,000 active users per their metrics; scale this securely or risk irrelevance.
