출처 불명 깃허브 저장소 '익스플로이타리움', 미보고 취약점 PoC 무더기 공개 논란...7-Zip·도커·VLC 등 SW 15종 익스플로이트 한곳에 모아, 보안업계 "책임공개 원칙 훼손" 우려

[한국정보기술신문] 'bikini'라는 사용자명으로 운영되는 깃허브(GitHub) 저장소 '익스플로이타리움(exploitarium)'이 여러 소프트웨어의 보안 취약점 공격증명코드(PoC)를 한곳에 모아 공개하면서 보안업계에서 논란이 일고 있다. 이 저장소는 스스로를 "공개된 익스플로이트 PoC와 취약점 연구 글을 모은 단일 아카이브"라고 소개하고 있으나, 저장소 설명란에 "이 글들을 올리는 시점에 어느 것도 신고되지 않았다"는 문구를 달아 두면서 미보고 취약점을 조율 없이 공개하는 이른바 '전면 공개(full disclosure)' 성격이 부각됐다.

PoC(Proof of Concept)는 특정 취약점이 실제로 악용될 수 있음을 입증하기 위해 제작한 시연용 코드나 자료를 뜻한다. 보안 연구자들은 취약점의 위험성을 알리고 개발사가 문제를 인정·수정하도록 압박하기 위해 PoC를 만든다. 다만 PoC는 그 자체로 공격에 활용될 소지가 있어, 통상적으로는 개발사에 먼저 알려 수정(패치)이 배포된 뒤에 공개하는 절차를 따른다. 익스플로이타리움이 주목받는 이유는 이 절차를 건너뛰는 듯한 공개 방식을 표방하고 있기 때문이다.

6월 28일 현재 이 저장소에는 15개의 폴더가 정리돼 있다. 대상 소프트웨어는 압축 프로그램 7-Zip, 원격제어 도구 AnyDesk, 컨테이너 플랫폼 도커(Docker), 역공학 분석 도구 기드라(Ghidra), 코드 협업도구 기티(Gitea), 이미지 처리 도구 이미지매직(ImageMagick), SSH 통신 라이브러리 libssh2, 네트워크 스캐너 엔맵(Nmap), 디스어셈블러 objdump, VPN 클라이언트 오픈VPN 커넥트(OpenVPN Connect), 미디어 플레이어 VLC, 게시판 소프트웨어 마이BB(MyBB) 등으로, 상용 소프트웨어와 오픈소스를 가리지 않는다. 개발자와 보안 전문가가 일상적으로 사용하는 도구들이 다수 포함돼 있다는 점에서 잠재적 영향 범위가 적지 않다는 우려가 나온다.

저장소 설명에 따르면 일부 폴더는 운영자가 과거에 별도로 운영하던 PoC 저장소를 통합한 것이며, 일부는 이 저장소에 직접 작성한 항목이다. 운영자는 옛 저장소들의 파일이 통합 과정에서 변형 없이 동일하게 옮겨졌는지를 깃(Git) 객체 식별값을 대조해 점검했다고 밝히고 있다. 다만 저장소가 익명으로 운영되고 있고 다수 항목의 진위가 외부에서 독립적으로 검증되지 않은 만큼, 게시된 내용을 그대로 사실로 단정하기는 어렵다는 지적도 함께 제기된다.

논란의 핵심은 저장소가 내건 공개 방침이다. 운영자는 설명란에서 게시 시점에 해당 취약점들이 신고되지 않은 상태라고 밝히면서, "직접 신고해서 CVE가 부여되면 그 공로를 가져가도 좋다"는 취지의 문구를 농담조로 덧붙였다. CVE(Common Vulnerabilities and Exposures)는 공개된 보안 취약점에 부여하는 국제 식별번호로, 취약점을 처음 발견·신고한 연구자에게 공로가 기록되는 것이 일반적이다.

