확장 하나가 나중에 다른 확장을 부른다 — Open VSX를 잠식한 공급망 웜

확장 하나가 나중에 다른 확장을 부른다 — Open VSX를 잠식한 공급망 웜

분류: Security · 소프트웨어 공급망 · 공급망 웜(악성 확장 배포) [정보성]

덱. 보안 업체 Socket이 코드 에디터 확장 마켓플레이스 Open VSX에서 확산 중인 “GlassWorm” 캠페인의 새 변형을 보고했습니다. 이번 변형의 핵심은 처음엔 완전히 무해해 보이는 확장을 올려두고, 나중 업데이트에서 다른 확장을 끌어오게 만드는 방식으로 진화했다는 점입니다. 설치 시점의 심사만으로는 이런 확산을 걸러낼 수 없다는 것을 보여주는 사례입니다.

리드

소프트웨어 유통망(공급망)에서 “이 패키지는 한 번 승인됐으니 계속 안전할 것”이라는 가정은 생각보다 자주 깨집니다. 심사는 대개 게시 시점 한 번 이뤄지고, 그 이후의 업데이트는 같은 강도로 재검토되지 않는 경우가 많습니다. 공격자는 이 틈을 압니다 — 처음엔 아무 문제 없는 도구를 올려 심사를 통과시킨 뒤, 신뢰가 쌓인 다음에야 진짜 페이로드를 붙입니다. 이번 GlassWorm 변형은 이 수법을 코드 에디터 확장이라는, 개발자가 가장 무심코 설치 버튼을 누르는 영역에 적용했습니다.

핵심 사실 요약

• GlassWorm은 Microsoft Visual Studio Marketplace와 Open VSX(비주얼 스튜디오 코드 계열 에디터가 쓰는 오픈소스 확장 마켓플레이스)에 반복적으로 침투해 온 악성코드 캠페인입니다. 감염된 시스템에서 비밀정보(시크릿)를 훔치고, 암호화폐 지갑을 비우고, 감염 기기를 다른 범죄 행위의 우회 경유지(프록시)로 쓰는 것이 목적으로 알려져 있습니다. 최초 포착은 2025년 10월 Koi Security로, 코드 안에 사람 눈에 보이지 않는 유니코드 문자를 숨겨 악성 로직을 감추는 기법이 이 캠페인의 특징으로 지목돼 왔습니다.
• Socket 보고서에 따르면, 2026년 1월 31일 이후 최소 72개의 새로운 악성 Open VSX 확장이 추가로 발견됐습니다. 이 확장들은 린터(코드 스타일 검사 도구)·포매터·코드 실행기, 그리고 AI 코딩 보조 도구용 확장처럼 개발자에게 익숙한 이름과 기능을 흉내 냈습니다. Open VSX 측은 이후 이들을 마켓플레이스에서 제거하는 조치를 취했다고 보고됐습니다. ⚠️미확인 — 제거가 전 목록에 걸쳐 완료됐는지, 이후 유사 계정으로 재게시가 있었는지는 이 초안에서 1차출처로 직접 확증하지 못했습니다.
• 확산 방식의 핵심 변화 — 확장 시스템에는 하나의 확장이 다른 확장들을 묶어서 함께 설치하도록 지정하는 두 가지 필드(extensionPack, extensionDependencies)가 있습니다. 원래는 “이 도구와 함께 쓰면 좋은 관련 확장들을 한 번에 설치해준다”는 편의 기능입니다. 이번 캠페인은 이 필드를 이용해, 게시 당시엔 다른 확장에 의존하지 않는 완전히 독립적인 확장을 먼저 올려 심사를 통과시킨 뒤, 나중 업데이트에서 이 필드에 GlassWorm 계열 악성 확장을 추가하는 방식을 씁니다. 결과적으로 겉보기엔 아무 변화도 없어 보이는 도구가, 어느 날부터 조용히 다른 확장을 함께 끌고 오기 시작합니다.
• 에디터 쪽 구현도 이 수법을 거들었습니다. extensionPack으로 선언됐든 extensionDependencies로 선언됐든, 에디터는 목록에 적힌 확장을 모두 설치합니다. 즉 사용자가 “이 확장 하나”만 설치했다고 생각해도, 실제로는 그 확장이 지정한 다른 확장까지 함께 시스템에 들어옵니다.
• 이번 변형은 기존 GlassWorm의 특징도 그대로 이어갑니다 — 러시아어 로캘(지역/언어 설정) 시스템에서는 감염을 피하도록 검사하는 로직, 명령제어(C2) 서버 주소를 알아내기 위해 솔라나(Solana) 블록체인 거래 내역을 일종의 “숨겨둔 쪽지”처럼 활용하는 방식(탐지·차단에 강한 이유), 그리고 탐지를 피하기 위해 지갑 주소를 계속 바꿔 쓰는 점입니다. 여기에 이번 변형은 난독화(코드를 읽기 어렵게 가공하는 기법) 강도를 더 높였습니다.
• 별개 보안업체 Aikido는 유사한 기법이 오픈소스 코드 저장소(GitHub) 자체를 노리는 데도 쓰이고 있다고 밝혔습니다. 2026년 3월 3일~9일 사이 최소 151개 저장소가, 보이지 않는 유니코드 문자로 인코딩된 악성 코드를 심는 방식의 공격을 받은 것으로 추정됩니다. 연구자 Ilyas Makari는 이 침투 커밋들이 “문서 수정, 버전 올림, 사소한 리팩터링” 등 해당 프로젝트의 평소 커밋 스타일과 자연스럽게 어울려 위장돼 있었다며, 공격자가 대형언어모델(LLM)을 이용해 그럴듯한 “위장용 커밋”을 자동 생성했을 가능성을 제기했습니다. 같은 유니코드 기법이 두 개의 npm(자바스크립트 패키지) 라이브러리에서도 확인돼, 여러 플랫폼에 걸친 조직적 활동으로 보인다고 보고됐습니다. ⚠️미확인 — 이 GitHub 저장소 침투 사례와 Open VSX 확장 캠페인이 동일 공격 그룹인지 정확히 연결되는지는 원문에서도 “동시 발표된 별개 권고(concurrent advisory)“로만 다뤄, 완전히 하나의 캠페인이라 단정하지는 않았습니다.

