보이지 않는 코드가 실행된다 — GlassWorm이 깨뜨린 「리뷰하면 막을 수 있다」는 전제

안녕하세요, 주식회사 TIMEWELL의 하마모토 류타입니다.

화면에 아무것도 표시되지 않는 문자에, 실행되는 코드가 들어 있다.

이렇게 쓰면 마술처럼 들리지만, 실제로 일어났습니다. GlassWorm이라는 공격으로, 개발자가 쓰는 에디터의 확장 기능을 거쳐 퍼졌습니다.

이 공격이 까다로운 것은 피해의 크기보다 전제를 깨뜨렸다는 점입니다. 우리는 소프트웨어의 안전을 「사람이 코드를 읽고 승인한다」는 구조로 지켜 왔습니다. 읽을 수 없는 것은, 승인도 부인도 할 수 없습니다.

무슨 일이 있었나

사실부터 잡습니다. 2025년 10월 18일, Koi Security가 탐지해 공개했습니다¹.

침해된 것은 VS Code 확장 기능입니다. 배포처인 OpenVSX 등 마켓플레이스에, 악성 코드가 심긴 확장 기능이 올라왔습니다. 확인된 침해 확장 기능은 16건, 총 다운로드 수는 35,800건으로 되어 있습니다¹.

확장 기능이 하는 일은 대체로 다음과 같습니다¹.

• npm, GitHub, OpenVSX, Git 인증 정보를 훔친다
• 49종의 암호화폐 지갑 확장 기능을 대상으로 정보를 가져간다
• 개발자 기기에 SOCKS 프록시를 세워, 공격 측 통신의 중계점으로 만든다
• VNC 서버를 숨겨 설치하고, 원격 조작이 가능한 상태로 만든다

그리고 가장 무거운 것이, 훔친 인증 정보로 또 다른 패키지나 확장 기능을 오염시킨다는 점입니다¹. 개발자 한 명이 감염되면, 그 사람이 공개 권한을 가진 자산이 다음 감염원이 됩니다. 자기 증식합니다. VS Code 확장 기능에서는 처음으로 확인된 행동으로 되어 있습니다².

왜 사람의 눈에 안 보이는가

기술의 핵심은 여기입니다. 천천히 쓰겠습니다.

쓰이는 것은 변형 선택자(Variation Selector)라는 Unicode 문자입니다. 범위는 U+FE00부터 U+FE0F(16문자)와 U+E0100부터 U+E01EF(240문자). GlassWorm이 주로 쓴 것은 후자로, 256가지 값을 표현할 수 있어 0부터 255까지의 바이트 값에 그대로 대응합니다³.

변형 선택자는 같은 문자의 모양 차이를 지정하기 위한 문자입니다. 일본어 한자처럼, 같은 글자에 여러 자형이 있을 때 「이쪽 형태로 표시하라」고 지정하는 용도로 쓰입니다. 즉, 그 자체는 아무것도 그리지 않습니다. 직전 문자의 표시 방법을 바꾸는 지시일 뿐, 표시될 내용을 갖고 있지 않습니다.

그래서 에디터에서 보면 아무것도 없는 줄로 보입니다. GitHub의 diff 표시도 같습니다. 줄이 비어 보일 뿐, 거기에 수백 문자가 들어 있어도 알 수 없습니다³.

실행되는 구조는 이렇습니다³.

1. 각 문자의 코드 포인트에서 계산으로 바이트 값을 꺼낸다
2. 꺼낸 바이트를 늘어놓아 Base64 문자열을 조립한다
3. 디코드하면 JavaScript 소스 코드가 된다
4. 그것을 eval로 실행한다

즉 비가시 문자 자체는 데이터이고, 그것을 조립해 돌리는 짧은 코드가 따로 있습니다. 공격자 입장에서는 본체를 「보이지 않는 데이터」로 빼돌리고, 눈에 보이는 부분은 무해하게 보이게 할 수 있는 구조입니다.

어디서 밟게 되는가

구체적인 상황을 듭니다. 어느 것도 특별한 일을 하는 장면이 아닙니다.

장면 1. 확장 기능을 설치할 때.

에디터의 확장 기능을 찾아, 다운로드 수가 많은 것을 고른다. 이것이 가장 직접적인 경로입니다. GlassWorm에서 피해가 가장 컸던 확장 기능은 설치 수가 3만 5,000건을 넘었습니다¹. 인기 있다는 것은 안전하다는 뜻이 아닙니다. 오히려 인기 있는 것일수록, 탈취당했을 때의 피해가 큽니다.

