개발자 5,000명이 정말 해킹당했을까? Cursor 플러그인 악성코드 주입 사건은 현재까지 어떤 영향을 미쳤을까?

작성자 주: 이 글에서는 Cursor 플러그인 악성코드 삽입 사건에서 ‘최대 5000명 영향’이 실제로 무엇을 뜻하는지 살펴봐요. 공격 경로, 확인된 사례, API 키의 위험 범위와 자체 점검 방법을 정리해 근거 있는 주장과 과장된 주장을 구분해요.

2026년 10월 29일, Cursor 확장 프로그램 마켓플레이스에 변조된 Claude Code 확장 프로그램이 등장했어요. 며칠 뒤부터 ‘개발자 5000명 해킹’, ‘Claude API 키 대규모 유출’ 같은 제목이 퍼지기 시작했죠. 하지만 실제로는 5000명은 Cursor가 공식적으로 밝힌 잠재적 영향 사용자 수의 상한선이지, 확인된 침입 성공 사례가 5000건이라는 뜻이 아니에요.

그렇다고 위험을 축소하려는 건 아니에요. Cursor의 공식 공지와 Microsoft 보안 연구팀, Phorion, Expel 등 여러 기관이 사건 발생 사실을 확인했으며, 고객 기기에서 악성 활동도 관찰됐어요. 이 글에서는 ‘배포, 실행, 쓰기, 악용 가능, 실제 침입, 데이터 손실’의 여섯 단계로 나눠 확인된 사실과 아직 공개되지 않은 수치를 살펴봐요.

이 글의 핵심: Cursor 플러그인 악성코드 삽입 사건이 나와 팀에 미치는 실제 영향을 판단하고, 공식 권고에 따라 자체 점검과 인증 정보 교체를 진행할 수 있어요.

Cursor 플러그인 악성코드 삽입 사건 핵심 요약

먼저 확인된 기본 사실부터 살펴볼게요. 이 사건을 이해할 때 중요한 건 영향 범위예요. 개발 도구의 소프트웨어 공급망 공격이지, Claude 모델이 뚫리거나 Anthropic 내부 시스템이 침해된 사건은 아니에요.

Anthropic은 이 악성 빌드를 직접 개발하거나 배포하지 않았으며, 내부 시스템이나 직원 컴퓨터도 사건과 관련이 없다고 밝혔어요. 공격자가 Cursor 마켓플레이스에 빌드를 게시할 권한을 어떻게 얻었는지는 11월 2일 기준으로 조사 결과가 공개되지 않았어요.

Cursor 플러그인 악성코드 삽입 사건 주요 타임라인

이 사건에서는 두 가지 시간 개념을 혼동하기 쉬워요. 하나는 마켓플레이스에서 악성 패키지를 다운로드할 수 있었던 기간이고, 다른 하나는 설치된 기기에서 악성코드가 실제로 실행된 시점이에요. 실제 실행은 배포 중단보다 훨씬 늦게 이뤄질 수도 있어요. 플러그인이 내려갔다고 해서 로컬 기기까지 안전해진 것은 아니에요.

처음에는 Open VSX가 공격받았다는 보도도 있었어요. 이후 OpenSourceMalware가 이를 정정했고, Socket도 Open VSX 레지스트리 기록을 확인한 결과 해당 악성 버전을 찾지 못했어요. 현재까지 공격받은 것으로 확인된 채널은 Cursor Marketplace뿐이에요.

Cursor 확장 프로그램 변조의 작동 방식: 66줄짜리 로더부터 역방향 SSH 터널까지

Phorion과 OpenSourceMalware의 분석에 따르면, 공격자는 정상 확장 프로그램의 extension.js 맨 앞, 기존 코드가 시작되기 전에 약 66줄의 악성 JavaScript 로더를 삽입했어요. 확장 모듈이 로드되는 순간 실행되므로 사용자가 Claude에 메시지를 보내거나 코딩 작업을 승인할 필요도 없어요. Claude Code의 화면과 기능은 평소처럼 작동하고 일부 오류도 조용히 처리돼 사용자가 알아차리기 어려웠어요.

공격 과정은 다음 여섯 단계로 요약할 수 있어요.

