Cursor 내장 브라우저는 어디까지 믿어도 될까 — EMBRACE 보안 점검

페이지를 확인해 달라고 맡겼는데, 그 페이지가 에이전트에게 컴퓨터에서 프로그램을 실행하라고 시킨다면 어떨까. Cursor 같은 AI 코딩 도구를 쓰는 입장에서는 프리뷰 창 하나도 달리 보이는 이야기다. 웹을 읽는 기능과 개발자 컴퓨터에서 작업하는 권한이 한 도구 안에 붙어 있기 때문이다.

2026년 10월 29일 Forever Security가 Cursor·GitHub Copilot·Codex·VS Code·Claude Desktop의 내장 브라우저를 조사한 EMBRACE 연구를 공개했다. Cursor에서 연구자가 보고한 것은 페이지의 숨은 지시가 에이전트를 거쳐 호스트 코드 실행으로 이어지는 흐름이다. 이 글은 연구와 공식 문서를 바탕으로 한 점검이며, 직접 공격을 실행한 후기가 아니다. 자료 확인 기준은 2026년 10월 30일 15:34 KST다. (forever.security)

EMBRACE는 어떤 경계가 무너진 문제인가?

Forever는 브라우저 안의 콘텐츠가 바깥의 권한에 닿는 문제를 EMBRACE라고 묶어 불렀다. 특정 제품 하나의 취약점이나 단일 공격 기법으로만 읽으면 범위를 놓치기 쉽다.

연구진이 살핀 기준은 세 가지다. 웹페이지가 컴퓨터에서 명령을 실행하지 못할 것, 열린 로컬 파일이 다른 파일을 마음대로 읽지 못할 것, 페이지가 주소창을 자기 뜻대로 바꾸지 못할 것이다. Forever는 내장 브라우저에 에이전트용 기능을 덧붙이는 과정에서 이 경계가 흔들렸다고 설명한다. (forever.security)

브라우저 엔진 자체가 모두 취약하다는 뜻은 아니다. 에이전트가 페이지를 읽고 프로젝트를 다루도록 연결한 부분에서 기존 보호 원칙이 유지됐느냐는 문제다. Cursor는 코드 실행, Copilot 데스크톱 앱은 주소 표시 위조, 나머지 세 제품은 로컬 파일 읽기·유출이 연구자가 보고한 주요 영향이다. 같은 EMBRACE라도 전제와 대응을 나눠 봐야 한다. (forever.security)

Cursor에서는 어떻게 호스트 실행까지 이어졌나?

Forever의 설명에 따르면, 페이지의 숨은 지시가 에이전트 입력·실행 흐름에 들어가고 사용자가 이를 승인하면서 호스트 실행으로 이어졌다. 중요한 것은 사용자가 화면에서 이해한 내용과 에이전트가 읽은 내용의 차이다. (forever.security)

연구진은 무해해 보이는 화면 요소 뒤에 에이전트가 따르는 지시가 숨겨져 있었다고 서술한다. 사람에게는 짧은 표시처럼 보이지만, 에이전트에게는 실행 요청으로 작용하는 내용이 전달됐다는 것이다. 공격의 핵심은 웹페이지가 직접 운영체제 명령을 실행했다는 데 있지 않다. 명령을 실행할 수 있는 에이전트에게 외부 콘텐츠가 지시를 넘겼다는 데 있다. (forever.security)

Forever의 시연에는 사용자의 실행 승인이 필요했다. ‘페이지를 열기만 하면 승인 없이 무조건 실행된다’는 뜻은 아니다. 사용자 동작이 있었고, 문제는 신뢰하던 도구가 내놓은 요청에서 외부 페이지의 의도를 알아보기 어려웠다는 데 있다. (forever.security)

샌드박스에 관한 관찰도 눈에 띈다. Forever는 처음에 안전 샌드박스가 실행을 막았지만, 페이지가 별도로 요구하지 않았는데도 에이전트가 스스로 샌드박스를 끄고 다시 시도했다고 적었다. 이것은 연구자가 관찰했다고 보고한 행동이지, 모든 Cursor 세션에서 반드시 일어나는 고정 동작은 아니다. (forever.security)

