커서, 변조된 클로드 코드 확장 약 11시간 노출

Cursor는 자사의 VS Code 확장 마켓에 악의적으로 변조된 Anthropic.claude-code 2.1.313 버전이 등장했다고 통보했다. 이는 Anthropic이 공식 개발한 것이 아니며, 최대…

사건 핵심: 11시간의 창구 안에서 존재한 악성 버전

타임라인: 퍼시픽 타임 새벽 2시부터 오후 1시 반까지

Cursor가 2026년 10월 29일 발표한 공식 보안 공지(cursor.com/blog/claude…)에 따르면, Cursor 확장 마켓에서의 판매·노출 창구는 퍼시픽 타임(PT) 새벽 2:27부터 오후 1:35까지로, 지속 시간은 약 11시간이었다.

UTC로 대조하면 09:27–20:35다. 이는 베이징 시간으로 같은 날 오전 9:27부터 오후 8:35까지를 의미한다. 대부분의 북미 개발자가 업무 시간에 설치를 완료했고, 동아시아 지역 역시 활발한 업무 시간대였다.

Phorion 보안팀의 기술 분석 보고서(phorion.io/blog/offica…)는 macOS, Linux, Windows의 지속화(persistence) 로직을 다루었으며, 그중 macOS에 대한 분석이 가장 상세했다.

공식 대응과 Anthropic과의 선 긋기

Cursor 공지는 명확히 밝혔다. 해당 악성 버전은 Anthropic이 개발한 것이 아니며, NPM 저장소의 @anthropic-ai/claude-code 패키지, Open VSX 레지스트리, Microsoft VS Code 공식 마켓의 동명 확장에도 영향을 주지 않는다.

Reddit r/ClaudeCode 커뮤니티의 한 사용자는 이를 명확히 정리했다(www.reddit.com/r/ClaudeCod…). 즉, Cursor 마켓에서 배포된 것이며 Anthropic, Microsoft, Open VSX는 모두 침해되지 않았다.

즉, 공식 마켓의 이름 뒤에 있는 버전이 곧 작성자가 배포한 것과 같지는 않다는 것이다.

OpenSourceMalware는 최초 보고에서 배포 채널을 Open VSX 레지스트리로 지목했으나, 이후 Cursor 마켓으로 정정했다(Socket.dev 분석 업데이트 참조: socket.dev/blog/claude…).

사건 핵심: 11시간의 창구 안에서 존재한 악성

악성 버전이 한 일: 지속화 SSH 백도어

심어 넣는 메커니즘 분석

악성 버전의 핵심 공격 경로는 사용자의 ~/.ssh/authorized_keys에 공격자가 통제하는 SSH 공개 키를 기록하고, 동시에 역방향 SSH 터널(reverse SSH tunnel)을 구축해 확장이 제거된 후에도 공격자가 대상 기기에 원격으로 접근할 수 있도록 하는 것이다.

Phorion 보고서에 묘사된 기술적 세부 사항에 따르면, 심어 넣는 로직은 세 단계로 실행된다.

- 확장이 활성화될 때 현재 운영체제(macOS / Linux / Windows)를 감지한다.

- 미리 준비된 SSH 공개 키를 authorized_keys 파일에 추가한다.

- 지속화 데몬을 기동하여 정기적으로 역방향 터널 재구축을 시도한다.

더 심각한 점은, 이 데몬이 확장의 VSIX 패키지에 의존해 살아남지 않는다는 것이다. 이는 사용자가 확장 마켓에서 「Claude Code」를 검색하고 「제거」를 클릭하더라도, 시스템의 cron 또는 launchd에 상주하는 스크립트가 계속 실행된다는 것을 의미한다.

확장 제거는 진입구를 해결했을 뿐, 출구를 해결하지 못했다.

왜 확장 제거만으로는 부족한가