게다가 이번에는 원래 정상이던 확장 기능이 나중에 오염된 형태입니다. 설치 시점에는 문제가 없어도, 자동 업데이트로 들어옵니다. 「넣을 때 확인했다」로는 막히지 않습니다.

장면 2. 풀 리퀘스트를 리뷰할 때.

동료가 낸 PR을 열고, diff를 눈으로 따라간다. 빈 줄이 한 줄 늘어난 것처럼 보인다. 신경 쓰지 않고 승인한다. 이것으로 통과합니다.

여기가 가장 무서운 지점입니다. 리뷰어의 주의력 문제가 아닙니다. 보이지 않는 것은, 아무리 주의 깊게 봐도 보이지 않습니다. 숙련자일수록 「diff가 작으니 안전하다」고 판단하기 쉬워, 오히려 반대로 작동하기도 합니다.

장면 3. 의존 패키지가 갱신될 때.

npm 패키지를 갱신한다. 락 파일의 diff를 확인한다. 내용까지는 읽지 않는다. 애초에 수만 줄을 매번 읽을 수 있는 사람은 없습니다. 업스트림이 오염되어 있으면, 그대로 자사 빌드에 들어옵니다.

장면 4. AI에게 코드를 쓰게 하거나, 읽게 할 때.

이것은 새로운 경로입니다. AI 코딩 에이전트에게 리포지토리를 읽혀 작업을 시킨다. 에이전트는 파일을 텍스트로 읽습니다. 비가시 문자는 텍스트로서는 그냥 존재합니다. 사람에게는 보이지 않고, AI의 출력에도 나타나지 않습니다. 그대로 다음 파일로 복사되기도 합니다.

개발 도구 자체가 감염 경로가 되는 구조는, AI 도구가 감염 경로가 되는 시대에서 TanStack 사례를 다뤘습니다. AI가 존재하지 않는 패키지 이름을 제안해 버리는 문제는 Slopsquatting에 있습니다.

지울 수 없는 지휘 계통이라는 새로움

처리가 어려운 요소가 하나 더 있습니다. C2(지휘 서버)를 어디에 두느냐입니다.

GlassWorm은 명령을 받는 입구를 삼중으로 만들어 두었습니다¹.

주 계통은 Solana 블록체인 트랜잭션 메모입니다. 블록체인에 쓰인 정보는 성질상 나중에 지울 수 없습니다. 신고해도 멈출 수 없는 지휘 계통입니다. 종래의 대책인 「악성 도메인을 테이크다운한다」「IP를 차단한다」가 통하지 않습니다.

부 계통으로 공격자 서버에 대한 직접 접속이 있고, 예비로 구글 캘린더 이벤트 이름에 인코딩한 명령을 두는 경로도 준비되어 있었습니다¹. 예비가 여기까지 갖춰져 있다는 것은, 운용으로서 진심이라는 뜻입니다.

이 구조를 보면, 「배포처를 멈춘다」만으로는 끝나지 않는다는 것을 알 수 있습니다. 이미 기기에 들어간 것은, 명령을 계속 가져옵니다.

육안 리뷰를 그만둔다는 대책

그렇다면 무엇을 하는가. 방침은 명확합니다. 사람의 눈에 의존하는 검사를, 기계의 검사로 바꾼다.

첫째. 로컬에서 검사한 뒤에 PR을 낸다.

Node.js 환경이라면, 다음 명령으로 비가시 문자를 검사할 수 있습니다⁴.

npx anti-trojan-source src/index.js

이것을 커밋 전의 습관으로 만든다. 로컬에서 떨어지면, 리뷰어의 시간을 쓰지 않습니다.

둘째. CI에서 기계적으로 떨어뜨린다.

더 확실한 것은 여기입니다. GitHub Actions라면, 다음과 같은 단계를 끼웁니다⁴.

- name: Scan for invisible Unicode attacks
  run: npx anti-trojan-source --files='**/*.{js,ts,jsx,tsx}' --json

탐지되면 빌드를 실패시킨다. 사람의 승인보다 먼저, 기계가 멈춘다. 다루는 언어가 늘면 확장자를 더합니다. ESLint 플러그인으로 기존 검사에 넣는 형태도 있습니다⁴.

여기서 중요한 것은, 「조심하자」를 대책으로 두지 않는 것입니다. 이번 공격은 주의력으로는 막을 수 없게 설계되어 있습니다. 주의력으로 막지 못하는 것은, 구조로 막을 수밖에 없습니다.