1. 호스트 정보 수집: 호스트명, 사용자 이름, 운영체제와 CPU 아키텍처, 홈 디렉터리, 작업 디렉터리, Git 전역 이메일, 공인 IP 등을 수집해요.
2. SSH 인증 키 삽입: 사용자의 authorized_keys에 공격자가 관리하는 공개 키를 쓰고 svc-telemetry라는 표시를 남겨요.
3. SSH 서비스 활성화 시도: 기기에서 SSH 로그인이 가능해지면 공격자는 삽입한 키로 로그인할 수 있어요.
4. 역방향 SSH 터널 구축: 피해 기기가 공격자 서버의 TCP 22 포트에 먼저 연결한 뒤, 연결을 기기의 SSH 서비스로 전달해 일부 인바운드 제한을 우회해요.
5. 지속성 확보: macOS와 Windows에서는 로그인 후 자동으로 재연결되도록 설정하고, Linux에서는 crontab @reboot을 사용해 확장 프로그램이 없어도 백도어가 실행되도록 해요. 연결에 실패하면 약 60초마다 재시도해요.
6. 실행 상태 보고: TCP 8099 포트의 HTTP 비콘을 통해 호스트 정보와 각 단계의 실행 결과를 서버에 보고해요.

Cursor 확장 프로그램 변조가 프롬프트 인젝션이 아닌 이유

“Claude Code에서 문제가 생겼다”는 말을 들으면 악성 프롬프트가 모델을 조종했다고 생각하기 쉬워요. 하지만 이번 사건은 달라요. 전형적인 확장 프로그램 코드 실행 공격으로, 악성 로직은 모델 출력과 전혀 관계가 없어요. 어떤 IDE 확장 프로그램이든 같은 방식으로 변조될 수 있어요.

따라서 이 사건에서 Claude 모델 자체의 보안성을 논하는 건 의미가 없어요. 드러난 문제는 개발 도구의 확장 프로그램 배포 채널이 사칭되면 신뢰 체계가 무너질 수 있다는 점이에요.

악성 코드의 두 가지 구현 결함

이번 공격은 코드의 구현 오류 때문에 위험성이 일부 줄었어요. macOS에서 악성 코드는 관리자 권한 없이 원격 로그인 상태를 조회했어요. 이때 시스템은 “꺼짐”이 아니라 권한 오류를 반환해요. 그런데 프로그램은 상태가 명확히 “꺼짐”으로 확인될 때만 SSH를 켜도록 작성됐어요. 그래서 SSH가 꺼져 있던 많은 Mac에서 이 단계가 실패했어요.

Windows에서는 OpenSSH Server를 설치할 때 Unix 방식의 /bin/sh를 잘못 호출했어요. 표준 Windows 환경에는 이 경로가 없어요.

그렇다고 공격이 무효가 된 건 아니에요. 악성 코드는 여전히 공개 키를 쓰고, 지속성 확보 스크립트를 생성하고, 네트워크 연결을 시도하고, 호스트 정보를 보고할 수 있어요. 이미 SSH가 켜져 있던 기기는 위험이 훨씬 커요. Phorion 공동 창립자 Calum Hall도 WIRED와의 인터뷰에서 제대로 구현됐다면 매우 위험한 공격 진입점이 될 수 있었다고 말했어요.

개발자 5000명이 해킹당했을까요? Cursor 플러그인 공급망 공격의 영향 6단계

‘5000명’이라는 숫자는 Cursor가 10월 29일 처음 발표한 공지의 “At most 5,000 users were affected”에서 나왔어요. 최대 5000명의 사용자가 영향을 받았다는 뜻이에요. 이는 Cursor가 자체 발표한 상한선이지, 보안 기관이 독립적으로 확인한 침해 건수는 아니에요. 최초 공지에는 2.1.313만 언급됐지만, 업데이트 후 2.1.312가 추가됐어요. 다만 Cursor는 각 버전에 해당하는 사용자 수나 수정된 전체 인원의 세부 내역을 공개하지 않았어요.

영향을 여섯 단계로 나누면 무엇이 확인됐고 무엇이 추정에 불과한지 더 분명해져요.