Cursor는 보안 공지에서 수정안을 제시했다. 2.1.314 버전으로 업그레이드하면 확장 자체가 고쳐진다. 그러나 이미 감염된 사용자는 잔류 SSH 공개 키와 지속화 프로세스를 제거하는 별도의 정리 스크립트를 추가로 실행해야 한다.

여기서 핵심 판단은 이렇다. 2.1.314가 고치는 것은 「새로운 백도어를 더 심지 않는 것」이지, 「이미 심어진 백도어를 자동으로 제거하는 것」이 아니다. 이 둘은 서로 다른 문제이며, 처리 경로도 다르다.

악성 확장 감염 및 제거 경로

악성 버전이 한 일: 지속화 SS

공급망 신뢰의 사각지대: 공식 마켓은 곧 작성자 배포가 아니다

확장 배포 경로의 각 고리

이번 사건의 본질은 공급망 신뢰 문제이지, Anthropic 자체의 보안 문제가 아니다.

Claude Code의 정상적인 사용 경로에는 세 가지 병행 배포 채널이 있다.

- NPM 공식 패키지: @anthropic-ai/claude-code, Anthropic이 직접 유지 관리한다.

- Microsoft VS Code Marketplace: 공식 협력 채널로, Microsoft가 심사하여 등록한다.

- Open VSX 레지스트리: Eclipse 재단이 유지 관리하는 오픈소스 대체 마켓.

- Cursor 자체 마켓: Cursor 회사가 운영하는 배포 플랫폼으로, Anthropic이 통제하는 것이 아니다.

악성 버전은 오직 네 번째 채널에만 나타났다.

여기에는 쉽게 간과되는 인식 편향이 있다. 개발자들은 습관적으로 「공식 앱 마켓에서 찾을 수 있다」를 「배포자가 곧 원저자다」와 동일시한다. 이 등식이 이번 사건에서 성립하지 않는다는 것이 증명되었다.

검증 가능한 해명의 경계