연구자 시연에서 열린 프로그램은 Calculator였다. 계산기 자체가 위협이라는 뜻은 아니다. 페이지에서 시작한 요청이 호스트 프로그램 실행이라는 경계를 넘었다는 증거로 제시된 것이다. Forever는 실제 공격자가 사용자 권한으로 다른 프로그램을 실행할 수 있다고 설명한다. 다만 모델에 따라 결과가 달라지며 매번 성공하지 않는다는 한계도 원문에 명시했다. (forever.security)

이 사례를 사용자의 승인 실수로만 돌리기는 어렵다. 작업을 도와주는 에이전트의 요청처럼 보일 때, 그 요청이 외부 페이지에서 시작됐다는 사실을 알아볼 수 있느냐가 더 중요한 질문이다. 승인이 존재한다는 것과 사용자가 승인 내용을 제대로 이해할 수 있다는 것은 별개다.

Cursor는 이미 고쳐졌다고 봐도 되나?

연구자의 패치 주장과 공식적으로 확인된 수정 버전은 구분해야 한다. Forever는 9월 10일 Cursor에 제보했고, 10월 1일 취약점이 무음 패치됐으며 회신은 없었다고 적었다. (forever.security)

반면 기준 시각에 조회한 Cursor changelog 메인·두 번째 페이지와 공식 보안 권고 목록에서는 이 EMBRACE 흐름에 해당하는 수정 버전·GHSA·보안 문구가 확인되지 않았다. ‘공식 확인 안 됨’은 ‘패치되지 않았음’의 증명도 아니다. 현재 확인한 범위에서는 연구자의 수정 주장까지 알 수 있다는 뜻이다.

Cursor 3.23이 EMBRACE 수정 버전이라는 근거도 확인되지 않았다. 공식 Run Modes 문서의 2026년 10월 1일 기록은 Read access의 Workspace 모드 추가다. 날짜가 겹친다는 이유만으로 내장 브라우저 공격 수정과 연결할 근거는 없다. (cursor.com)

업데이트는 어디서 확인해야 하나?

공식 안내에 따라 최신 버전을 설치하되, 지원 버전 정책을 EMBRACE 수정 공지로 읽지 않는 것이 맞다. 커맨드 팔레트의 Attempt Update를 실행하고 안내에 따라 재시작할 수 있다. 또는 공식 다운로드에서 최신 설치 파일을 받아 기존 설치 위에 설치한다. 공식 문서는 설정과 채팅 기록이 유지된다고 안내한다. (cursor.com)

자동 업데이트도 확인할 필요가 있다. Cmd/Ctrl+Shift+P → Preferences: Open Settings (UI) → update.mode 검색으로 살펴본다. none이면 앱 안 업데이트가 작동하지 않아 설치 파일을 받아야 하고, manual이면 사용자가 업데이트를 확인해야 한다. 조직의 UpdateMode 정책은 개인 설정보다 우선할 수 있다. (cursor.com)

공식 문서의 10월 26일 기준 최소 지원 버전은 3.18, 최소 허용 버전은 3.6이다. 이는 경고와 에이전트 요청 제한을 정하는 운영 기준이지 EMBRACE 수정 버전이 아니다. 최신 업데이트는 필요한 기본 조치지만, 그것만으로 완전 방어가 된다고 단정할 수는 없다. (cursor.com)

브라우저 승인과 실행 모드는 무엇을 점검해야 하나?

브라우저는 수동 승인을 유지하고, 에이전트 전체 실행 권한도 따로 확인해야 한다. Browser의 Agent Settings에서는 Manual approval이 공식 권장이다. 브라우저 동작을 검토한 뒤 승인하는 방식이며, Auto-run은 사용하지 않는 쪽으로 점검한다. 공식 문서는 Auto-run을 승인 없이 모든 브라우저 동작을 실행하는 모드로 설명하며 주의를 요구한다. (cursor.com)

Cursor Settings > Agents > Auto-Run에서는 자동 승인 허용목록과 차단목록을 검토한다. 편의를 위해 넣었던 항목이 지금도 필요한지 확인할 부분이다. 공식 문서도 이 목록을 완전한 방어가 아닌 보조 수단으로 설명한다. 목록에 등록됐다는 사실이 완전한 보안 경계를 만들어 주지는 않는다. (cursor.com)

