개발자가 IDE 확장 기능을 업데이트한 뒤, 보안팀이 “마켓플레이스에서 내려간 특정 버전이 악성 코드였다”고 통지받는 상황을 생각해 보자. 이때 조직이 내려야 할 결정은 하나가 아니다. 해당 확장을 계속 써도 되는지, 설치만 했던 장비를 재설치해야 하는지, 실행 흔적이 있는 장비를 사고로 처리할지 구분해야 한다.
2026년 10월 Cursor는 Cursor VS Code Extension Marketplace에서 배포된 Anthropic.claude-code 2.1.312와 2.1.313의 macOS·Windows용 패키지가 악성으로 변조됐다고 공지했다. Cursor에 따르면 이 버전은 Anthropic이 개발한 것이 아니며, 호스트와 사용자 정보를 수집하고, 공격자 SSH 키 추가·SSH 서비스 활성화·역방향 SSH 터널 설정·지속성 등록을 시도했다.
이 사건에서 중요한 점은 “공식 제품처럼 보이는 확장 기능”이 문제가 됐다는 사실만이 아니다. 확장 기능은 개발자의 편의 도구가 아니라, 소스 코드·터미널·자격 증명·네트워크에 닿을 수 있는 실행 코드다. 따라서 확장 기능의 출처, 설치 시점, 정확한 버전, 실행 권한, 업데이트 경로를 일반 소프트웨어 자산과 같은 수준으로 관리해야 한다.
실패는 확장 기능이 IDE 권한을 물려받는 데서 시작한다
VS Code 계열 확장 기능은 확장 호스트에서 실행되며, 그 호스트는 IDE와 같은 권한을 가진다. IDE가 읽고 쓸 수 있는 파일에 접근할 수 있고, 네트워크 요청을 보내거나 외부 프로세스를 실행할 수도 있다. 개발자가 로그인한 계정으로 IDE를 실행한다면, 확장 기능도 대체로 그 사용자 권한 범위에서 움직인다.
이 권한 모델은 언어 서버, 코드 검사기, AI 코딩 도구, Git 연동 도구를 작동시키는 기반이기도 하다. 동시에 공급 경로가 침해되면 악성 확장이 개발 환경 내부에서 실행될 수 있다는 뜻이다. 소스 코드가 있는 작업 폴더만 보호해서는 부족한 이유다.
Cursor가 식별한 악성 버전은 사용자 홈 디렉터리의 SSH 설정을 바꾸고 지속성 메커니즘을 설치하려 했다. 악성 코드에 구현 오류가 있어 일반적인 macOS·Windows 환경에서는 SSH 서비스 활성화나 터널 연결이 실패할 수 있었다는 점은 영향 판단에 고려할 사실이다. 그러나 이것이 “실행됐어도 안전하다”는 결론은 아니다. Cursor도 악성 SSH 키 추가, 지속성 등록, 호스트 정보 전송 가능성을 이유로 조사와 자격 증명 교체를 권고했다.
실패 분석의 출발점은 공격 코드가 의도한 최종 결과가 아니라, 이미 성공했을 수 있는 행위를 분리하는 데 있다.
- 확장 패키지를 설치하거나 업데이트했는가
- 해당 버전이 IDE에서 실제로 로드됐는가
- 사용자 SSH 설정, 시작 프로그램, 예약 작업에 변경 흔적이 있는가
- 개발 환경에서 접근 가능했던 소스 코드, 토큰, 세션, 배포 자격 증명이 무엇인가
- 침해된 마켓플레이스가 아닌 승인된 경로에서 동일 기능을 다시 설치할 수 있는가
설치 이력만 발견됐을 때와 실행 흔적이 있을 때는 대응이 다르다
모든 설치 장비를 같은 사고 등급으로 처리하면 조사 범위가 과도해질 수 있다. 반대로 “공격 서버가 꺼졌다”거나 “권한 상승은 실패했을 수 있다”는 이유로 재설치만 하면 지속성 파일과 노출된 자격 증명을 남길 수 있다. CTO와 개발 리드는 다음 네 단계로 대상을 나누는 편이 낫다.
1. 영향 버전 설치 여부를 확인할 수 없는 장비
확장 기능 목록, 로컬 확장 디렉터리, 중앙 소프트웨어 자산 목록, IDE 업데이트 기록 중 어느 곳에도 버전 이력이 남지 않았다면, 먼저 조사 가능성을 복구해야 한다. 이 단계에서 사용 중단을 영구 결정할 근거는 부족할 수 있지만, 해당 확장의 자동 업데이트와 신규 설치는 일시 중지할 이유가 있다.
확장 기능 이름만 수집하는 자산 목록은 이 상황에서 거의 도움이 되지 않는다. 게시자 식별자, 버전, 설치 시각, 설치 원본 마켓플레이스, 패키지 해시 또는 서명 확인 결과까지 남겨야 다음 사건에서 범위를 좁힐 수 있다.
2. 영향 버전이 설치됐지만 실행 흔적이 없는 장비
정확히 영향을 받은 버전이 설치됐으나, 해당 기간에 IDE가 실행되지 않았거나 악성 행위의 흔적을 찾지 못한 경우다. 이 경우에도 확장 제거와 승인된 배포 경로에서의 재설치 여부를 검토해야 한다. 다만 “흔적이 없다”는 판단은 탐지 범위에 따라 달라진다. 사용자 홈 디렉터리의 SSH 설정, macOS LaunchAgent, Windows 예약 작업, 관련 프로세스와 네트워크 기록을 어디까지 확인했는지 함께 남겨야 한다.
재설치는 패키지를 신뢰 가능한 상태로 되돌리는 조치다. 이미 생성됐을 수 있는 독립 실행형 지속성 파일이나 유출된 세션을 되돌리는 조치는 아니다.
3. SSH 키·지속성·의심 프로세스가 확인된 장비
이 단계부터는 확장 기능 문제로만 다루지 않는 편이 안전하다. Cursor는 해당 징후가 있는 호스트를 격리하고, 비인가 SSH 키와 지속성 메커니즘, 실행 중인 터널 프로세스를 제거한 뒤 재구축 필요성을 평가하라고 안내했다. 확장 기능을 삭제해도 별도로 생성된 파일이나 시작 항목이 남을 수 있기 때문이다.
특히 개발자 장비에는 Git 호스팅, 패키지 레지스트리, 클라우드 콘솔, CI/CD, 원격 접속, 비밀 관리 도구의 세션이나 토큰이 있을 수 있다. 영향 장비에서 접근 가능했던 자격 증명과 세션을 신뢰할 수 있는 별도 시스템에서 교체할지 판단해야 한다. 이때 조사팀은 “발견된 토큰”만 보지 말고, 그 장비에서 통상 접근 가능한 계정 범위를 함께 확인해야 한다.
4. 관리자 권한으로 IDE를 실행했거나 고권한 개발 환경인 경우
Cursor는 일반적인 macOS·Windows 환경에서 악성 코드가 SSH 서비스를 켜는 단계는 관리자 권한 부족과 구현 오류 때문에 실패할 수 있다고 설명했다. 그러나 IDE를 관리자 권한으로 실행했거나, 비대화형 관리자 권한이 허용된 환경은 같은 가정을 적용하기 어렵다.
빌드 서버, 공유 개발 VM, 관리자 계정으로 운영되는 자동화 장비도 여기에 포함해 별도 조사 대상으로 잡는 것이 좋다. 위험을 판단하는 기준은 “개발자 PC인가”가 아니라 “확장이 어떤 권한으로 어떤 비밀 정보와 시스템 설정에 닿을 수 있었는가”다.
공식 이름, 검증 배지, Restricted Mode가 대신해 주지 않는 것
마켓플레이스의 게시자 확인, 악성코드 검사, 동적 분석은 중요한 방어 수단이다. 그러나 이 수단들은 특정 패키지가 특정 시점에 안전하다는 절대 보증이 아니다. 이번 사례처럼 유통 경로 안에서 변조된 버전이 배포될 가능성을 조직의 운영 절차에 포함해야 한다.
Workspace Trust도 확장 기능 공급망 침해를 해결하는 경계는 아니다. 이 기능은 신뢰하지 않는 작업 폴더에서 자동 코드 실행을 줄이기 위한 장치다. VS Code 문서 역시 악성 확장이 Restricted Mode를 무시하고 코드를 실행하는 일을 막을 수 없다고 설명한다. 낯선 저장소를 열 때 Restricted Mode를 쓰는 것과, 설치된 확장 기능을 신뢰하는 것은 서로 다른 결정이다.
따라서 “공식 마켓플레이스 등록 여부”는 설치 승인 근거 중 하나일 뿐, 승인 종료 조건이 되어서는 안 된다. 조직은 마켓플레이스와 게시자, 패키지 버전, 설치 경로를 분리해 기록해야 한다.
계속 사용할 확장 기능이라면 업데이트 경로까지 승인한다
Claude Code나 유사한 AI IDE 확장 기능을 전면 금지할지 판단할 때는 제품 범주 전체를 한 덩어리로 보지 않는 편이 낫다. Cursor는 식별된 두 악성 버전 외의 버전이나 공식 배포본이 영향을 받았다는 증거는 없다고 밝혔다. 이 사실은 모든 Claude Code 배포본이 침해됐다고 단정할 근거가 없다는 뜻이다. 동시에 특정 마켓플레이스의 특정 배포 경로를 신뢰 목록에서 분리해야 한다는 뜻이기도 하다.
계속 사용을 허용하려면 보안팀과 개발 플랫폼 팀이 다음 질문에 답할 수 있어야 한다.
- 조직이 허용하는 배포 채널은 무엇인가. 공식 공급자 채널, 특정 마켓플레이스, 내부 패키지 저장소를 구분하고, 채널별 승인 책임자를 정해야 한다.
- 자동 업데이트는 누가 통제하는가. 업데이트를 막자는 뜻이 아니라, 새 버전이 어느 장비에 언제 배포됐는지 추적할 수 있어야 한다는 뜻이다.
- 확장 기능별로 필요한 권한은 어디까지인가. 개발자 로컬 파일, 터미널 실행, 네트워크 통신, 원격 개발 환경 접근을 같은 위험도로 취급하지 말고 업무 필요성과 함께 검토해야 한다.
- 침해 통지가 왔을 때 누가 설치 대상 목록을 뽑는가. 중앙 관리 콘솔, 엔드포인트 관리 도구, IDE 설정 관리 중 어느 기록이 기준인지 미리 정해야 한다.
- 예외 승인은 무엇을 남기는가. 특정 팀이 확장을 계속 써야 한다면 제품명만 적지 말고, 승인 버전·설치 채널·허용 기간·업데이트 방식·사고 시 연락 책임자를 남기는 편이 좋다.
여기서 예외 승인은 보안 검토를 건너뛰는 문서가 아니다. 영향이 확인된 버전을 계속 쓰는 승인과, 검증된 다른 버전을 제한된 경로에서 쓰는 승인을 구분하는 장치다.
다음 사고 전에 만들어 둘 조기 신호
확장 기능 침해는 개발자가 이상한 파일을 발견할 때까지 기다리면 대응이 늦어진다. 조기 신호는 확장 기능의 정상 동작을 세밀하게 추측하는 데서보다, 개발 환경에서 원래 없던 변경을 연결하는 데서 나온다.
우선 확장 기능 설치·업데이트 이벤트와 IDE 실행 기록을 연결할 수 있어야 한다. 여기에 사용자 SSH 설정 파일 변경, 시작 프로그램 또는 예약 작업 생성, IDE 프로세스가 실행한 외부 명령, 예상하지 못한 외부 통신을 함께 조사할 수 있다면 영향 판단 속도가 달라진다.
다만 이 신호만으로 악성 행위를 단정해서는 안 된다. 개발 도구는 파일을 읽고 프로세스를 실행하며 네트워크에 연결하는 일이 많다. 탐지 규칙은 확장 기능 식별자와 버전, 설치 시점, 변경된 경로, 실행 계정처럼 확인 가능한 맥락을 함께 보도록 설계해야 한다.
이번 유형의 사건에서 가장 먼저 정할 일은 “이 확장을 허용할 것인가”가 아니다. 조직이 어떤 확장 기능이 어느 경로에서 어느 버전으로 설치됐는지 오늘 바로 답할 수 있는지 확인하는 일이다. 그 답이 없다면 사용 중단, 재설치, 격리 중 무엇을 선택해도 영향 범위를 설명하기 어렵다.