셋째. 인증 정보를 교체하고, 줄인다.

GlassWorm의 증식은, 훔친 인증 정보가 연료입니다. npm, GitHub, OpenVSX 토큰을 정기적으로 교체한다. 그리고 쓰지 않는 토큰을 개발 머신에서 지운다⁴. 개인 개발 머신에 몇 년 전 토큰이 남아 있는 일은, 상당히 흔한 이야기입니다. 한 번 훑어 정리하는 것만으로도, 증식의 연료는 줄어듭니다.

넷째. 확장 기능을 자산으로 관리한다.

각자 마음대로 넣고 있는 상태를 멈추고, 조직으로서 무엇이 들어가 있는지를 파악한다. 도입 때의 심사만으로는 부족합니다. 업데이트로 나중에 오염되는 경로가 있으므로, 계속해서 봐야 합니다. 「넣을 때 확인했다」는, 이번 같은 사후 오염에는 통하지 않습니다.

AI에게 읽히는 시대에 이 구멍은 어떻게 작동하는가

마지막으로, 조금 앞의 이야기를 합니다.

사람이 읽지 않는 코드의 비율은, 앞으로 분명히 늘어납니다. AI가 쓰고, AI가 읽고, AI가 리뷰한다. 그때 「사람 눈에 보이지 않는 문자」는 누구의 점검에도 걸리지 않는 영역이 됩니다.

AI는 텍스트로서 비가시 문자를 다룰 수 있지만, 그것을 이상으로 보고한다는 보장은 없습니다. 「이 줄에는 변형 선택자가 240자 늘어서 있습니다」라고 말해 줄 보장은 없습니다. 문자로서는 타당한 Unicode이므로, 깨진 데이터조차 아니기 때문입니다.

그래서 이 검사는 자동화 파이프라인에 두어야 하는 것입니다. 사람의 리뷰에도, AI의 리뷰에도 기대지 않고, 결정적인 규칙으로 걸러 낸다. 바이트열을 보고, 예상 밖의 문자가 들어 있으면 멈춘다. 그것뿐입니다.

솔직히, 이 공격에서 제가 가장 걸린 것은 기술적인 고도함이 아니라 착안점입니다. Unicode의 변형 선택자는, 다언어 문자를 올바르게 표시하기 위해 존재하는 사양입니다. 선의의 호환성을 위해 마련된 여백이, 그대로 은닉 장소가 되었습니다. 새로운 취약점을 찾아낸 것이 아니라, 기존 사양의 쓰임새를 비튼 것뿐입니다.

그리고 이것은 처음이 아닙니다.

2021년, 케임브리지 대학교의 Nicholas Boucher와 Ross Anderson이 「Trojan Source」를 공개했습니다. 이쪽은 Unicode의 양방향 텍스트 제어 문자를 악용하는 것으로, 아랍어나 히브리어처럼 오른쪽에서 왼쪽으로 쓰는 언어를 올바르게 표시하기 위한 사양을 사용합니다. 토큰의 나열 순서를 표시상에서만 바꿔, 사람이 읽는 코드와 컴파일러가 해석하는 코드를 다른 것으로 만들 수 있다는 공격이었습니다⁵.

영향 범위는 넓어, C, C++, C#, JavaScript, Java, Rust, Go, Python 같은 주요 언어의 컴파일러가 대상이 되었습니다. CVE-2021-42574와 CVE-2021-42694가 할당되어 있습니다⁵.

앞에서 소개한 검사 도구의 이름이 anti-trojan-source인 것은, 이 공격에 대항하기 위해 만들어졌기 때문입니다. 5년 전 대책 도구가, 이번 공격에도 그대로 먹힙니다. 수법은 달라도, 「표시와 실체가 어긋난다」는 구멍의 모양이 같기 때문입니다.

이 형태의 공격은, 아마 또 다른 사양에서도 일어납니다. 변형 선택자, 양방향 제어, 제로폭 문자, 개별 사용 영역. Unicode에는 「표시되지 않지만 유효한 문자」가 여러 개 있고, 그 전부가 후보입니다. 그래서 대책도 일반화해 두어야 하고, 「우리가 읽고 있는 것과, 기계가 실행하고 있는 것이 같다」는 것을, 어딘가에서 기계적으로 확인한다. 이것이 본질이라고 생각합니다.

사내 보안 교육이나 개발 체계를 다시 보는 일에 대해서는, WARP의 관점이 참고가 될 수 있습니다. 구체적인 상황을 상담하고 싶으시면 여기로 연락 주십시오.

