詳細検索

커서 취약점 "MCPosion"이란 무엇인가요? RCE가 AI 편집기를 표적으로 공격하다

아바타
글쓴이 ジェホ
5분 읽기

커서 취약점 "MCPosion"이란 무엇인가요? RCE가 AI 편집기를 표적으로 공격하다
日本語에서 번역 • 원문 보기
ジェホ
ジェホ

안녕하세요 여러분. 저는 Colorkrew Security의 보안 엔지니어 연재호입니다.

 

최근 몇 년간 개발은 생산성 향상을 위해 AI 기반 코드 완성 및 자동화 도구를 빠르게 도입했습니다. 커서, 코파일럿, 다양한 LLM 기반 IDE는 더 이상 소수의 고급 팀만을 위한 것이 아니라 많은 개발 조직에서 일상적인 도구가 되었습니다.

하지만 이 '편리함' 뒤에는 지금까지 개발 환경에는 존재하지 않았던 새로운 공격 표면이 있다는 사실을 알고 계셨나요?

이 블로그에서는 AI 코드 편집기 커서 에서 발견된 치명적인 취약점에 대해 논의할 것입니다.
"원격 코드 실행(RCE) MCP(모델 컨텍스트 프로토콜) 설정을 남용"
―― MCPosion(CVE-2025-54136), 일반적으로 MCPosion으로 알려진 것의 메커니즘, 공격 흐름, 위험 및 실질적 대응책을 조직하고 설명할 것입니다.


위협 요약: AI의 "신뢰 설정"이 공격의 출발점이 되

이 취약점의 본질은 **Cursor가 사용하는 바로 그 '신뢰 모델'**에 있습니다.

커서는 AI가 외부 도구를 조작하는 메커니즘으로 MCP(모델 컨텍스트 프로토콜) 를 사용합니다.
개발자는 각 프로젝트별로 '.cursor/rules/mcp.json'를 정의할 수 있으며, 여기에는 다음과 같은 정보가 포함될 수 있습니다:

  • MCP 이름
  • 실행해야 할 명령
  • 인수(매개변수)

커서가 프로젝트를 열면 자동으로 이 '.cursor' 디렉터리를 스캔하고 정의된 MCP를 처리합니다.

문제는 여기서 시작됩니다.

사용자가 "이 MCP를 신뢰합니다" 라고 인정하면,
**이제부터는 신뢰 결정이 오직 '이름'만을 바탕으로 이루어지며, 실행 명령어나 인자 변경은 이중 검증되지 않습니다. **

이 행동을 남용함으로써,
나중에 악성 명령어로 교체하면 추가 승인 없이 실행됩니다
심각한 병이 발생한다.


공격 흐름: GitHub의 "평범한 협업"이 함정으로 변함

MCPosion 공격은 매우 현실적이고 조용하게 진행됩니다.
특별한 취약한 서버나 공용 서비스가 필요하지 않습니다.

**공격의 흐름은 다음과 같습니다: **

1. 초기 침입: 겉보기에는 무해해 보이는 커밋

공격자는
겉보기에는 괜찮은 MCP 구성을 포함하는 커밋을 만드세요 .

  • 악성 명령은 포함하지 않음
  • 일반 도구 정의처럼 보입니다
  • 리뷰할 때 덜 의심스러워

이 단계에서는 손상이 아직 발생하지 않을 것입니다.


2. 커서에 프로젝트 승인

피해자(개발자)가 커서에서 프로젝트를 열면,
새 MCP에 대한 확인 대화 창이 나타날 것입니다. "실행을 허용하시겠습니까?"

여기서 사용자가 승인하면,
MCP 이름은 신뢰 상태로 기록됩니다.


3. 악성 탑재체 주입

공격자는
**이미 신뢰받는 MCP의 "실행 명령어"와 "인자"만 교체하세요. **

  • MCP 명칭 변경 없음
  • 하지만 실행 내용은 완전히 다릅니다
  • 커서는 재승인을 요청하지 않습니다

이것이 바로 이 취약점의 핵심입니다.


4. 착취 실행: 동기화와 재시작만 가능한 RCE

피해자가 다음 중 어느 하나라도 행동하는 순간 공격이 성립됩니다:

  • 저장소 동기화 (풀)
  • 커서 재시작

그 결과,
악성 명령은 사용자 권한으로 즉시 실행됩니다 .

연구들은 역탄을 이용한 완전한 시스템 제어 도 확인했습니다.


왜 위험한가: 전통적인 보안 가정을 깨뜨리다

이 문제가 심각한 이유는 단순한 '도구 버그'가 아니라는 점입니다.

전통적인 가정

  • GitHub 저장소가 검토됩니다
  • 로컬 실행된 코드는 본인 책임입니다
  • IDE는 "수동 도구"입니다.

MCPosion이 직면한 현실

  • 설정 파일이 실행 대상이 됩니다.
  • AI가 자동으로 명령을 실행합니다
  • "원 트러스트"는 미래의 변화를 허용합니다

다시 말해,
AI 지원 개발 환경 자체가 공격 벡터가 됩니다
새로운 위협 모델이 드러났습니다.


탐지 난이도: 기록이나 경고 없음

이 공격은 다음과 같은 이유로 탐지하기 매우 어렵습니다:

  • 정식 GitHub 작업 (커밋/풀)
  • 정식 커서 동작
  • 사용자 본인이 승인한 MCP

EDR과 안티바이러스 관점에서도 마찬가지입니다.
대부분의 경우 "개발자가 그냥 도구를 사용했다"는 것처럼 보입니다.


대응책: "AI 개발 환경을 너무 신뢰하지 마라"

1. 커서 업데이트 (최우선)

이 취약점은 최신 버전에서 수정되었습니다 .
커서를 사용하는 환경에서는 프롬프트 업데이트가 강력히 권장됩니다.


2. 코드 검토를 위한 MCP 구성 표적

  • '.cursor/'를 일반 코드처럼 검토하세요
  • 단순히 MCP의 '이름'이 아닙니다
    실행 명령어와 인수에 대한 차분 검사가 필요합니다

3. AI 도구의 권한을 최소화하세요

  • 개발 터미널에서 관리자 권한 사용을 피하세요
  • AI 도구를 통해 실행되는 명령의 영향 범위를 제한합니다

4. "신뢰"의 재정의

  • 설계를 승인 = 영구 신탁으로 가정하지 마십시오
  • 팀 내에서 AI 도구 사용 정책을 명확히 명시하세요

결론: AI는 강력하지만 중립적이지 않

MCPosion
이 이야기는 "AI 사용 자체가 위험하다"는 것이 아닙니다.

문제는,
그 이유는 인간이 쌓아온 '신뢰의 경계'가 AI 시대의 업무 흐름에 직접 적용되었기 때문입니다.

AI는 코드를 작성합니다,
AI가 도구를 구동하고,
AI가 설정을 해석하고
그리고 AI는 공격 경로가 될 수도 있습니다.

지금이 바로 그때입니다,
"AI가 할 수 있는 일은 어느 정도로, 누구의 권한으로 이루어지는가?"
다시 물어볼 때입니다.

개발 효율성과 보안은 절충이 아닙니다.
잘 설계하면 둘 다 할 수 있습니다.

이 블로그가 여러분이 AI 개발 환경을 검토하는 데 영감을 주길 바랍니다.

지금까지 Colorkrew Security의 Jaeho Yoon이 최고의 소식을 전해드렸습니다.
정말 감사합니다.

Related Articles