커서 마켓플레이스에 올라온 클로드 코드 확장 변조본
커서에서 클로드 코드 확장을 쓰고 있다면 10월 29일 밤부터 30일 새벽 사이에 확장이 업데이트됐는지부터 봐야 합니다. 커서는 자사 VS Code 확장 마켓플레이스에 Anthropic.claude-code 2.1.312와 2.1.313 변조본이 올라와 있었다고 공지했습니다. 대상은 Windows와 macOS용 패키지이고, 커서가 밝힌 영향 규모는 최대 5,000명입니다.
배포 시간은 미국 태평양 시간 10월 29일 오전 2시 27분부터 오후 1시 35분까지입니다. 한국 시간으로 바꾸면 10월 29일 오후 6시 27분부터 다음 날 오전 5시 35분까지, 약 11시간입니다. 저녁에 커서를 켜 둔 채 자리를 비웠거나 밤새 에이전트 작업을 돌렸다면 자동 업데이트로 이 버전을 받았을 수 있는 시간대입니다.
이 변조본은 앤트로픽이 만든 것이 아닙니다. 커서는 cursor.com/marketplace에서 받은 다른 확장에는 영향이 없다고 밝혔고, 마켓플레이스를 통째로 내렸다가 접근 기록을 점검하고 키를 교체한 뒤 다시 열었습니다. 마이크로소프트도 같은 패키지가 Visual Studio Marketplace와 npm 배포본에는 올라간 적이 없고, 앤트로픽 시스템이 침해되지 않았다는 답을 앤트로픽에게서 받았다고 적었습니다. 마이크로소프트 VS Code에서 공식 마켓플레이스로 확장을 받았거나 터미널용 클로드 코드만 썼다면 이번 사고 범위 밖입니다.
커서는 공지와 함께 모든 사용자에게 Claude Code for VS Code 2.1.314로 업데이트하라고 안내했습니다. 문제는 업데이트가 확장 파일만 새로 바꾼다는 점입니다. 변조본이 실행되면서 확장 폴더 밖에 남긴 흔적은 그대로 남기 때문에, 아래 순서대로 한 번 더 살펴봐야 합니다.
We identified a security incident affecting a modified Claude Code VS Code extension accessed through our Cursor IDE extension marketplace, impacting at most 5,000 users. This malicious version of the extension was not developed by Anthropic. It does not impact other extensions downloaded from the https://t.co/sJRGX5jLXW, Grok Bot, Grok or our other SpaceXSI products. In response, we took down our extension marketplace this afternoon, worked with relevant providers to neutralize the malware, and have reinstated the marketplace after confirming there is no further risk. If affected, please review instructions in this blog post to understand how to find the malicious package and establish a path to mitigate any potential impact. We are asking all customers update to Claude Code for VS Code version 2.1.314: https://t.co/ESqf7YEtHZ
— Cursor (@cursor_ai) 2026년 10월 30일
확장이 켜지는 순간 실행된 코드와 가져간 정보
변조본은 정상 확장 코드 맨 앞에 짧은 자바스크립트를 끼워 넣은 형태였습니다. 확장이 불러와지는 순간 이 코드가 먼저 돌고, 그 뒤 클로드 코드 확장은 평소처럼 동작합니다. 사용자는 화면에서 이상한 점을 거의 느낄 수 없었습니다. 마이크로소프트 분석을 보면 이 코드는 명령 출력과 오류를 모두 숨겨 실패해도 티가 나지 않게 짜여 있었습니다.
처음 하는 일은 PC 정보 수집입니다. 컴퓨터 이름, 사용자 이름, 운영체제와 CPU 종류, 홈 폴더와 작업 폴더 경로, Git에 설정한 이메일, 공인 IP를 모읍니다. 환경 변수도 훑는데, 이름에 KEY, TOKEN, SECRET, PASS, AWS, GCP 같은 단어가 들어간 항목을 최대 40개까지 골라냅니다. 마이크로소프트는 이때 밖으로 보낸 것이 변수의 값이 아니라 이름이라고 설명합니다. 값이 빠졌더라도 그 PC에 어떤 종류의 비밀 값이 있는지 알려 주는 정보라 가볍게 넘길 일은 아닙니다.
그다음은 원격 접속 준비입니다. 공격자의 SSH 공개 키를 사용자 계정의 authorized_keys 파일에 추가하고, PC의 SSH 서버를 켠 뒤, 공격자 서버 쪽으로 역방향 SSH 터널을 엽니다. 바깥에서 내 PC로 바로 들어오는 대신 내 PC가 먼저 밖으로 연결을 만들고, 공격자는 그 연결을 타고 거꾸로 들어오는 구조입니다. 터널이 끊기면 약 60초마다 다시 연결을 시도합니다.
커서는 이 마지막 단계가 대부분의 PC에서 실패했다고 봅니다. SSH 서버를 켜려면 관리자 권한이 필요한데, 커서를 관리자 권한으로 실행한 드문 경우가 아니면 악성 코드에 그 권한이 없었고 코드 자체에도 오류가 있었다는 설명입니다. 공격자 서버도 호스팅 업체와 협력해 내려간 상태입니다.
그래도 안심하고 넘어가면 안 되는 이유가 있습니다. 공격자 키 추가와 자동 실행 등록, PC 정보 전송은 관리자 권한 없이도 이뤄졌을 수 있습니다. 서버가 내려갔다고 이미 PC에 생긴 파일까지 사라지지는 않습니다.
svc-telemetry 키로 내 PC 영향 여부 확인하는 방법
살펴봐야 하는 경우는 세 조건이 겹칠 때입니다. macOS나 Windows에서, 커서 확장 마켓플레이스를 통해, 위 시간대에 클로드 코드 확장을 새로 설치했거나 2.1.312, 2.1.313으로 업데이트했다면 대상입니다. 자동 업데이트도 포함됩니다. 언제 업데이트됐는지 기억나지 않는다면 아래 명령을 한 번 실행해 보는 편이 빠릅니다.
변조본은 공격자 공개 키를 추가할 때 svc-telemetry라는 이름표를 붙였습니다. 그래서 authorized_keys 파일에서 이 문자열을 찾으면 영향 여부를 알 수 있습니다. macOS는 터미널에서, Windows는 PowerShell에서 커서 공지에 나온 명령을 그대로 실행합니다. Windows 명령은 사용자 폴더의 .ssh 아래 파일과 C:\ProgramData\ssh 아래 관리자용 키 파일을 함께 봅니다.
결과가 No key found로 나오면 커서 기준으로 영향을 받지 않은 PC입니다. svc-telemetry key found가 나오면 영향을 받은 것이므로 다음 장의 순서로 넘어갑니다. 두 명령 모두 파일을 읽기만 하고 아무것도 바꾸지 않으니 회사 PC에서도 부담 없이 돌려 볼 수 있습니다. 회사에 보안 담당자가 있다면 결과 화면을 지우지 말고 그대로 전달하는 것이 좋습니다.
# macOS 터미널
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"
# Windows PowerShell
$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }근거 [1]
키가 나왔다면 확장 삭제보다 먼저 할 일
영향을 받은 PC에서 확장만 지우는 것으로는 부족합니다. 변조본은 확장 폴더 밖에 별도 스크립트와 자동 실행 항목을 만들어 두었기 때문에, 확장을 지우거나 2.1.314로 올려도 그 스크립트는 계속 남아 터널 연결을 시도할 수 있습니다. 커서와 마이크로소프트 모두 이 점을 따로 짚었습니다.
자동 실행 항목은 정상 시스템 구성 요소처럼 보이는 이름을 썼습니다. macOS에는 ~/Library/LaunchAgents/com.apple.sysmond.plist라는 LaunchAgent와 ~/.config 아래 .smt, .smtk 파일이 생깁니다. Windows에서는 SysMon이라는 예약 작업을 SYSTEM 권한으로 만들려고 시도하고, 그게 막히면 시작프로그램 폴더에 sysmon.cmd를 넣습니다. 사용자 폴더의 .config 아래 smt.cmd와 smtk 파일도 함께 생기고, 임시 폴더에는 .stk_로 시작하는 파일이 남습니다.
커서는 운영체제별 복구 스크립트를 공지에 올려 두었습니다. macOS는 remediate-macos.sh를 내려받아 root가 아니라 영향을 받은 사용자 계정으로 bash remediate-macos.sh를 실행합니다. Windows는 remediate-windows.ps1을 내려받은 뒤 관리자 권한으로 연 PowerShell에서 실행합니다. 두 스크립트는 악성 확장과 자동 실행 항목, 실행 중인 터널 프로세스, 공격자 SSH 키를 지우고, 하나라도 남으면 오류 상태로 끝납니다.
스크립트를 돌린 뒤에도 할 일이 남습니다. 커서는 그 PC에서 접근할 수 있었던 인증 정보와 세션을 다른 깨끗한 기기에서 교체하라고 권합니다. GitHub 토큰, 클라우드 키, AI 서비스 API 키처럼 환경 변수나 설정 파일에 들어 있던 값이 대상입니다. 수집된 것이 변수 이름뿐이었어도 백도어를 통해 나중에 값에 접근했을 가능성까지 배제할 수는 없다는 이유입니다.
회사 PC라면 순서가 조금 다릅니다. 마이크로소프트는 정리하기 전에 확장 패키지와 바뀐 키 파일, 생성된 스크립트를 증거로 먼저 보존하고, 실행 흔적이 있는 기기는 네트워크에서 격리하라고 권합니다. 이름만 보고 지우지 말고 각 자동 실행 항목이 실제로 무엇을 실행하는지 확인한 뒤 지우라는 당부도 붙어 있습니다. 조사 결과에 따라 기기를 새로 설치해야 할 수도 있습니다.
키가 없을 때 할 일과 2.1.314 업데이트
키가 나오지 않았다면 커서 왼쪽의 확장 패널에서 클로드 코드 확장을 열고 버전이 2.1.314 이후인지 보면 됩니다. 변조본은 이미 마켓플레이스에서 내려갔기 때문에 지금 새로 받는 버전이 같은 문제를 가진 것은 아닙니다. 개인 사용자라면 여기까지로 충분합니다.
여러 대를 관리하는 팀은 조금 더 봐야 합니다. 마이크로소프트는 키가 없다는 사실 하나로 설치 기록과 프로세스, 네트워크 기록 검토를 대신하지 말라고 적었습니다. 공격자 서버 주소 134.209.82[.]225로 나간 연결이 있었는지, 앞에서 말한 파일 이름이 생겼는지 보안 장비 기록에서 찾아보는 것이 다음 단계입니다. 마이크로소프트 Defender를 쓰는 조직을 위한 검색 쿼리도 분석 글에 함께 실려 있습니다.
이번 사고에서 Linux는 커서 공지의 영향 대상에 들어 있지 않습니다. 커서가 공개한 변조 패키지 해시도 macOS용 darwin-arm64와 Windows용 win32-x64 두 종류입니다. 다만 마이크로소프트 분석에는 Linux에서 crontab @reboot 항목을 만드는 코드도 들어 있었다고 나옵니다. Linux 환경을 함께 쓰고 있다면 ~/.config/.smt 파일과 crontab 목록을 한 번 살펴보는 정도는 해 둘 만합니다.
확장 설치 대기 시간으로 다음 사고 줄이기
이번 변조본이 마켓플레이스에 머문 시간은 약 11시간이었습니다. 새 버전이 올라오자마자 받지 않고 하루만 기다렸다가 설치했다면 피할 수 있었던 사고이기도 합니다. 커서 도움말에는 바로 이 목적의 설정이 있습니다.
커서는 서드파티 확장을 Open VSX 레지스트리에서 가져오되, 자체 프록시인 marketplace.cursorapi.com을 거치며 악성 코드와 공급망 분석을 한 뒤 보여 준다고 설명합니다. 같은 publisher.extension 이름이라도 Open VSX와 마이크로소프트 마켓플레이스에서 다른 게시자나 다른 코드를 가리킬 수 있다는 주의도 함께 적혀 있습니다. 확장 ID를 패키지 의존성처럼 다루고 믿을 수 있는 게시자 것만 설치하라는 권고입니다.
팀 관리자는 팀 설정의 Security & automation 메뉴에서 Marketplace Install Cooldown 값을 시간 단위로 정할 수 있습니다. 기본값은 0이라 꺼져 있고, 0보다 크게 두면 마켓플레이스에 공개된 지 그 시간이 지난 버전만 설치와 업데이트가 됩니다. 팀이 값을 강제하지 않았다면 개인 사용자도 자기 설정에서 extensions.installCooldownHours를 지정할 수 있습니다. 24로 두면 공개된 지 하루가 지난 버전만 받는 식입니다.
엔터프라이즈 팀이라면 허용한 게시자나 확장 ID만 설치되게 막는 Allowed Extensions와, Open VSX 서명이 유효한 확장만 받게 하는 설정도 켤 수 있습니다. 마이크로소프트도 분석 글 끝에서 승인된 게시자로 확장을 제한하고 설치 대기 시간을 두라고 권했습니다.
코딩 에이전트 확장은 저장소와 터미널, 클라우드 키 바로 옆에서 동작합니다. 그만큼 확장 하나가 변조됐을 때 닿는 범위가 넓습니다. 자동 업데이트를 하루 늦춰도 일에 큰 지장이 없다면 지금 설정해 둘 만한 항목입니다.
