Radicle 네트워크 프로토콜 취약점 공개

AI 요약

Git 기반 P2P 코드 협업 도구 Radicle의 개발팀이 노드 네트워크 프로토콜에서 발견한 치명적인 취약점 두 건을 공개했습니다. 공개된 모든 버전이 영향을 받으며, 개발팀은 수정 버전이 나오기 전까지 비공개 저장소를 네트워크로 공유하지 말라고 권고했습니다. 이번 수정은 통신 규약과 호환되지 않아 메이저 버전 업데이트가 필요합니다.

취약점 두 건

첫 번째 문제는 노드 간 통신 내용이 평문으로 전송된다는 점입니다. 두 노드 사이 네트워크 경로를 관찰하는 공격자는 오가는 데이터를 읽을 수 있습니다. 저장소 객체는 Signed References로 검증하므로 공격자가 전송 중 객체를 바꾸더라도 변경 사실은 감지합니다. 따라서 코드 변조보다 정보 노출이 주된 우려이며, 특히 비공개 저장소가 위험합니다. 이 취약점은 Konstantinos Maninakis가 2026년 6월 24일 신고했습니다.

두 번째 문제는 연결 과정의 피어 인증이 깨져 있다는 점입니다. 공격자는 자신의 Node ID가 아닌 다른 ID를 제시할 수 있습니다. 비공개 저장소는 허용 목록에 든 Node ID에만 공유되지만, 공격자가 목록에 든 ID를 위조하면 네트워크 경로에 있지 않아도 저장소를 가져갈 수 있습니다. 다만 허용 목록은 공개되지 않으므로, 경로 밖의 공격자는 유효한 ID를 먼저 알아내야 합니다. cryptocode가 이 문제를 2026년 8월 12일 신고했습니다.

두 취약점은 함께 악용될 때 위험이 커집니다. 통신 경로에 있는 공격자는 연결 양쪽의 Node ID를 알아내고, 전송 중인 데이터를 읽은 뒤 관찰한 ID를 이용해 저장소 전체를 요청할 수 있습니다. 개발팀은 비공개 저장소가 과거 네트워크로 전송된 적이 있다면 이미 노출된 것으로 간주하라고 안내했습니다. 저장소에 암호화되지 않은 비밀번호, 키, 토큰이 있었다면 교체해야 합니다.

사용자가 취할 조치

비공개 저장소를 네트워크로 시드하지 않도록 설정하려면 먼저 rad ls --private --all로 목록을 확인한 뒤 각 저장소에 rad block <RID>를 실행합니다. rad block은 명시적으로 공유를 차단하므로 노드의 기본 정책이 허용인 경우에도 적용됩니다. 기본 정책이 차단이라면 rad unseed로도 충분하지만, 허용 정책을 설정했다면 unseed 뒤에도 저장소를 계속 제공할 수 있습니다. 노드를 완전히 멈추려면 rad node stop을 실행합니다.

이 조치는 로컬 저장소를 삭제하지 않으며, 이미 가져간 다른 피어의 복사본에도 영향을 주지 않습니다. 저장소를 디스크에서 직접 지우면 보유한 포크까지 삭제될 수 있으므로, 삭제 경로를 정확히 이해하지 못한다면 보관하라고 개발팀은 안내했습니다. Tor, I2P, VPN 같은 별도 암호화 전송도 충분한 대책은 아닙니다. 네트워크 경로의 관찰을 어렵게 만들더라도 피어 사칭 문제까지 막지는 못하기 때문입니다.

수정 계획과 영향 범위

두 문제는 저장소 데이터 모델이 아니라 노드 전송 계층에 있습니다. Git 객체와 Signed References의 검증은 기존처럼 작동하며, 공격자가 코드를 위조하거나 정체성을 변조할 수 있는 취약점은 아니라고 개발팀은 밝혔습니다. 다만 통신 계층의 기밀성과 피어 인증은 보호되지 않습니다.

