두 개의 CVE, 하나의 조용한 버그 유형

Cursor는 2026년 가장 많이 사용되는 AI 지원 IDE 중 하나이며, 여기에는 타당한 이유가 있습니다. 개발자가 코드를 읽고, 편집하고, 실행하고, 검증하는 단일 루프 내에서 에이전트(Agent)에게 실제 작업을 위임할 수 있게 해주기 때문입니다. 이제 그 기능이 보안 검토자의 책상 위에 올라왔습니다. Cato Networks의 연구원들은 프롬프트 인젝션 (Prompt Injection)을 통해 명령 실행 샌드박스 (Sandbox)를 탈출하고 원격 코드 실행 (RCE)으로 이어지는 Cursor IDE의 두 가지 취약점을 공개했습니다. CVE-2026-50548 및 CVE-2026-50549로 추적되는 이 결함들은 사전 사용자 권한이나 특정 사용자의 상호작용을 필요로 하지 않습니다.

마지막 문구가 핵심입니다. 대부분의 샌드박스 탈출 (Sandbox escape)은 클릭, 확인, 또는 잘못 설정된 권한을 필요로 합니다. 하지만 이 결함들은 그렇지 않습니다. 개발자가 일반적인 프롬프트처럼 보이는 내용을 입력하는 것만으로도 충분합니다.

샌드박스가 수행하기로 되어 있었던 일

Cursor의 명령 실행 샌드박스 (Command execution sandbox)는 AI 에이전트와 기본 운영 체제 사이의 보호 계층입니다. 정상적인 작동 상태에서 에이전트는 워크스페이스의 파일을 읽고 편집하며, 빌드 및 테스트 명령을 실행하고, MCP 서버와 통신할 수 있습니다. 하지만 샌드박스는 에이전트가 호스트에서 임의의 행동을 하는 것, 즉 ~/.ssh에 쓰기, 클라우드 자격 증명 읽기, 공격자가 제어하는 엔드포인트로 curl 명령을 보내는 것 등을 차단해야 합니다.

이 샌드박스 모델은 매우 정교한 균형을 맞춰야 합니다. 에이전트가 실제로 유용한 작업(테스트 스위트 실행, 의존성 설치, 파일 포맷팅 등)을 수행할 수 있을 만큼 허용적이면서도, 혼란을 겪거나 악의적인 프롬프트에 의해 유도된 에이전트가 호스트로 탈출할 수 없을 만큼 제한적이어야 합니다. 두 개의 CVE는 내부에서 그 간극을 메워버립니다. 에이전트는 자신의 컨텍스트(Context) 내에 머물러 있지만, 에이전트가 읽는 '콘텐츠'가 샌드박스 경계를 넘어 명령을 전달하는 지침을 담고 있는 것입니다.

두 개의 CVE를 쉬운 영어로 설명하자면

CVE-2026-50548 및 CVE-2026-50549는 동일한 전달 메커니즘을 통해 도달할 수 있는, Cursor의 샌드박스(sandbox)를 벗어나는 두 가지 서로 다른 경로를 다룹니다. Cato Networks의 보고서에 따르면 다음과 같습니다:

"이는 피해자가 무해한 프롬프트(prompt)를 작성했을 때, MCP 서버나 웹 검색 결과와 같이 신뢰할 수 없는 소스로부터 공격자가 제어하는 페이로드(payload)를 의도치 않게 흡수할 때 발생합니다."

즉, 공격자가 Cursor에 직접 침입하는 것이 아닙니다. 에이전트가 읽게 될 입력을 오염시킨 다음, 개발자가 일반적인 질문을 던지기를 기다리는 것입니다. 에이전트는 오염된 콘텐츠를 가져와 그 일부를 지침(instructions)으로 취급하고, 의도된 샌드박스 경계 외부에서 공격자의 페이로드를 실행합니다.

이것이 '읽기, 오해하기, 실행하기'라는 세 단계로 이루어진 전체 킬 체인(kill chain)입니다.

[[DIAGRAM: 개발자가 일반적인 프롬프트를 입력함 → 에이전트가 MCP 서버나 웹 검색 결과로부터 오염된 콘텐츠를 가져옴 → 에이전트가 해당 콘텐츠의 일부를 지침으로 해석함 → 샌드박스를 우회하는 셸 명령(shell command)을 실행함]]