그림의 양쪽 차이가 바로 뉴스 제목과 증거 사이의 차이예요. 깔때기 아래로 내려갈수록 공개된 증거는 줄어들어요. 현재로서는 “컴퓨터 5000대가 완전히 장악됐다”거나 “5000명의 API 키가 도난당했다”는 두 주장 모두 뒷받침할 증거가 없어요.

Expel의 실제 사례 4건이 보여주는 것

Expel은 10월 29일부터 30일까지 고객 4곳에서 발생한 관련 사건 4건을 처리했어요. 각 사건에서 영향을 받은 기기는 Mac 1대씩이었어요. 이 중 3대는 CrowdStrike Falcon을, 1대는 Microsoft Defender for Endpoint를 사용하고 있었어요. 4건 모두 공격자 서버 IP로 향하는 네트워크 연결이 확인됐어요. 이는 사건이 실험실에서 코드를 분석하는 단계를 넘어 실제 환경에서도 발생했다는 뜻이에요.

가장 주목할 만한 건 실행이 지연된 사례예요. 사용자가 베이징 시간 10월 30일 12:44에 Mac에 로그인해 Cursor를 실행하자 1분 뒤 악성 활동이 나타났어요. 22:29까지도 공격자 IP로의 연결이 이어져, 그 기간이 거의 10시간에 달했어요. 이때는 악성 패키지가 마켓플레이스에서 내려간 지 오래였어요. 패키지가 노출 기간에 이미 다운로드됐고, 사용자가 Cursor를 다시 열었을 때 실행됐다는 해석이 더 합리적이에요.

이 데이터의 해석에는 분명한 한계가 있어요. 4건이 전 세계에서 감염된 기기가 4대뿐이라는 뜻은 아니며, 4를 5000으로 나눠 감염률을 계산할 수도 없어요. SSH 터널이 탐지됐다고 해서 공격자의 로그인이 성공했다는 뜻도 아니에요. Phorion도 고객의 Mac에서 샘플을 발견했지만, Expel의 사례와 겹치는지는 불분명하므로 단순히 합산할 수 없어요. Expel은 악성 터널 프로세스가 실행 중이지만 svc-telemetry 공개 키 표식은 없는 기기도 발견했어요. 표식 하나만 검색하면 탐지에서 누락되기 쉽다는 뜻이에요.

Cursor 플러그인 악성코드 삽입 사건의 API 키 위험 범위

악성 코드는 이름에 KEY, TOKEN, SECRET, PASS, AWS, GCP가 포함된 환경 변수를 최대 40개까지 찾아내요. 예를 들어 기기에 OPENAI_API_KEY가 설정되어 있다면 공격자는 해당 서비스를 사용한다는 사실을 알 수 있어요. 하지만 연구진이 확인한 초기 전송 대상은 변수의 값이 아닌 변수 이름뿐이었어요.

따라서 정확히 말하면 공격 코드는 민감한 설정의 종류를 식별할 수 있었어요. 백도어가 실제로 악용됐다면 공격자가 로컬 자격 증명과 소스 코드를 추가로 읽었을 가능성도 있어요. 실제로 얼마나 많은 API 키가 도난당했는지는 현재 공개된 자료가 없어요. “모든 사용자의 API 키가 도난당했다”는 주장은 가능성을 결과와 동일시한 것이에요. 다만 위험 범위가 불분명한 만큼 예방 차원에서 자격 증명을 교체하는 것이 좋아요.

Cursor 플러그인 악성코드 삽입 사건의 영향 분석

개발자에게 미치는 영향

• 플러그인 삭제만으로는 부족해요: 공식 안내에 따르면 플러그인을 삭제하거나 2.1.314로 업그레이드해도 이미 추가된 SSH 공개 키, 시작 항목, 백그라운드 스크립트가 반드시 제거되는 것은 아니에요.
• 스토어에서 삭제된 후에도 실행될 수 있어요: Expel이 확인한 지연 실행 사례를 보면, “플러그인이 삭제된 후에야 Cursor를 연” 사용자도 직접 확인해야 해요.
• SSH를 상시 켜둔 기기는 위험이 더 커요: 원격 디버깅을 위해 개발 기기에서 Remote Login을 켜두는 경우가 많은데, 이 경우 악성 코드의 구현 결함을 피해 갈 수 있어요.
• 자격 증명 노출 범위가 파악됐을 수 있어요: 백도어가 성공적으로 악용되지 않았더라도 공격자가 어떤 클라우드 서비스와 API를 사용하는지 이미 알아냈을 수 있어요.