현재 Radicle은 Noise를 사용하는 자체 프로토콜을 쓰고 있습니다. 개발팀은 이를 표준 기반 오픈소스 P2P 네트워킹 스택인 iroh로 교체하는 작업을 진행하고 있습니다. iroh는 이번 문제를 해결하는 동시에 NAT traversal도 제공해 연결의 안정성과 복원력을 높일 예정입니다. 프로토콜을 바꾸면 구버전 노드와 신버전 노드가 서로 통신하지 못해 네트워크가 두 집단으로 나뉩니다. 버전 협상 기능이 없고 변경 사항이 유선 프로토콜과 호환되지 않아, 이전 버전과 호환되는 완화책은 어렵다고 개발팀은 설명했습니다. 저장소 형식은 유지해 업그레이드 과정의 변경 범위를 네트워크 쪽에 집중할 계획입니다.

Lobsters 반응

• @freddyb — 악의는 없지만, 프로토콜을 만들면서 실수로 암호화를 전혀 하지 않을 수 있나요? 실제 네트워크 패킷을 확인하지 않나요? 테스트용으로 다른 클라이언트를 구현해 프로토콜을 검증하지 않나요?
  • @gecko — 그런 반응은 충분히 이해합니다. 예전에 Radicle을 살펴봤고, 이론상으로는 마음에 들었습니다. 하지만 업계에서 오래 일하다 보면 프로젝트에서 뭔가 어긋난다는 느낌이 들 때가 있습니다. 정확히 설명하긴 어렵지만, 그 느낌 때문에 사용을 멈췄습니다. 이번 일로 그때 느낌이 맞았다는 생각이 들고, 다시 쓰지 않을 것 같습니다.
  • @retr0id — 흥미롭네요. 저도 예전에 아주 피상적으로 봤을 때는 인상이 좋았는데, 그래서 이번 소식이 더 놀랍습니다.
  • @lorddimwit — 글을 읽을 때는 암호화나 키 교환에 결함이 있어 트래픽이 사실상 보호되지 않는 문제인 줄 알았습니다. 세션 키를 쉽게 계산할 수 있는 식으로요. 그런데 버그 보고서를 보니 키 교환으로 세션 키를 만들고도 그 키를 전혀 쓰지 않았던 것 같습니다. 첫 번째 문제도 이해하기 어렵지만 두 번째는 정말 놀랍습니다. 취약한 버전을 왜 아직 배포하나요? 홈페이지에서 제품을 설치하고 시험해 보라고 안내하는 이유도 모르겠습니다. 용도에 맞게 쓸 수 있는 상태가 아니라고 봅니다.
  • @yorgos — 홈페이지에서 수정 전까지 비공개 저장소를 언급하는 부분은 분명히 고쳐야 합니다. 용도에 맞지 않는 상태라는 말에도 동의합니다. 다만 공개 저장소도 고려해 주세요. 제 생각에는 Radicle 같은 P2P 구조가 자유·오픈소스 소프트웨어(FLOSS)를 호스팅하기에 자연스럽습니다. 실제 사용도 공개 저장소가 주를 이뤘고, 개발팀은 그 사용 사례에 가장 집중해 왔습니다. 공개 저장소에 영향을 주는 취약점은 파악하지 못했습니다.
  • @pyfisch — Konstantinos Maninakis가 2026년 6월 24일 신고했다고 합니다. 근본적인 결함을 알고도 공개까지 3개월이 걸린 이유가 뭔가요?
  • @lorddimwit — 90일은 흔한 공개 유예 기간입니다. 조사와 확인을 하고 주요 사용자에게 비공개로 알릴 시간을 주는 취지입니다. 다만 이번 경우에는 확인에 오래 걸렸을 것 같지 않습니다.
  • @jstoja — 90일은 보통 수정에도 쓰는 시간입니다. 모든 Radicle 버전이 영향을 받는다고 하면서 신고 이후에도 여러 버전을 출시했습니다. 문제가 심각한 데다 수정 우선순위도 낮았던 것처럼 보입니다.
  • @lattera — 기존 통신 프로토콜을 깨뜨리는 수정이라 쉽지 않습니다. 최근 몇 달 사이 Radicle 네트워크가 꽤 커졌고, 모든 구성 요소와 사용자들이 맞물려 움직이도록 조정해야 합니다. 개발 초기 단계에서 간단히 tcpdump로 확인했다면 발견했을 문제라고 생각합니다. 사람은 실수합니다. 저도 Radicle 통신이 암호화된다는 문서를 순진하게 믿었습니다. 저 역시 tcpdump를 실행해 뻔한 문제를 확인할 수 있었습니다. iroh로 옮길 때 암호화 통신을 검증하는 시험을 진행하길 바랍니다. 다만 공개문에서 밝혔듯 이 이전은 통신을 깨뜨리는 변경입니다. Radicle 사용자 전체가 비슷한 시기에 옮겨야 할 텐데, 정확한 계획은 모르겠습니다.
  • @lorddimwit — 네, 무책임했다고 생각합니다.
  • @kitkat — 직접 와이어 프로토콜을 만들 때마다 언젠가는 Wireshark로 패킷을 살펴봤습니다.