프롬프트 인젝션(Prompt Injection)이 어떻게 RCE가 되는가

프롬프트 인젝션(Prompt Injection)은 LLM이 데이터로 읽어야 할 텍스트가 지침으로 해석되는 실패 모드(failure mode)입니다. 컨텍스트 윈도우(context window)를 통해 들어오는 모든 것은 문자열(string)로 보이기 때문에, 모델은 무엇이 데이터이고 무엇이 지침인지 구별할 수 있는 신뢰할 수 있는 방법이 없습니다. Cursor의 샌드박스는 최후의 보루(backstop) 역할을 하도록 설계되었습니다. 즉, 모델이 위험한 행동을 하고 싶도록 속더라도, 에이전트가 실제로 호스트(host)에 셸을 실행(shell out)할 수는 없어야 한다는 것입니다.

이 CVE들은 그 최후의 보루가 무너지는 상황을 보여줍니다. 구체적인 공격 형태는 다음과 같습니다:

# 개발자가 입력하는 무해해 보이는 프롬프트
"이 이슈를 확인하고 수정해 줄 수 있어?"

...

'샌드박스 우회(sandbox bypass)' 요소는 이것을 단순히 혼란을 주는 모델의 응답이 아닌 RCE(원격 코드 실행, Remote Code Execution)로 만드는 핵심입니다. 에이전트는 단순히 당황스러운 말을 내뱉는 것에 그치지 않고, 개발자의 세션에서 개발자의 권한을 가지고 실제 OS 명령을 실행합니다. 일단 에이전트가 호스트에 접근할 수 있게 되면, 채팅창에서는 그저 잘못된 답변에 불과했을 프롬프트 인젝션 트릭이 임의 코드 실행(arbitrary code execution)으로 변하게 됩니다.

이것이 Cursor만의 버그가 아닌 LLM급 버그인 이유

여기서는 Cato의 프레임워크가 중요합니다. 연구진은 이러한 결함이 Cursor뿐만 아니라 LLM(대규모 언어 모델)과 AI 지원 IDE(통합 개발 환경)의 고유한 결함을 드러내는 것이라고 설명합니다. 그 이유는 특정 벤더의 문제가 아닌 구조적인 문제입니다. 다음 세 가지 속성이 동시에 충족되어야 합니다:

1. 에이전트가 신뢰할 수 없는 소스로부터 읽어옵니다. MCP 서버, 웹 검색 결과, 가져온 문서(fetched docs), 제3자 README, 리포지토리 이슈(repository issues) 등이 모두 컨텍스트 윈도우(context window)에 들어옵니다.
2. 에이전트가 호스트에 접근할 수 있는 도구(tools)를 가지고 있습니다. 셸(Shell), 파일 시스템(file system), 네트워크(network) 등이 이에 해당합니다. 이러한 도구가 없다면 에이전트는 실제로 작업을 수행할 수 없지만, 이 도구들이 있다면 에이전트는 무엇이든 할 수 있습니다.
3. 모델이 "사용자의 지시(instructions from the user)"와 "가져온 콘텐츠에 포함된 지시(instructions embedded in fetched content)"를 안정적으로 구분할 수 없습니다. 모델은 이러한 구분을 인지할 수 있는 권한이 없습니다. 이는 신중하게 설계된 시스템 프롬프트(system prompt)가 강제하려고 시도할 수 있는 속성이지만, 프롬프트 인젝션(prompt injection)은 바로 그 지점을 겨냥한 잘 알려진 공격 방식입니다.

이 세 가지 속성을 모두 충족하는 모든 IDE는 동일한 범주에 속합니다. Cursor는 단지 오늘날 이름이 붙은 CVE(공통 보안 취약점)를 보유한 사례일 뿐입니다.

현재 할 수 있는 일

좋은 소식은 대부분의 완화 조치가 생소한 것이 아니라 운영적인 측면이라는 점입니다. 팀에서 Cursor를 사용한다면, 다음 네 가지가 상황을 개선할 수 있습니다:

# 1. CVE-2026-50548 / CVE-2026-50549를 해결한 버전으로 Cursor를 패치하세요.
# 작업을 계속하기 전에 Cursor → Updates(또는 사용 중인 패키지 관리자)를 확인하여
# 릴리스 노트에 해당 CVE들이 명시되어 있는지 확인하십시오.
...