팀과 업계에 미치는 영향

• 플러그인 배포가 새로운 공격 표면이 됐어요: 같은 확장 프로그램이라도 마켓플레이스에 따라 버전의 출처가 다를 수 있어요. 버전 번호만 보지 말고 설치 출처와 파일 해시를 함께 확인해야 해요.
• AI 코딩 도구의 터미널 권한을 재평가해야 해요: IDE 플러그인은 보통 사용자 권한으로 실행되며 홈 디렉터리를 읽고 쓰거나 네트워크에 연결할 수 있어요. 기업은 이를 엔드포인트 관리 대상에 포함해야 해요.
• 사고 대응은 자격 증명의 전체 수명 주기를 다뤄야 해요: 영향을 받은 기기에서 접근할 수 있는 저장소, API 키, 클라우드 자격 증명, 세션 토큰을 모두 평가해야 해요. 프로젝트에서 사용하는 키가 여러 곳에 흩어져 있을수록 교체 비용도 커져요.

Cursor 플러그인 오염 자가 점검과 자격 증명 교체 실습

먼저 Cursor 공식 공지에서 제공하는 macOS 및 Windows 점검·복구 스크립트를 사용하세요. 아래 지표와 명령어는 이해와 점검을 돕기 위한 것으로, 공식 스크립트와 로그 조사를 대체할 수 없어요.

1단계: 로컬 환경 빠른 점검（macOS 예시）

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

Windows 사용자는 schtasks /query /tn SysMon으로 예약 작업을 확인한 다음, 시작 폴더에서 sysmon.cmd를 찾아보세요. 어느 하나라도 발견되면 증거를 보존하고 기기를 격리한 뒤 공식 스크립트로 정리해야 해요. 기기의 신뢰할 수 있는 상태를 복구할 수 없다면 시스템 재설치를 고려하고, 다른 신뢰할 수 있는 기기에서 자격 증명을 교체하세요.

2단계: 노출된 자격 증명 변수 이름 확인하기

다음 스크립트는 악성 코드와 동일한 키워드로 환경 변수를 필터링해 값은 출력하지 않고 이름만 출력해요. 이를 통해 교체해야 할 자격 증명 목록을 확인할 수 있어요. 교체한 뒤에는 간단한 API 호출로 새 API 키가 작동하는지 확인하세요.

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

세 번째 단계: 우선순위에 따라 자격 증명 교체하기

🎯 기술 팁: 프로젝트에서 OpenAI, Claude, Gemini 등 여러 플랫폼에 직접 연결한다면, 사고 발생 후 각 플랫폼의 관리 콘솔에 로그인해 키를 폐기하고 다시 발급해야 해요. 공식적으로 권장하는 방법은 모델 호출을 APIYI apiyi.com으로 통합하는 거예요. 키 하나로 여러 주요 모델을 사용할 수 있고 OpenAI와 인터페이스도 호환돼요. 키를 교체할 때 설정 한 곳만 수정하면 되며, 사용량을 한곳에서 확인하고 비정상적인 비용도 쉽게 발견할 수 있어요.

자주 묻는 질문 FAQ

Cursor 확장 프로그램 악성코드 삽입 핵심 요약 Key Takeaways

• 사건의 성격: Cursor 마켓플레이스를 통해 변조된 확장 프로그램이 배포된 공급망 공격이에요. Claude 모델의 취약점은 아니에요.
• 5000명의 의미: 공식적으로 제시된 잠재적 영향의 상한선이지, 침해가 확인된 인원은 아니에요.
• 확인된 사실: 독립 기관이 실제 Mac에서 악성 활동과 외부 통신을 관찰했어요.
• 공개되지 않은 정보: 원격 로그인 성공 건수, 탈취된 키의 수, 경제적 피해 규모는 공개되지 않았어요.
• 주요 위험: 마켓플레이스에서 내려간 뒤에도 악성 코드가 실행될 수 있으며, 확장 프로그램을 삭제해도 백도어가 제거된다는 보장은 없어요.
• 대응 방법: 공식 스크립트를 실행하고, 신뢰할 수 있는 기기에서 자격 증명을 교체하며, APIYI apiyi.com을 활용해 키의 수를 줄이세요.