보안업계에서는 이 같은 방식을 두고 '책임공개(responsible disclosure)' 원칙과 '전면공개(full disclosure)' 입장이 충돌하는 전형적 사례로 본다. 책임공개는 취약점을 개발사에 먼저 비공개로 알리고 수정이 이뤄진 뒤 정보를 공개하는 방식으로, 이용자가 패치를 적용할 시간을 확보할 수 있다는 장점이 있다. 반면 전면공개를 지지하는 일각에서는 개발사가 수정에 미온적일 때 정보를 즉시 전면 공개해야 패치를 압박하고 이용자가 스스로 방어할 수 있다고 주장한다. 양측 입장 모두 보안 생태계 안에서 오래 논의돼 온 사안이다.

그러나 패치가 배포되지 않은 상태에서 동작하는 PoC를 공개하는 것은 결이 다르다는 평가가 우세하다. 익명의 한 보안 연구자는 "수정되지 않은 취약점의 PoC를 공개하면 방어자보다 공격자가 먼저 이를 활용할 가능성이 크다"며 "공익적 동기가 있더라도 결과적으로 공격자에게 무기를 쥐여주는 셈이 될 수 있다"고 우려했다. 미패치 취약점을 무차별적으로 공개하는 행위는 국가·지역에 따라 법적 책임 문제로 이어질 수 있다는 지적도 나온다.

다만 저장소에 담긴 항목이 모두 미보고 취약점인 것은 아니다. 대표적으로 'libssh2-cve-2026-55200-poc' 폴더는 이미 식별번호가 부여되고 수정이 완료된 취약점과 연결돼 있다. CVE-2026-55200은 SSH 통신에 널리 쓰이는 라이브러리 libssh2에서 발견된 심각도 '치명적(Critical)' 등급(CVSS 9.2)의 취약점으로, 인증 절차를 거치지 않고도 원격에서 임의 코드를 실행할 수 있는 사전인증 원격코드실행(pre-auth RCE) 결함으로 분류된다.

이 취약점은 보안 연구자 트리스탄 마다니(Tristan Madani)가 책임공개 절차에 따라 알린 것으로, 6월 17일 공개되며 같은 날 깃허브 권고 데이터베이스에 등재됐고 개발 측에서 수정 커밋이 반영됐다. libssh2는 파일 전송 도구와 자동화 프레임워크, 각종 SSH 클라이언트에 폭넓게 내장돼 있어, 정식 패키지 갱신만으로는 정적 링크된 사본까지 모두 갱신되지 않을 수 있다는 점이 부각된 바 있다. 일부 보안 매체가 관련 PoC의 출처로 익스플로이타리움을 언급하기도 했으나, CVE 자체의 공로는 책임공개를 진행한 마다니에게 기록돼 있다. 결과적으로 이 저장소에는 이미 공개·수정된 CVE의 PoC와, 운영자가 미보고 상태라고 주장하는 항목이 뒤섞여 있는 셈이다.

전문가들은 이번 사안이 특정 저장소의 진위 공방을 넘어, 미패치 취약점 정보가 통제되지 않은 채 공개되는 상황 자체에 경각심을 가질 필요가 있다고 강조한다. 저장소에 거론된 소프트웨어를 사용하는 개인과 기업은 해당 제품의 최신 보안 권고와 패치 적용 여부를 점검하고, 정적 링크나 번들 형태로 포함된 구성요소가 없는지 의존성을 함께 살펴야 한다는 조언이 나온다. 특히 libssh2처럼 다른 소프트웨어에 내장돼 눈에 잘 띄지 않는 구성요소는 별도 점검이 필요하다는 설명이다.

깃허브 측은 이용자 신고에 따라 정책 위반 콘텐츠를 검토·조치하는 절차를 운영하고 있다. 미패치 취약점의 공격용 코드가 정책상 어떻게 다뤄질지는 신고 및 검토 결과에 달려 있어, 향후 이 저장소의 존속 여부에도 영향을 미칠 수 있을 것으로 보인다. 보안업계는 책임 있는 취약점 공개 문화의 정착과 함께, 연구 목적과 악용 우려 사이의 경계를 어떻게 설정할지에 대한 논의가 다시 필요한 시점이라고 입을 모은다.