커서(Cursor) 취약점 2건, 지금 뭘 확인해야 할까요?
이번 주(8월 14일~18일) 커서(Cursor)를 둘러싸고 보안 이슈가 두 건 겹쳤습니다. 중국 Z.ai가 8월 14일 출시한 코딩 특화 모델 GLM-5.3이 커서 코드에서 새 결함을 찾아냈다는 소식과, 작년 12월 신고돼 7개월 만인 지난달에야 공개된 CVSS 8.7짜리 CVE-2026-63093이 그것입니다. 둘 다 저장소 폴더를 열기만 해도 코드가 실행될 수 있는 유형이라, 바이브코딩으로 커서를 쓰는 분이라면 지금 확인해두시는 게 좋아요.
이번 주 무슨 일이 있었나 — GLM-5.3이 커서에서 찾아낸 새 결함
Z.ai는 8월 14일 코딩·사이버보안에 특화한 모델 GLM-5.3을 출시했습니다. 이 회사는 원래 취약점 탐색 성능으로 이름이 알려진 곳인데요, 이번 모델은 취약점 탐색 벤치마크 CyberGym에서 84.5%를 기록해 Mythos 5(83.8%)와 GPT-5.6 Sol(83.6%)을 근소하게 앞섰습니다. 더 눈에 띄는 건 ExploitBench 점수로, 54.4%를 찍어 전작 GLM-5.2(약 27%)의 딱 두 배 수준으로 뛰었더라고요.
보안 연구자 Joshua Saxe는 이 모델을 테스트하다가 커서의 Electron+Rust 코드베이스에서 ‘잠재적으로 심각한’ 아키텍처 취약점을 발견했다고 알렸습니다. 임의 파일 쓰기(arbitrary file write)로 이어질 수 있는 결함이라는데요, Z.ai는 이를 공개하지 않고 비공개로 커서 측에 신고했다고 하네요. 아직 CVE 번호는 부여되지 않았고, 커서는 현재 수정 작업 중입니다.
Z.ai 계열 모델이 취약점을 찾아낸 게 이번이 처음은 아닙니다. GLM-5.2 이후로 오픈소스 프로젝트 269개에서 취약점 2,436건을 찾아냈고, 이 중 1,097건이 심각(critical) 또는 높음(high) 등급이었고요. 커널·브라우저 엔진·네트워크 프로토콜까지 걸쳐 있고, 가장 오래된 버그는 1981년까지 거슬러 올라갑니다. 출시 시점 기준 CVE 53건이 공개됐고 나머지 2,383건은 아직 엠바고 상태고요.
7개월 전 신고, 이제야 공개된 CVE-2026-63093 (CVSS 8.7)
이번 주 소식과 별개로, 커서에는 이미 알려진 심각한 취약점이 하나 더 있습니다. CVSS 8.7점짜리 CVE-2026-63093인데요, 방식은 ‘바이너리 플랜팅(binary planting)’입니다. 저장소 루트에 악성 git.exe 하나만 심어두면, 윈도우의 실행파일 검색 순서상 커서가 이 가짜 파일을 정식 git 대신 실행해버리거든요. pyproject.toml 파일이 있는 저장소라면 hatch.exe도 똑같은 방식으로 노려집니다.
조건이 이렇게 없는 취약점도 드뭅니다.
프롬프트 주입도, AI 모델과의 상호작용도, 사전 접근 권한도 전혀 필요 없습니다. 피해자가 할 일은 그냥 악성 저장소 폴더를 커서로 여는 것뿐이거든요. 보안업체 Mindgard가 2025년 12월 15일 이 문제를 커서에 신고했는데, 실제 공개는 2026년 7월 14일에야 이뤄졌습니다. 신고부터 공개까지 딱 7개월이 걸린 셈입니다.
보도에 따르면 커서는 공개 하루 전인 7월 13일 패치됐다고 알려졌지만, 신고자인 Mindgard 측 자체 검증에서는 이 패치 여부가 별도로 확인되지 않았습니다. 공식 보안 권고(advisory)도 따로 나오지 않았고요. 그래서 이 취약점을 정확히 아는 사용자가 생각보다 많지 않습니다 — 저도 이번에 자료를 찾아보다가 처음 알았어요.
두 취약점 한눈에 비교
두 사건을 나란히 놓고 보면 대비가 뚜렷합니다. 하나는 신고부터 공개까지 7개월이 걸린 ‘이미 끝난’ 사건이고, 다른 하나는 이번 주 막 알려진 ‘진행 중’인 사건이거든요. 표 하나로 나란히 놓아봤습니다.
| 구분 | 발견일 | 공개일 | CVSS | 공격 방식 | 패치 상태 |
|---|---|---|---|---|---|
| CVE-2026-63093 | 2025-12-15(Mindgard 신고) | 2026-07-14 | 8.7 | 악성 git.exe·hatch.exe 바이너리 플랜팅 | 패치 보도 있음(Mindgard 미확인·공식 권고 없음) |
| GLM-5.3 발견 결함(CVE 미부여) | 2026-08월 둘째 주(Joshua Saxe) | 비공개(엠바고 중) | 미부여 | Electron+Rust 아키텍처 결함 → 임의 파일 쓰기 | 수정 작업 중 |
표만 봐도 두 취약점의 성격이 다르다는 게 보이실 텐데요. 기존 CVE는 패치됐다는 보도는 있지만 신고자 측 확인도 공식 권고도 없는 애매한 상태고, 새 결함은 아직 패치 전인 ‘현재진행형 위험’이라는 게 문제입니다. 결과적으로 지금 커서를 쓰는 사람은 두 위험을 동시에 신경 써야 하는 상황인 거죠.
커서 기본 설정이 위험한 이유 — 꺼져 있는 Workspace Trust
CVE-2026-63093 같은 공격이 먹히는 배경에는 커서의 기본 설정이 있습니다. 커서는 기본값에서 Workspace Trust(작업공간 신뢰 확인) 기능이 꺼져 있습니다. 낯선 폴더를 열 때 “이 폴더를 신뢰하시겠습니까”라고 묻는 절차 자체가 없다는 뜻이에요. VS Code는 이 기능이 기본으로 켜져 있어 낯선 폴더를 열면 최소한 확인 창을 거치는데, 커서는 그 문턱이 아예 없는 셈이죠.
아 근데 생각해보니, 이 기능 자체를 몰랐던 분도 꽤 많으실 것 같아요. 저도 이번 기사를 쓰면서 제 커서 설정을 열어봤는데, 역시나 Workspace Trust가 꺼진 채였습니다. 평소에 딱히 의식하고 쓰던 기능이 아니다 보니 확인할 생각도 못 했더라고요. 게다가 커서·윈드서프 같은 AI 코딩 에디터는 구형 Electron 빌드를 쓰고 있어서, 아직 패치되지 않은 Chromium 취약점 수십 개에도 함께 노출돼 있다는 지적까지 나온 상태입니다.
지금 5분 안에 확인할 체크리스트 5가지
취약점 자체를 개인이 막을 방법은 없습니다. 다만 노출 폭을 줄이는 데는 5분이면 돼요. 아래 다섯 가지만 확인하셔도 오늘 다룬 위험의 상당 부분을 피할 수 있습니다.
- Workspace Trust 켜기 — 설정에서 활성화해 낯선 폴더를 열 때 확인 절차를 거치게 만드세요.
- 커서 버전 확인 — 최신 버전으로 업데이트하고, 공식 릴리스 노트에서 CVE-2026-63093 관련 수정 여부를 직접 확인하세요.
- 낯선 저장소 열기 전 루트 폴더 확인 — 특히 윈도우에서는 git.exe·hatch.exe가 저장소 루트에 딸려 있지 않은지 열기 전에 살펴보세요.
- MCP 서버 연결은 stdio 방식으로 — 원격 URL 연결 대신 로컬 프로세스(stdio) 방식으로 붙여두면 노출 경로가 줄어듭니다.
- 업데이트 로그 구독 — GLM-5.3이 찾은 결함은 아직 패치 전입니다. 공식 업데이트 로그를 구독해 패치 소식을 놓치지 마세요.
다섯 개 다 하는 데 정말 5분이면 충분해요. 특히 1번과 2번은 설정 화면 딱 두 번 클릭이면 끝나거든요.
진짜 별거 없습니다.
다른 AI 코딩 에디터는 안전한가 — 윈드서프도 같은 구형 Electron
커서만의 문제냐고 물으신다면, 아닙니다. 윈드서프 역시 커서와 마찬가지로 구형 Electron 빌드를 쓰고 있어서 아직 패치되지 않은 Chromium 취약점 수십 개에 함께 노출돼 있다는 지적이 나오거든요. 지난번 바이브코딩 Supabase RLS 체크리스트 글에서도 얘기했지만, AI 코딩 도구 전반이 ‘개발 속도’에 밀려 보안 업데이트 주기를 놓치는 경우가 흔합니다.
그렇다고 커서를 당장 지워야 한다는 얘기는 아닙니다. 다만 도구를 바꾸는 것보다 지금 켜져 있는 스위치 하나(Workspace Trust)를 켜는 게 훨씬 빠르고 확실한 대응이더라고요. 저라면 오늘 안에 Workspace Trust부터 켜두고, 조만간 나올 GLM-5.3 발견 건의 패치 소식을 업데이트 로그로 한 번 더 확인하는 쪽을 택하겠습니다.