Cursor 자체를 넘어, 팀이 채택하는 모든 AI 지원 IDE에 대해 표준화할 가치가 있는 세 가지 습관은 다음과 같습니다:

• 기본 차단 방식의 도구 노출 (Deny-by-default tool surface). 에이전트는 현재 작업에 필요하지 않은 셸 (Shell) 액세스 권한을 가져서는 안 됩니다. 대부분의 "자동 승인 (auto-approve)" 토글은 편의 기능이지만, 가져온 페이지에 악의적인 지침이 포함되는 순간 CVE(취약점)로 변질됩니다.
• 아웃바운드 송신 필터링 (Outbound egress filtering). 개발자의 에디터가 임의의 URL로 curl을 실행할 수 있다면, 프롬프트를 제어하는 공격자가 송신 (egress) 경로를 제어하게 됩니다. 송신 허용 목록 (allowlist) (예: github.com, npm registry, 내부 CI는 허용하고 나머지는 차단)을 설정하면 공격 체인 (kill chain)의 절반인 데이터 유출 (exfiltration)을 무력화할 수 있습니다.
• IDE 자체를 샌드박스 (Sandbox)에서 실행. 호스트 키 (host-key) 액세스가 없고, 영구적인 자격 증명 (credentials)이 없으며, 재시작 시 파일 시스템이 초기화되는 컨테이너 또는 VM을 사용하면, "에이전트가 셸 명령을 실행했다"는 상황이 보안 침해에서 단순한 불편함 수준으로 격하됩니다. 이는 Cursor의 내부 샌드박스가 불필요하게 만들고자 했던 조치였으나, 여전히 필요합니다.

보안 팀에게 이번 공개는 기존 탐지 영역 (detection surface)에 AI-IDE 에이전트 트래픽을 추가하도록 강제하는 계기가 됩니다. 에이전트의 아웃바운드 명령을 새로운 CI 러너 (runner)를 다루는 것과 동일하게 취급하십시오. 즉, 로그, 허용 목록 (allowlist), 그리고 기준점 (baseline)을 갖추어야 합니다.

이것이 AI 지원 개발에 의미하는 바

불편한 결론은 이제 "IDE 내의 AI"가 단순한 생산성 기능이 아니라 보안 노출 영역 (security surface)이 되었다는 점입니다. 읽고, 쓰고, 실행하고, 검증하는 에이전트의 편리함은 프롬프트 인젝션 (Prompt Injection)이 코드 실행 (code execution)을 위한 전달 메커니즘이 되게 만드는 것과 동일한 속성입니다.

그렇다고 IDE에서 AI 사용을 중단하라는 뜻은 아닙니다. Cursor는 카테고리를 정의하는 제품을 출시했으며, 보안 커뮤니티는 이제 카테고리를 정의하는 제품에 대해 항상 그래왔듯 제품을 철저히 검증 (kicking the tyres)하고 있는 것입니다. 이는 에이전트를 셸 액세스 권한이 있고 Stack Overflow에서 코드를 복사해 붙여넣는 습관이 있는 주니어 엔지니어처럼 대하라는 의미입니다. 샌드박스화하십시오. 감사(Audit)하십시오. 패치(Patch)하십시오.

그 아래에 있는 지속 가능한 계층

도구(Tools)는 급변합니다. 모델(Models)은 변합니다. CVE(취약점)는 계속 등장합니다. 매 분기마다 움직일 필요가 없는 부분은 사용자가 실제로 만지는 UI 계층(UI layer)입니다. 즉, 웹, iOS, Android에서 동일한 방식으로 렌더링되는 바로 그 컴포넌트입니다. 그 계층이야말로 지루할 정도로 안정적이고 버전 관리가 잘 되어야 할 가치가 있는 부분입니다. 그래야 다음 샌드박스 우회(sandbox bypass) 공격이 다른 도구에 영향을 미치더라도, 사용자가 보는 버튼, 리스트, 폼(forms)이 폭발 반경(blast radius)에 포함되지 않을 것입니다.

Cursor를 사용하십시오. 패치(Patch)하십시오. MCP를 잠그십시오(Lock down). 그리고 그 아래의 UI를 안정적으로 유지하십시오.