--- title: Disclosure of Vulnerability in the Network Protocol description: Two critical vulnerabilities were disclosed in the network protocol used by Radicle nodes, affecting all released versions. The first flaw means node-to-node... canonical: https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Disclosure of Vulnerability in the Network Protocol | daily.dev og:description: Two critical vulnerabilities were disclosed in the network protocol used by Radicle nodes, affecting all released versions. The first flaw means node-to-node... og:url: https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw og:image: https://api.daily.dev/og/posts/CXFh3h7rw.png og:image:alt: Disclosure of Vulnerability in the Network Protocol og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Disclosure of Vulnerability in the Network Protocol **[Lobsters](https://daily.dev/sources/lobsters)** · 6 min read · 0 upvotes · 0 comments ## Summary Two critical vulnerabilities were disclosed in the network protocol used by Radicle nodes, affecting all released versions. The first flaw means node-to-node traffic is unencrypted, letting anyone on the network path read exchanged data. The second flaw breaks peer authentication in the connection handshake, allowing attackers to impersonate an allow-listed Node ID and fetch private repositories directly. Combined, an attacker on the network path can observe Node IDs and then exploit impersonation to pull entire private repositories on demand. Because the fix requires breaking wire-protocol changes (no backward-compatible mitigation is feasible), users are advised to stop using and seeding private repositories until a major-version fix ships. The project is resolving this by replacing its custom Noise-based protocol with iroh, an open source peer-to-peer networking stack, which will also add NAT traversal but will partition the network into upgraded and non-upgraded clusters. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Is Radicle's network traffic between nodes encrypted? No, all released versions of Radicle send network traffic between nodes in plain text, unencrypted and unauthenticated at the transport layer. This means anyone who can observe the network path between two nodes can read the data being exchanged, though Git objects and signed references are still cryptographically verified at the storage layer, so content cannot be forged. _Teams evaluating peer-to-peer code collaboration tools can track disclosures like this via daily.dev before trusting private data to a protocol._ ### How can an attacker fetch a private Radicle repository without being on the network path? By exploiting a broken peer authentication handshake, an attacker can present a fake Node ID belonging to an allow-listed peer and fetch the private repository directly. The allow-list is not public, so the attacker normally needs to first observe a valid Node ID over the network path, making the two disclosed flaws most dangerous when combined. _Developers hardening allow-list based access controls can follow protocol security writeups like this through daily.dev._ ### What is Radicle replacing its Noise-based networking protocol with to fix its security vulnerabilities? Radicle is replacing its custom Noise-based network protocol with iroh, an open source peer-to-peer networking stack built on open standards, which also adds NAT traversal for better reliability. The change is backwards-incompatible and will require a major version bump, causing a temporary network partition between upgraded and non-upgraded nodes. _Anyone planning a breaking protocol migration can watch how projects like Radicle handle it via daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 22 comments across lobsters (as of 2026-09-28). **TL;DR:** The disclosure is met with strong criticism over how basic wire-protocol mistakes (no post-handshake encryption, no version negotiation) went unnoticed for years, plus frustration at the slow disclosure timeline and lack of a fix despite multiple releases in the interim; a few commenters credit the team for transparency. **Sentiment:** 5% positive · 20% mixed · 75% skeptical **The case for** - Some credit the team for openly publishing a detailed disclosure before a fix was ready, which is seen as more responsible than typical industry behavior. - Interest in the planned move to iroh as a networking stack is noted as a positive technical direction worth following. **The pushback** - Commenters are baffled that a custom wire protocol went years without anyone inspecting actual traffic (e.g. via Wireshark) to catch missing encryption. - Several find it especially damning that session keys were established but never actually used to encrypt traffic. - People question why the vulnerable version remained the one advertised for install despite being unfit for purpose. - Concerns raised that the 90-day disclosure window was used for coordination but not for actually shipping a fix, since releases continued during that period. - The advice to stop using private repositories entirely is seen by some as potentially fatal for trust in the project. - A few say this confirms a prior vague sense that something felt 'off' about the project's engineering quality. **By community** - lobsters (skeptical): Discussion is dominated by disbelief at the basic nature of the flaws and criticism of the slow, seemingly fix-less disclosure process, with only minor credit given for transparency. **Hottest debate:** Whether the team deserves credit for candidly disclosing the flaw versus criticism that disclosure without a timely fix is itself irresponsible. **Open questions** - Why wasn't the vulnerable version pulled or flagged as unfit for use on the project's own homepage? - Why did it take three months to disclose a flaw that seems straightforward to confirm? - Why wasn't the disclosure more widely publicized on the project's social channels? **Highlights** > Holy poop. Reading the article I thought it was a flaw in the encryption or key exchange or something, such that traffic was “encrypted but not really.” Like you could trivially derive the session keys or something but the traffic was protected against casual inspection. Now reading the bug reports it would appear that, no, the session keys established during key exchange are there and just *never used*. The first one is understandable but the second one just blows me away. EDIT: And why is the vulnerable version still available? Why are they still telling you to install and try out the product on the home page? By definition it is not fit for purpose. > — [lorddimwit on lobsters · 2 points](https://lobste.rs/s/ad5vwg/radicle_disclosure_vulnerability#c_qyvbhn) > 90days usually also gives you time to fix… here they say: > Which versions are affected? > > All versions of Radicle that were released to date are vulnerable. Between the time of the initial report and now, there were several releases. So in addition of being really bad, it seems like low priority for them to fix… > — [jstoja on lobsters · 4 points, 1 comments](https://lobste.rs/s/ad5vwg/radicle_disclosure_vulnerability#c_9f8bke) > But…I mean. You write a custom wire protocol and don’t once in 3+ years look at a pcap? It’s just really weird to me. > — [lorddimwit on lobsters · 1 points](https://lobste.rs/s/ad5vwg/radicle_disclosure_vulnerability#c_oltikk) > Wow, this is hella disturbing! Didn't they rewrite the protocol 3 times *from scratch*? And now they: - apparently have *no versioning*?? ("Due to a lack of version negotiation features") - No encryption?? A real bummer! From a high-level architectural view I still believe Radicle would be the best (F)OSS Github alternative (given the focus on source availability which lacks in all alternatives)... I just hope this is gonna end in a "any publicity is good publicity" kind of incident! > — [Melkor333 on lobsters · 1 points, 1 comments](https://lobste.rs/s/ad5vwg/radicle_disclosure_vulnerability#c_fk07vx) **Source threads** - [lobsters](https://lobste.rs/s/ad5vwg/radicle_disclosure_vulnerability) · 61 points · 22 comments ## Similar posts on daily.dev - [Radicle: peer-to-peer collaboration with Git](https://daily.dev/posts/radicle-peer-to-peer-collaboration-with-git-u8vrdyihj) · Lobsters · 0 upvotes · 0 comments - [Radicle: the sovereign forge](https://daily.dev/posts/radicle-the-sovereign-forge-7i5ablujn) · Hacker News · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#git](https://daily.dev/tags/git), [#peer-to-peer](https://daily.dev/tags/peer-to-peer) [View this post on daily.dev](https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Disclosure of Vulnerability in the Network Protocol","url":"https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw"},"datePublished":"2026-09-23T17:06:05.885Z","dateModified":"2026-09-28T14:36:18.469Z","description":"Two critical vulnerabilities were disclosed in the network protocol used by Radicle nodes, affecting all released versions. The first flaw means node-to-node...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/48a0b56d58fd627fe6d2d5a3a49ec9f3?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/48a0b56d58fd627fe6d2d5a3a49ec9f3?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,git,peer-to-peer","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Disclosure of Vulnerability in the Network Protocol"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/disclosure-of-vulnerability-in-the-network-protocol-cxfh3h7rw#faq","mainEntity":[{"@type":"Question","name":"Is Radicle's network traffic between nodes encrypted?","acceptedAnswer":{"@type":"Answer","text":"No, all released versions of Radicle send network traffic between nodes in plain text, unencrypted and unauthenticated at the transport layer. This means anyone who can observe the network path between two nodes can read the data being exchanged, though Git objects and signed references are still cryptographically verified at the storage layer, so content cannot be forged. Teams evaluating peer-to-peer code collaboration tools can track disclosures like this via daily.dev before trusting private data to a protocol."}},{"@type":"Question","name":"How can an attacker fetch a private Radicle repository without being on the network path?","acceptedAnswer":{"@type":"Answer","text":"By exploiting a broken peer authentication handshake, an attacker can present a fake Node ID belonging to an allow-listed peer and fetch the private repository directly. The allow-list is not public, so the attacker normally needs to first observe a valid Node ID over the network path, making the two disclosed flaws most dangerous when combined. Developers hardening allow-list based access controls can follow protocol security writeups like this through daily.dev."}},{"@type":"Question","name":"What is Radicle replacing its Noise-based networking protocol with to fix its security vulnerabilities?","acceptedAnswer":{"@type":"Answer","text":"Radicle is replacing its custom Noise-based network protocol with iroh, an open source peer-to-peer networking stack built on open standards, which also adds NAT traversal for better reliability. The change is backwards-incompatible and will require a major version bump, causing a temporary network partition between upgraded and non-upgraded nodes. Anyone planning a breaking protocol migration can watch how projects like Radicle handle it via daily.dev."}}]} ```