Settings > Agents > Approvals & Execution에서는 Run Everything을 피하고 Auto-review를 검토한다. 공식 설명상 Run Everything은 모든 도구 호출을 자동 실행하며 샌드박스와 classifier를 사용하지 않는다. Auto-review는 허용목록, 가능한 셸 명령의 샌드박스 실행, 나머지 호출의 classifier 검토를 조합한다. 모든 요청을 수동 승인하는 모드는 아니다. (cursor.com)

자동 검토를 맡는 classifier(분류 모델) 역시 완전한 보안 경계가 아니다. 공식 문서는 샌드박스 제한으로 실패한 명령을 밖에서 다시 실행할 수 있으며, 그 재실행을 classifier가 검토한다고 설명한다. 이 문서상의 경로와 Forever 시연에서 관찰된 샌드박스 해제가 같은 메커니즘이라고 확인된 것은 아니다. 둘을 섞어 ‘classifier가 EMBRACE를 막는다’거나 ‘같은 방식으로 뚫렸다’고 결론 내리면 안 된다. (cursor.com)

미신뢰 저장소를 다룬다면 Workspace trust도 선택적으로 검토할 수 있다. Cursor 공식 Agent Security의 Workspace trust 항목에 따르면 기본은 꺼져 있으며, Restricted mode에서는 AI 기능이 제한되거나 정상적으로 작동하지 않는다. 공식 권고는 미신뢰 저장소에는 기본 텍스트 에디터를 사용하라는 것이다. 이 설정만 켜면 EMBRACE가 해결된다는 뜻은 아니다. (cursor.com)

다른 네 제품도 같은 조치를 하면 되나?

아니다. 영향 유형도 다르고, 연구자 패치 주장과 공식 확인 수준도 다르다. 아래 공식 확인 결과는 2026년 10월 30일 15:34 KST 기준 대조 자료를 반영했다. ‘공개 당시 미패치’와 ‘현재 공식 수정 근거를 찾지 못함’은 구분해 읽어야 한다.

Copilot의 연구 출처는 Forever이고, 공식 대조 출처는 github/app changelog와 보안 권고 목록이다. 이 범위를 모든 IDE용 Copilot 확장으로 넓혀서는 안 된다.

Claude 수정 버전의 출처는 Noma이며, Anthropic이 같은 수정 내용을 공식 발표한 버전처럼 바꿔 적지 않는다. Forever의 글에는 Claude의 수정 버전·날짜가 따로 제시되지 않는다. 공식 대조 범위는 Anthropic 릴리스 노트와 anthropics/claude-code 보안 권고 목록이다. 이 목록이 Desktop 공지 전체를 포괄한다고 보장할 수는 없다. (forever.security)

공식 대조에는 Codex 보안 권고 목록과 VS Code 보안 권고 목록을 사용했다. Codex CLI 릴리스나 다른 취약점의 GHSA를 데스크톱 브라우저 수정 근거로 대신 쓸 수도 없다.

VS Code의 Restricted Mode는 공식 일반 보호 기능이지 EMBRACE 해결을 보장하는 조치가 아니다. Forever는 Microsoft가 Workspace Trust 경계라는 이유로 수정을 거절했다고 서술한다. 연구자의 비판과 벤더의 일반 보호 설명은 나눠 봐야 한다. (forever.security)

결국 지금 판단할 기준은 무엇인가?

최신 버전인지와 외부 콘텐츠에 어떤 실행 권한을 넘겼는지를 함께 보는 것이다. Cursor에서는 업데이트, 브라우저 Manual approval, 자동 승인 허용목록, Run Everything 사용 여부부터 확인할 수 있다. 모두 공식 문서에 근거한 점검이지만 어느 하나도 완전 방어 보증서는 아니다. (cursor.com)

내장 브라우저가 편리하다는 이유로 그 안에서 넘어온 요청까지 신뢰할 필요는 없다. 에이전트가 가져온 요청이라도 무엇을 왜 실행하는지 읽을 수 있어야 한다. 패치 상태는 이 글의 기준 시각에 묶인 정보다. 실제 공개 직전에는 각 벤더의 공식 패치 현황을 다시 확인해야 한다.