짧은 논평

이 사례가 잘 보여주는 건 “신뢰는 시점이 아니라 지속적으로 재검증해야 한다”는 원칙입니다. 마켓플레이스 심사가 아무리 꼼꼼해도, 그 심사가 게시 시점 한 번에 그친다면 방어선은 사실 “최초 업로드 시점의 스냅샷”만 지키는 셈입니다. 확장 간 의존 관계처럼 원래는 편의를 위한 기능이 그대로 신뢰 재사용의 통로가 된다는 점도 눈여겨볼 대목입니다 — 사용자는 “확장 A를 설치했다”고 인지하지만, 실제 신뢰 판단은 A가 나중에 지정하는 B, C에까지 자동으로 확장됩니다. 같은 시기 보고된 npm 생태계의 또 다른 사례(Endor Labs가 지목한 이른바 PhantomRaven 계열 패키지들)도 결이 비슷합니다 — 패키지 메타데이터가 코드를 npm 저장소가 아니라 공격자가 통제하는 외부 URL에서 가져오도록 지정해두면, 배포 이후에도 서버 쪽 파일 하나만 바꿔서 이미 설치된 모든 사용자의 동작을 조용히 바꿀 수 있습니다. 두 사례 모두 “설치 순간에 본 것이 이후에도 그대로일 것”이라는 개발자의 암묵적 가정을 정확히 겨냥합니다. 개발 도구 공급망을 지키려면 게시 시점 심사에 더해, 업데이트·의존성 변경마다 재검증하는 지속적 감시와, 확장이 실제로 통신하는 대상(도메인·블록체인 주소 등)에 대한 런타임 모니터링이 함께 필요합니다.

References / 참고자료

1. Ravie Lakshmanan, “GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers”, The Hacker News, 2026-03-14 — 이 글이 재구성한 원 분석(Socket·Aikido·Endor Labs 보고 종합). https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html

이 글은 위 원 분석을 우리 관점에서 다시 쓰고 짧은 논평을 더한 정보성 초안입니다. 특정 문장·패키지명 목록·기술 세부를 그대로 옮기지 않았으며, 작동하는 재현 절차는 싣지 않았습니다. ⚠️미확인 표시 항목은 발행 전 독립 팩트체크에서 확증·정정되어야 합니다.