---

Footnotes

1. Koi Security의 GlassWorm 탐지 보고서(2025년 10월 18일 탐지, 당일 공개). VS Code 확장 기능을 대상으로 하며, 침해 확장 기능은 해당 보고서의 IOC 섹션에서 16건(OpenVSX 15건, VS Code 1건)이 열거되고, 총 다운로드 수는 35,800건으로 되어 있다. 탈취 대상은 npm 인증 토큰, GitHub 인증 정보, OpenVSX 인증 정보, Git 인증 정보, 그리고 49종의 암호화폐 지갑 확장 기능. 감염된 기기에 SOCKS 프록시 및 숨겨진 VNC 서버를 설치한다. 지휘 계통은 Solana 블록체인 트랜잭션 메모에 Base64로 인코딩한 페이로드 URL을 심는 방식을 주 계통으로 하고, 공격자 서버에 대한 직접 접속, 그리고 구글 캘린더 이벤트 제목에 인코딩하는 방식을 예비로 가진다. 훔친 인증 정보로 또 다른 패키지 및 확장 기능을 침해하는 자기 증식의 순환을 가진다. https://www.koi.ai/blog/glassworm-first-self-propagating-worm-using-invisible-code-hits-openvsx-marketplace ／ 본 기사에서는 구체적인 지갑 주소, IP 주소, URL 등의 IOC는 악용 가능성을 피하기 위해 기재하지 않는다. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. GlassWorm은 VS Code 확장 기능을 대상으로 하는 자기 증식형 웜으로서 처음으로 확인된 것으로 되어 있다. https://www.veracode.com/blog/glassworm-vs-code-extension/ ／ https://www.bleepingcomputer.com/news/security/self-spreading-glassworm-malware-hits-openvsx-vs-code-registries/ ↩

3. 사용된 비가시 문자는 변형 선택자(Variation Selector)이며, 범위는 VS1부터 VS16이 U+FE00부터 U+FE0F(16문자), VS17부터 VS256이 U+E0100부터 U+E01EF(240문자). GlassWorm의 구현에서는 후자가 주로 사용되어, 0부터 255의 바이트 값에 대응하는 256가지 값을 지원했다. 변형 선택자는 동일 문자의 다른 시각적 표현을 선택하는 기능을 가지므로 그 자체는 그려지지 않고, 대부분의 텍스트 에디터에서 시각적으로 나타나지 않는다. 실행은 코드 포인트에서 바이트 값을 복원하고, Base64 문자열로 재구성한 뒤 디코드하여 JavaScript 소스 코드를 생성한 다음 eval()을 거쳐 이루어진다. https://www.endorlabs.com/reports/invisible-threats-glassworm-unicode-vscode ↩ ↩² ↩³

4. 대책의 구체적인 내용. 육안 코드 리뷰에만 의존하지 않을 것, npx anti-trojan-source src/index.js에 의한 풀 리퀘스트 송신 전의 로컬 검사, GitHub Actions에서의 npx anti-trojan-source --files='**/*.{js,ts,jsx,tsx}' --json에 의한 머지 전 자동 검사와 탐지 시 차단, ESLint 플러그인으로 기존 워크플로에 넣는 선택지, npm·GitHub·OpenVSX 토큰의 정기적 교체와 불필요한 인증 정보 삭제, 그리고 서드파티 컴포넌트의 지속적인 신뢰성 확인은 모두 해당 기사에 따른다. https://snyk.io/articles/defending-against-glassworm/ ↩ ↩² ↩³ ↩⁴

5. Trojan Source. 2021년에 케임브리지 대학교의 Nicholas Boucher 및 Ross Anderson이 공개한 공격 수법으로, Unicode의 양방향 텍스트 제어 문자를 악용해 소스 코드의 표시상 모습과 실제 실행 내용을 다른 것으로 만든다. 공격자는 Unicode 제어 문자로 인코딩 층에서 토큰의 나열 순서를 바꿀 수 있어, 컴파일러와 사람 리뷰어가 다른 논리를 보는 상태를 만들어 낼 수 있다. C, C++, C#, JavaScript, Java, Rust, Go, Python 등 주요 언어의 컴파일러가 영향을 받았고, CVE-2021-42574 및 CVE-2021-42694가 할당되어 있다. https://access.redhat.com/security/vulnerabilities/RHSB-2021-007 ／ https://thehackernews.com/2021/11/new-trojan-source-technique-lets.html ／ https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/ ↩ ↩²