정리

Cursor 확장 프로그램 악성코드 삽입 사건의 핵심은 다음과 같아요.

1. 제목과 증거를 구분하세요: “최대 5000명에게 영향을 미쳤을 가능성이 있다”와 “5000명이 해킹당했다”는 전혀 다른 얘기예요. 현재 공개된 증거는 실제 악성 코드 실행 사례가 확인됐다는 수준이에요.
2. 공격은 실제로 존재했지만 성공률에는 한계가 있었어요: 악성 코드에는 백도어와 지속성 유지 기능이 있지만, macOS와 Windows의 구현상 결함으로 원격 로그인 성공률이 낮아졌어요.
3. 한 가지만 확인해서는 안 돼요: 설치 출처, 파일 해시, 프로세스, 네트워크 연결, 시작 항목을 함께 살펴봐야 해요. svc-telemetry만 검색하면 놓치는 항목이 있을 수 있어요.

10월 29일부터 30일 사이에 Cursor 마켓플레이스에서 Claude Code 확장 프로그램을 사용했다면, 먼저 공식 지침에 따라 점검한 뒤 우선순위에 맞춰 자격 증명을 교체하세요. 모델 API의 경우 이번 기회에 흩어진 키를 APIYI apiyi.com으로 통합하면, 다음에 긴급 교체가 필요할 때 훨씬 수월해져요.

📚 참고 자료

1. Cursor 공식 보안 공지: 사건 발생 시점, 버전, 악성 파일 해시 및 정리 스크립트
2. 링크: cursor.com/blog/claude-code-extension-security-notice

3. 설명: 자체 점검 시 먼저 확인하세요. macOS와 Windows용 복구 스크립트가 포함되어 있어요.

4. Microsoft Security Research: 악성 Claude Code 확장 프로그램의 공격 체인 분석

5. 링크: microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. 설명: 공급망 경계, SSH 작동 방식, 지속성 확보 방법을 확인할 수 있어요.

7. Phorion: Official Claude Code Extension Compromise

8. 링크: phorion.io/blog/offical-claude-code-vsx-compromise/

9. 설명: 66줄짜리 로더, 플랫폼별 차이와 코드 결함에 관한 기술적 세부 사항을 다뤄요.

10. Expel: Fake Claude Code extensions in Cursor

11. 링크: expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. 설명: 실제 고객 사건 4건과 지연 실행 사례를 소개해요.

13. Socket: Cursor Removes Malicious Claude Code Extension

14. 링크: socket.dev/blog/claude-code-extension-compromise
15. 설명: Open VSX와 npm 기록을 확인하고 초기 오보를 바로잡아요.

작성자: APIYI 기술팀
기술 문의: APIYI apiyi.com 홈페이지에서 문의해 주세요. 더 많은 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.

관련 글

• Claude Code 확장 프로그램에 악성 코드 주입: 2.1.313 백도어, 5단계 자가 점검 및 제거: 10월 29일 Cursor Marketplace의 공식 Claude Code 확장 프로그램 2.1.312와 2.1.313이 SSH 백도어가 포함된 빌드로 교체되어 최대 5,000명의 사용자가 노출된 사건을 완전히 마무리할 수 있도록, 이 글에서는 svc-telemetry 공개 키 자체 점검, LaunchAgent와 예약 작업 등 지속성 설정 제거, 2.1.314 이상으로 업그레이드, GitHub·클라우드 자격 증명 및 APIYI 키 교체 방법을 5단계로 설명합니다.
• Claude Max, Ultra로 이름 변경… 5시간 제한도 사라졌을까? 먼저 확인할 3가지 변화: Claude Max 20x는 Ultra로, Max 5x는 Max로 이름이 바뀌지만 가격은 그대로이며, 인증된 Ultra 계정의 5시간 제한은 폐지되고 주간 한도는 유지되므로, 이 글의 비교표와 3단계 자가 점검, 비용 계산을 통해 요금제 변경 여부를 판단하세요.