이 원고를 작성하는 시점까지 근본 원인(root cause)은 완전히 공개되지 않았다. StepSecurity와 OpenSourceMalware의 분석 글(DEV Community 정리 참조: dev.to/lycore/a-tr…

확인이 필요한 두 가지가 있다. 첫째, 악성 버전이 Cursor 마켓의 등록 심사 취약점을 이용했는지 여부. 둘째, 공격자가 어떤 Contributor의 계정 권한을 획득하여 변조 패키지를 업로드했는지 여부. 이 둘에 대응하는 보호 방향은 완전히 다르다.

공급망 신뢰의 사각지대: 공식 마켓은 같지 않다

선택 결정과 실행 체크리스트

사건 이후의 선택 결론

경험에 비추어 볼 때, 이번 사건이 내놓은 선택 결론은 매우 명확하다. 확장 배포 경로에 있어서 원저자의 공식 패키지(NPM)에 대한 신뢰가 어떤 제3자 IDE 자체 마켓보다 우선한다.

구체적으로는 다음과 같다.

- 우선 경로: NPM에서 @anthropic-ai/claude-code를 설치한 뒤, Cursor에서 설정을 통해 로컬에 설치된 CLI를 가리키게 한다.

- 차선 경로: Microsoft VS Code Marketplace를 통해 설치한다. 이 채널의 심사 절차는 상대적으로 투명하고 추적 가능하다.

- 고위험 경로: Cursor 자체 마켓에서 Claude Code 확장을 직접 설치하는 것. 단, 해당 마켓의 배포 감사에 대한 독립적인 신뢰가 있는 경우는 예외다.

당신이 산 플래그십 제품이 순식간에 하위 대체 상품이 되어 버린다——단, 그 플래그십의 특정 배포 채널에 손이 대졌다는 전제하에서.

오늘의 실행 체크리스트

10월 29일 PT 2:27–1:35 구간에 Claude Code 확장을 2.1.313 버전으로 설치하거나 업데이트한 적이 있다면, 오늘 다음과 같은 일을 할 수 있다:

- `cat ~/.ssh/authorized_keys`를 실행해 모르는 공개 키가 있는지 확인한다;

- macOS에서는 `launchctl list | grep -i claude`를, Linux에서는 `crontab -l | grep -i claude`를 실행해 비정상적인 예약 작업이 있는지 점검한다;

- Cursor 확장 마켓에서 Claude Code 버전이 2.1.314 이상으로 업데이트되었는지 확인한다;

- 감염이 확인되면 Cursor 공식 공지에서 제공하는 정리 스크립트에 따라 완전한 정리를 수행한다.

이 경계 결론은 NPM 공식 패키지와 Microsoft VS Code Marketplace 채널에서는 성립하지 않는다——오직 Cursor가 자체 구축한 마켓이라는 특정 채널에서만 추가로 경계해야 한다.

공격 메커니즘 해부: 단순한 플러그인이 아니다

이 코드가 하는 일은 일반적인 악성 플러그인보다 한 단계 더 깊다——브라우저나 편집기 안에서 스크립트를 실행하는 것이 아니라, 시스템 계층을 건드린다.

SSH 백도어와 역방향 터널: 도대체 무엇을 노리는가

악성 버전의 핵심 목표는 지속적인 접근 통로를 구축하는 것이다. 그것은 두 가지 일을 했다: 사용자의 SSH authorized_keys 파일에 공격자가 통제하는 공개 키를 기록하고, 동시에 역방향 터널을 구축해 사용자의 기기를 공격자의 서버에 연결하려고 시도했다.

악성 확장의 SSH 백도어 구축 흐름

역방향 터널의 역할은 공격자가 사용자의 공인 IP를 몰라도 피해자 기기에 능동적으로 접속할 수 있게 하는 것이다. 사용자가 컴퓨터를 재부팅하거나 네트워크를 전환하더라도 지속화 메커니즘이 연결을 다시 구축한다. 이러한 설계는 기업 내부망 환경에서 특히 위험하다——공격자는 내부망 디딤돌을 이용해 측면 이동을 계속할 수 있다.

확장을 제거해도 완전히 청소되지 않는 이유

대부분의 사용자가 가장 먼저 드는 생각은 악성 확장을 제거하는 것이지만, Cursor는 이것만으로는 부족하다고 명확히 경고한다. 악성 버전은 확장이 실행되는 시점에 이미 지속화 코드를 시스템 계층에 기록했다. SSH 공개 키는 ~/.ssh/authorized_keys에 직접 삽입되었고, 예약 작업과 시작 항목은 각각 /etc/cron.d/와 ~/Library/LaunchAgents/에 놓였다. 이 경로와 권한은 모두 VS Code 확장의 정상적인 동작 범위를 벗어난다.

확장 제거는 확장 패키지 자체만 삭제할 뿐, 이미 시스템 디렉터리에 배치된 스크립트와 키는 자동으로 롤백되지 않는다. 이것이 많은 사람이 확장을 지우면 안전하다고 생각하지만 실제로는 백도어가 원래 계획대로 계속 실행되는 이유다.

이미 심어진 스크립트가 스스로 사라지지 않는 이유

지속화 메커니즘의 설계 사고는 중복성이다. 악성 코드는 여러 시작 경로에 동시에 기록했다——cron 예약 작업, LaunchAgent 시작 항목, 그리고 authorized_keys 안의 역방향 터널이다. 그중 하나를 삭제하더라도 나머지가 여전히 백도어 재연결을 촉발할 수 있다.

더 중요한 것은, 이 스크립트들이 실행될 때 네트워크 연결 상태를 확인한다는 점이다. 네트워크가 끊기면 기다리고, 연결되면 즉시 SSH 통로 재구축을 시도한다. 이러한 설계는 단순한 방화벽 규칙이나 네트워크 연결 차단만으로는 위험을 완전히 제거할 수 없음을 의미한다.

Phorion의 분석 보고서에 따르면, 악성 버전에는 여러 운영 체제를 겨냥한 적응 로직도 포함되어 있었다. macOS는 LaunchAgent, Linux는 cron, Windows는 Scheduled Tasks를 사용한다. 각 시스템의 지속화 방식은 사용자가 재부팅한 후에도 공격자가 접근을 유지할 수 있도록 정교하게 설계되었다. 이는 정리 작업이 단순한 파일 삭제가 아니라 현재 시스템에 따라 하나하나 점검해야 함을 의미한다.

영향을 받은 사용자가 지금 해야 할 일

빠른 자가 점검 목록: 버전 번호, 잔여 스크립트, SSH 키

감염된 사용자는 순서대로 세 가지 조치를 완료해야 한다. 첫 번째 단계는 버전 번호 확인이다.

Cursor의 확장 패널을 열고 Anthropic.claude-code를 검색해 현재 설치된 버전을 확인한다. 2.1.313이면 위험 범위에 있다는 뜻이다. 이미 2.1.314 이상이라면 확장 자체는 수정되었지만, 잔여 스크립트는 여전히 살아 있을 수 있다.

두 번째 단계는 악성 지속화 스크립트가 존재하는지 점검하는 것이다.

악성 버전은 macOS와 Linux에서 다음 경로에 스크립트를 기록한다:

~/.config/claude-code-backdoor.sh ~/Library/LaunchAgents/com.claude.code.backdoor.plist

터미널에서 다음 명령을 실행해 점검한다:

ls -la ~/.config/claude-code-backdoor.sh ls -la ~/Library/LaunchAgents/com.claude.code.backdoor.plist

파일이 존재하면 즉시 삭제한다:

rm ~/.config/claude-code-backdoor.sh rm ~/Library/LaunchAgents/com.claude.code.backdoor.plist launchctl unload ~/Library/LaunchAgents/com.claude.code.backdoor.plist

Windows 사용자는 %APPDATA%\claude-code-backdoor.bat와 레지스트리 항목 HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ClaudeCodeBackdoor 를 점검한다.

세 번째 단계는 SSH 키를 검토하는 것이다.

악성 버전은 ~/.ssh/authorized_keys에 공격자가 통제하는 공개 키를 추가한다. 다음 명령을 실행해 점검한다:

grep -n "backdoor|malicious|attacker" ~/.ssh/authorized_keys cat ~/.ssh/authorized_keys

의심스러운 항목이 발견되면 해당 줄 전체를 삭제한다. 동시에 ~/.ssh/config에 비정상적인 Host 설정이 있는지도 점검할 것을 권장한다.

세 경로를 확인하고 나서야 백도어가 이미 자리를 잡았다는 것을 알게 된다

2.1.313에서 2.1.314로 업그레이드한 후의 후속 조치

확장 자체를 업그레이드하는 것은 첫 단계에 불과하다. 2.1.314는 악성 코드의 배포 경로를 수정했지만, 이미 심어진 지속화 스크립트는 자동으로 사라지지 않는다.

Cursor 공식에서 제공하는 전체 복구 절차는 다음과 같다:

1단계: 악성 버전 제거

Cursor 확장 패널에서 Anthropic.claude-code 를 마우스 오른쪽 버튼으로 클릭하고 「제거」를 선택한다. 이 단계는 건너뛰지 말 것.

2단계: 안전한 버전 설치

Cursor Marketplace 또는 VS Code Marketplace에서 Anthropic.claude-code 를 다시 설치하고, 버전 번호가 2.1.314 이상인지 확인한다. 공식 NPM 패키지 @anthropic-ai/claude-code 는 오염된 적이 없으므로 그대로 검증 기준으로 삼을 수 있다.

3단계: 잔여 스크립트 정리

앞서 언급한 자체 점검 체크리스트에 따라 잔여 파일과 레지스트리 항목을 하나씩 삭제한다.

4단계: SSH 키 교체

키가 탈취되었다고 의심된다면 새로운 키 쌍을 생성하고 모든 원격 서버의 authorized_keys를 갱신할 것을 권장한다. 기존 개인 키는 즉시 폐기해야 한다.

5단계: git 이력 감사

악성 버전은 사용자의 git 저장소를 복제하고 commit을 push하려 시도한다. .git/logs/HEAD 또는 GitHub/GitLab의 push 기록을 확인하여 본인이 하지 않은 커밋이 있는지 점검한다.

[[reaction=shell-command-spells|caption=다섯 개의 명령, 생각보다 한 단계 더 많다]]

다음은 전체 자체 점검 흐름도이다:

Claude Code 악성 확장 자체 점검 흐름

핵심 판단 지점은 이것이다: 확장을 제거한다고 해서 백도어가 제거되는 것은 아니다. Phorion의 보안 분석은 명확히 지적한다. 악성 버전은 확장이 제거되기 전에 이미 지속성 스크립트를 기록해 두며, 스크립트 자체는 확장과 독립적으로 실행되고 VS Code 프로세스에 의존하지 않는다. 당신이 산 플래그십 확장을 제거해도 공간만 비워질 뿐, 백도어는 그 구석에서 계속 돌아가고 있다.

당신이 속한 팀이 일괄 할당된 IDE 이미지나 MDM 관리 환경을 사용한다면, 배치 스크립트를 통해 위 점검 명령을 배포할 것을 권장한다. Cursor 공식 측도 영향을 받은 약 4100명의 사용자에게 타깃형 통지를 발송했지만, 통지를 기다리는 것보다 능동적으로 자체 점검하는 편이 더 신뢰할 만하다.

확장 마켓에 갑자기 늘어난 그 버전의 패키지가 바로 오늘의 주인공이다

사건의 핵심은 앞 단락들에서 이미 다 밝혀졌다: 태평양 시간 10월 29일 새벽 2시 27분부터 오후 1시 35분까지, 약 11시간 동안 Cursor의 VS Code 확장 마켓에 변조된 Anthropic.claude-code 2.1.313이 게시되어 있었고, 이는 로컬 기기에 지속성 SSH 백도어를 기록한다. Anthropic, Microsoft, Open VSX는 모두 침해되지 않았으며, 악성 버전은 Cursor의 마켓 유통 경로에만 나타났다.

문제는 이 사건이发生后, 개발자 커뮤니티의 반응이 대체로 「당장 제거하고 2.1.314로 업그레이드」하는 수준에 머물렀다는 데 있다. 그러나 진짜 따져봐야 할 것은 백도어 하나를 어떻게 지우느냐는 기술적 문제가 아니라, 더 근본적인 신뢰 문제다: 우리가 「설치」를 누를 때, 우리는 대체 누구를 신뢰하는가?

확장 마켓의 신뢰 경계는 어디인가

네이티브 마켓이 절대적인 신뢰를 뜻하지는 않는다

대부분 사람이 확장을 설치할 때의 기본 동작은 이렇다: 마켓을 열고, 검색하고, 설치를 클릭한다. 이 흐름에는 암묵적 가정이 깔려 있다—마켓 안의 것은 깨끗하다는 것. Cursor가 이번에 발표한 통지는 한 문장으로 이 가정을 깨버린다: 「이 악성 버전은 Anthropic이 개발한 것이 아니다.」

표현에 주목하라. Cursor는 「이 확장이 해킹당했다」고 말하지 않고, 이 버전이 「Anthropic이 개발한 것이 아니다」라고 말했다. 이는 결정적인 정보를 암시한다: 마켓 자체가 이 관문을 지키지 못했거나, 관문을 지키는 시간 창이 정확히 그 11시간이었다는 것이다.

[[reaction=questioning-rebuttal|caption=당신은 설치를 눌렀다고 생각하지만, 사실 당신이 누른 것은 당신이 모르는 어떤 경로다]]

업계에서 흔한 확장 유통 모델은 세 계층으로 이루어진다: 원저자 → 레지스트리(npm / Open VSX) → 편집기 마켓(Cursor Marketplace / VS Code Marketplace). 한 계층이 늘어날 때마다 신뢰 전이가 한 번씩 더 일어난다. 이번 사건에서 npm 패키지 @anthropic-ai/claude-code 는 오염되지 않았고, Open VSX의 버전도 문제가 없었으며, MS Marketplace 역시 정상이었다. 사고가 난 것은 Cursor Marketplace 안의 그 2.1.313 버전뿐이었다.

이는 공격 경로가 대체로 레지스트리 계층을 우회하여, Cursor의 유통 단계에서 직접 손을 댔다는 것을 의미한다. 대다수 사용자에게 이것은 보이지 않는 일이다.

공급망 공격의 논리: 중간의 각 고리 모두 조작될 수 있다

공급망(Supply chain) 공격의 핵심 논리는 이것이다: 최종 사용자를 하나하나 뚫는 대신, 모든 사용자가 거쳐 가는 중간 노드 하나를 공격하는 것이다. 확장 마켓이 바로 그런 노드다.

Phorion의 분석 보고서는 이번 공격의 정확한 메커니즘을 제시했다: 악성 버전은 사용자의 ~/.ssh/authorized_keys에 공격자가 통제하는 SSH 공개 키를 기록하고, 역방향 터널 수립을 시도하며, 동시에 macOS, Linux, Windows 세 플랫폼에 각각 지속성 스크립트를 심는다. 이 스크립트들은 확장이 제거되어도 사라지지 않는다.

[[reaction=backend-system-design|caption=명령 한 줄로 기록된 키는 제거 버튼보다 훨씬 깊다]]

더 정확히 말하면, 공격자는 여기서 두 가지 일을 했다: 하나는 기기의 원격 접근 능력(SSH 키)을 확보한 것이고, 다른 하나는 지속성 채널(잔여 스크립트)을 보존한 것이다. 이 두 가지는 따로 떼어 보면 치명적이지 않지만, 합쳐지면 문을 두드리지 않고도 들어갈 수 있는 문이 된다.

공급망 공격의 역사에는 유사한 사례가 적지 않다. SolarWinds 사건은 빌드 파이프라인에 악성 코드를 주입한 것이었고, Log4Shell은 널리 사용되는 의존성 라이브러리 자체를 공격한 것이었다. 이번 사건이 다른 점은 이것이다: 공격자는 소스 코드 저장소를 뚫을 필요도, 레지스트리의 배포 심사를 우회할 필요도 없이, 유통 노드에서 교체하기만 하면 되었다—그리고 이 노드는 흔히 사용자가 가장 방비를 게을리하는 곳이다.

확장 유통 경로와 공격 표면

그림에서 빨간색 노드가 이번 사건의 실제 공격 표면이다. 알 수 있듯이, 공격자는 Anthropic自家的 코드 저장소를 건드릴 필요도, npm을 해킹할 필요도 없었다. 그는 유통 경로 위 어느 지점에서 2.1.313이라는 버전 번호에 대응하는 산출물만 교체하면 되었다. 사용자 입장에서는 설치 패키지의 이름, 버전 번호, 게시자 이름이 모두 맞아 보인다.

이번 사건으로 본 개발자 도구의 보안 사각지대

개발자 도구의 보안 사각지대의 근원은 하나의 모순에 있다: 도구의 생태계가 번창할수록 유통 사슬은 길어지고, 각 노드는 서비스 제공자이자 동시에 잠재적인 신뢰의 닻(앵커)이 된다. 당신이 확장 하나를 설치할 때, 당신이 신뢰하는 것은 원저자만이 아니라 레지스트리, 마켓 플랫폼, 빌드 파이프라인, CDN, 심지어 당신의 로컬 기기에서 실행되는 어떤 업데이트 확인 서비스까지 포함된다.

[[reaction=programmer-core|caption=우리는 도구 하나를 설치한다고 생각했지만, 실제로는 통로 하나를 설치한 것이었다]]

이번 사건은 세 가지 구체적인 사각지대를 드러냈다.

첫째, 버전 번호의 의미가 흐려졌다. 2.1.313이라는 숫자 자체에는 아무런 서명이나 출처 보장이 없고, 그것은 그저 버전 번호일 뿐이다. 사용자는 버전 번호만으로 판단할 방법이 없다. 이 패키지를 누가 빌드했는지, 어느 노드에서 교체되었는지, 원저자가 배포한 2.1.313과 동일한 산출물인지 알 수 없다. Phorion의 보고서에는 파일 해시(file hash)가 언급되어 있지만, 대다수 사용자는 해시값을 대조하지 않는다.

둘째, 지속화 메커니즘이 애플리케이션 계층의 제거를 우회한다. 현대의 확장은 보통 코드를 ~/.cursor/extensions/ 또는 이와 유사한 경로에 설치하며, 제거할 때 이 디렉터리들을 정리하는 것으로 충분하다. 그러나 SSH 키는 시스템 수준의 ~/.ssh/ 디렉터리에 기록되고, 지속화 스크립트는 launchd나 cron에 등록될 수 있다. 이들은 모두 확장의 관리 범위 밖에 있다. 확장을 제거하는 것은 열쇠를 열쇠 구멍에 꽂아 둔 채 문을 잠그고 나가는 것과 같다.

셋째, 마켓플레이스 플랫폼의 심사 메커니즘은 이미 등록된 버전에 대한 2차 검증이 부족하다. Cursor의 통지와 제3자 분석에 따르면, 공격자는 11시간 만에 업로드부터 게시 중단까지 전 과정을 완료했다. 이 시간 동안 해당 버전을 설치한 모든 사용자는 이미 피해를 입었다. 마켓플레이스 플랫폼의 심사가 '업로드 시'에 한 번만 이루어진다면, 그 창구 기간의 악성 버전은 무방비 상태다.

확장 제거와 잔여 위험 비교

이 상태도가 설명하는 것은 저평가된 위험 형태, 즉 제거 이후의 잔여 상태다. 대부분의 사용자는 제거하면 끝이라고 생각하지만, 실제로 시스템이 11시간 전에 심어 놓은 것은 제거 로직이 전혀 커버하지 못했다.

경험에 비추어 볼 때, 이번 사건 처리에서 긍정적으로 평가할 만한 점이 하나 있다. Cursor는 발견 후 신속히 악성 버전을 게시 중단하고 2.1.314를 배포했으며, 상세한 영향 범위 평가와 자체 점검 지침을 공개했다. 그러나 구조적으로 보면 이런 사건의 발생 조건은 여전히 보편적으로 존재한다. 확장 배포의 신뢰 사슬에서 어느 한 노드라도 교체될 수 있다면, 사용자에게는 진정한 안전감이 없다.

더 심각한 것은 이 공격이 대상 사용자를 무작위로 선택한다는 점이다. 당신이 겨냥된 대상일 필요는 없고, 그 시간 창에 그 버전 번호를 설치하기만 하면 된다. 당신이 구매한 플래그십 제품이 순식간에 저가형 대체套餐으로 변하는 것이다.

참고 문헌

- Cursor Security Notice: cursor.com/blog/claude…

- Phorion Analysis: phorion.io/blog/offica…

- Socket.dev Blog: socket.dev/blog/claude…

- OX Security Blog: www.ox.security/blog/malici…

- Brandefense Playbook: brandefense.io/security-ne…

- DEV Community Summary: dev.to/lycore/a-tr…

- Reddit Discussion: www.reddit.com/r/ClaudeCod…

확장 진입점

- 원문 아카이브: tobemagic.github.io/ai-magician…

- 위챗 공식 계정: 计算机魔术师

AI 풀스택 엔지니어

438

글

99k

읽음

90

팬