• @flockofbirbs — Noise를 쓰는 자체 프로토콜에서 어떻게 노드 간 트래픽이 암호화되지 않을 수 있는지 궁금했습니다. 답은 간단했습니다. 초기 핸드셰이크 뒤에 아무것도 암호화하지 않았습니다.
  • @wofo — Noise 처리를 의존성에 맡기고 제대로 작동한다고 믿었던 것 같습니다. 그런데 그렇지 않았습니다.
  • @tclancy — 물량으로 밀어붙이면 됩니다.
• @veqq — 수정이 나올 때까지 비공개 저장소 사용을 중단하라고 권고하네요. 프로젝트가 회복하기 어려울 것 같습니다.
  • @nullenvk — 소프트웨어에 근본적인 보안 문제가 있고 가까운 시일 내에 고칠 수도 없다고 인정하는 건 취약점 공개에서 최악에 가까운 결과일 겁니다.
  • @retr0id — 그래도 공개적으로 인정한 점은 어느 정도 좋게 볼 수 있습니다.
  • @atmosx — 동의합니다. 책임 있는 자리에 있는 사람들이 책임을 거의 지지 않는 세상에서, 수정본을 내기 전에 성명을 발표한 점은 적어도 긍정적입니다. 흔한 일은 아닙니다.
• @quad — 재분산화 프로젝트에서 iroh가 자꾸 보입니다. Delta Chat과 Radicle이 그렇습니다. Tailscale, libp2p, IPFS, cjdns, Yggdrasil, wormhole 계열과 프로토콜이 어떻게 다른지 배워야 할 것 같네요.
• @Melkor333 — 정말 충격적입니다. 프로토콜을 처음부터 세 번이나 다시 썼다고 들었는데, 이제는 버전 협상도 없고 암호화도 없다고 합니다. 높은 수준의 구조만 보면 Radicle이 가장 나은 FLOSS GitHub 대안이라고 여전히 생각합니다. 소스 가용성을 중시하는 점은 다른 대안에 없다고 봅니다. 이번 일이 결국 좋은 홍보가 되는 사건으로 끝나길 바랍니다.
  • @mdaniel — FLOSS 라이선스를 쓰는 포지(forge)가 적어도 세 개 더 있는데, 소스 가용성을 이유로 그렇게 말하는 건 매우 이상합니다.
  • @JadedBlueEyes — 여기서 말하는 가용성은 중복성과 복원력, 즉 CIA 보안 3요소에서 말하는 가용성에 가까운 것 같습니다.
• @hunger — 이 소식을 소셜 미디어에도 올렸나요? Mastodon에서는 못 본 것 같습니다. 웹사이트에 연결된 Zulip에서 이메일을 보내서 알게 됐습니다. Zulip 사용자가 웹사이트에 공지된 소셜 계정보다 많을 것 같지는 않습니다.
• @z3t0 — 이 도구의 가치와 심각한 보안 결함을 함께 인정해야 한다고 생각합니다. 사람은 실수하지만, 기존 서비스형 소프트웨어보다 더 안전한 대안으로 보이는 도구에서 이런 실수는 용납하기 어렵습니다. 그래도 투명하게 대응하는 현재 방식은 다시 신뢰를 얻을 기회를 줄 만하다고 봅니다. 비슷한 비용의 취약점이 독점 서비스에도 있을 수 있지만, 그런 서비스는 보안 문제를 알리지 않는 경우가 많고 공개 감사를 위해 코드도 열지 않습니다. 복잡한 문제를 토론으로 풀고 싶어서 제 생각을 적었으며, 논쟁으로 만들지 않으려고 답글은 삼가겠습니다.

원문: Radicle / 번역·요약: Trawling