Cursor 제로데이: 완전 공개만이 남은 보호 수단이 된 이유

7 hours ago 3

Windows용 Cursor는 프로젝트를 열 때 작업공간 루트의 git.exe를 자동 실행해, 악성 바이너리가 포함된 저장소만 열어도 사용자 상호작용 없이 임의 코드가 실행될 수 있음
Git 경로 탐색 범위에 저장소 내부가 포함되며 경고나 승인 없이 파일을 실행할 뿐 아니라, 프로젝트가 열려 있는 동안 주기적으로 재실행함
Mindgard가 2025년 12월 15일 신고하고 HackerOne을 통해 재현·전달까지 마쳤지만, 6개월 이상과 197개 이상의 새 버전이 지난 뒤에도 최신 테스트 버전에 문제가 남아 있었음
관리형 Windows 환경은 AppLocker나 Windows App Control의 경로 기반 거부 규칙을 적용하고, 일반 사용자는 패치 전까지 신뢰할 수 없는 저장소를 VM이나 Windows Sandbox에서 열어야 함
조율된 공개 절차로 사용자 위험을 줄일 수 없다고 판단한 Mindgard는 전체 세부 정보를 공개했으며, AI 개발 도구를 선택할 때 공급사의 보안 대응과 소통 능력도 신뢰 기준으로 삼아야 함

저장소를 여는 것만으로 실행되는 git.exe

Cursor는 프로젝트를 불러올 때 여러 위치에서 Git 바이너리를 찾으며, 검색 대상에 현재 작업공간도 포함함
공격자가 저장소 루트에 악성 git.exe를 배치하면 Cursor가 경고나 승인 대화상자, 별도 클릭 없이 이를 자동 실행함
개발자가 해당 프로젝트를 여는 것만으로 공격이 시작되며, 프롬프트 인젝션이나 모델 조작, 탈옥, 메모리 손상, 복잡한 익스플로잇 체인은 필요하지 않음
실행된 코드는 현재 Cursor 사용자의 권한 범위에서 동작함

재현 과정과 반복 실행 기록

Mindgard는 안전한 개념증명을 위해 Windows Calculator를 git.exe로 이름을 바꿔 저장소 루트에 배치함
Cursor에서 저장소를 열자 Calculator가 실행됐고, 프로젝트를 계속 열어 두자 여러 창이 추가로 나타남
- 연구자가 여러 창을 수동으로 연 것이 아님
- 일회성 시작 동작이 아니라 정상 사용 중 작업공간의 실행 파일을 주기적으로 재실행한 결과임
실제 공격에서는 Calculator 대신 공격자가 제어하는 코드를 배치할 수 있음
Sysinternals Process Monitor 기록에는 Cursor.exe가 저장소 내부의 git.exe를 실행하면서 다음 명령을 전달한 내역이 남아 있음

git rev-parse --show-toplevel

마지막 검증은 2026년 4월 30일, Windows용 Cursor 3.2.16에서 이뤄짐

대규모 사용자 기반에 남아 있던 취약점

Cursor는 다음 규모로 사용되는 AI 지원 개발 환경임
- 활성 사용자 700만 명 이상
- 일일 사용자 100만 명 이상
- 유료 사용자 100만 명 이상
- 사용 기업 5만 곳 이상
보고된 시장가치는 600억 달러임
Mindgard는 2025년 12월 15일 취약점을 발견하고 같은 날 신고함
서두 기준으로 6개월 이상과 197개 이상의 새 버전이 지난 뒤에도 최신 테스트 버전에 취약점이 남아 있었음
대응 경과를 다룬 본문에는 기능 추가와 발표가 이어지는 동안 70개 이상의 버전이 출시됐지만 문제가 유지됐다고 기록돼 있음
단순하고 재현하기 쉬운 임의 코드 실행 취약점이 수개월간 해결되지 않아 Cursor를 배포한 개인과 조직 모두가 영향을 받음

패치 전 적용할 수 있는 임시 대응

관리형 Windows 시스템에서는 AppLocker나 Windows App Control 정책으로 개발 작업공간 디렉터리의 해당 실행 파일 이름을 차단할 수 있음
바이너리마다 해시가 달라질 수 있으므로 해시 기반 차단 목록보다 저장소·작업공간 루트로 범위를 제한한 경로 기반 거부 규칙이 적합함

%USERPROFILE%\source\repos\*\filename.exe

Windows에는 특정 부모 프로세스가 실행한 경우에만 임의의 자식 실행 파일을 차단하는 일반 내장 규칙이 없음
- 부모 프로세스를 인식하는 통제에는 EDR이나 맞춤형 엔드포인트 보안 제품이 필요함
일반 사용자는 IDE가 패치될 때까지 신뢰할 수 없는 저장소를 격리된 VM, Windows Sandbox 또는 폐기 가능한 환경에서만 열어야 함
바이너리를 바꿀 때마다 해시가 달라질 수 있으므로 이 취약점에는 파일 해시 차단 목록을 신뢰해서는 안 됨

신고 후 멈춰 버린 조율 절차

최초 신고는 Cursor의 security.txt에 지정된 보안 신고 이메일로 전달됐지만 수신 확인이 오지 않음
Mindgard는 후속 이메일과 공개 연락 요청을 통해 적절한 보안 담당자를 찾으려 함
Cursor CISO는 내부 자동화 실패로 예정된 HackerOne 절차가 시작되지 않았다고 답하고, Mindgard를 비공개 버그 바운티 프로그램에 수동으로 초대함
HackerOne에 다시 제출한 보고서는 처음에 Informative 및 범위 밖으로 종료됨
- Mindgard가 해당 판정에 이의를 제기함
- HackerOne이 문제를 재현한 뒤 보고서를 다시 열고, 세부 정보가 Cursor에 전달됐음을 확인함
이후 업데이트 요청과 HackerOne을 통한 에스컬레이션, Cursor CISO 및 경영진을 향한 직접 연락에도 의미 있는 답변이 없었음
Mindgard는 수정이 시작됐거나 엔지니어링 팀이 조사 중이거나, 영향받은 사용자에게 위험이 전달됐다는 증거를 받지 못함

신고부터 전체 공개까지의 일정

2025년 12월 15일
- Mindgard가 취약점을 발견함
- security-reports@cursor.com으로 신고함
2025년 12월 18일
- 수신 확인을 요청하는 후속 연락을 보냄
2026년 1월 13일
- Cursor 연락 담당자를 찾기 위해 LinkedIn 게시물을 올림
- 댓글에서 한 사용자가 Cursor CISO를 지목함
2026년 1월 15일
- Cursor CISO가 HackerOne 비공개 바운티 초대 자동화 실패를 알리고 수동으로 초대함
- Mindgard가 HackerOne을 통해 취약점을 제출함
2026년 1월 16일
- 보고서가 Informative 및 범위 밖으로 종료됨
- Mindgard가 판정에 이의를 제기함
- 재현 성공 후 보고서가 다시 열림
2026년 1월 20일
- HackerOne이 Cursor에 보고서를 전달했다고 확인함
2026년 2월 16일, 3월 3일
- Mindgard가 업데이트를 요청했지만 응답을 받지 못함
2026년 3월 17일
- Cursor CISO에게 직접 업데이트를 요청함
2026년 3월 18일
- HackerOne이 Cursor에 연락했다고 알림
2026년 4월 1일
- Mindgard가 다시 업데이트를 요청했지만 응답을 받지 못함
- HackerOne도 Cursor로부터 업데이트가 없다고 확인함
2026년 6월 1일
- Mindgard가 공개 의사를 HackerOne에 알림
2026년 6월 3일
- HackerOne이 공개 지침을 제공함
2026년 7월 14일
- 취약점 세부 정보를 담은 게시물을 공개함

조율된 공개가 사용자 보호로 이어지지 않은 이유

일반적인 조율 공개는 신고, 대화, 심각도 논의, 엔지니어링 조사, 수정 개발, 사용자 보호, 공개 순으로 진행됨
이 절차는 모든 참여자가 위험 감소라는 목표를 공유할 때 작동함
이번 사례에서는 7개월 동안 공급사의 의미 있는 참여가 없어 위험 감소 단계까지 나아가지 못함
대규모로 빠르게 변화하는 플랫폼은 수정에 시간이 걸릴 수 있지만, 수개월간 소통이나 업데이트, 가시적 진전이 없는 상황에서는 계속 기다리기 어려움
연구자에게는 두 가지 선택지만 남았음
- 침묵을 유지해 사용자가 안전하다는 잘못된 전제 아래 계속 작업하도록 둠
- 공개를 통해 조직이 위험을 파악하고 대응 여부를 판단할 수 있도록 함
Mindgard는 다른 모든 경로가 실패했을 때 사용하는 완전 공개를 선택함

버그 바운티와 AI 보안 대응 체계가 남긴 질문

해결이 지연된 원인을 두고 다음 가능성을 질문함
- 현대의 버그 바운티 프로그램이 과부하 상태인지
- Mythos처럼 역량이 높아진 모델 때문에 신고량을 감당하기 어려워졌는지
- Cursor가 SpaceX 인수에 집중하면서 사용자 안전의 우선순위를 낮췄는지
- 수십억 달러가 걸린 상황에서 사용자 안전이 실제 관심사인지
AI 제품 확산으로 보안 발견 건수가 크게 늘고 있으며, 상당수는 기존 취약점 분류에 깔끔하게 들어맞지 않음
약 20년간 의존해 온 분류·접수 절차는 AI 환경에서 기반 가정이 흔들리면서 빠르게 실패하고 있음
공개 파이프라인이 과부하 상태라면 업계가 이를 투명하게 알려 연구자와 고객, 사용자가 상황을 판단할 수 있어야 함
급성장하는 기업은 보안 실패를 해결하는 동시에 사용자를 구매 실험 대상이 아닌 가치 있는 고객으로 대해야 함

AI 개발 도구를 신뢰하기 위한 조건

AI 기업은 코드와 저장소, 터미널, 비밀정보, 작업 흐름에 전례 없이 넓은 접근 권한을 요구하며 제안과 실행의 경계도 점차 흐려지고 있음
사용자는 프로덕션 소프트웨어에 소스 코드와 자격증명, 독점 지식재산, 점점 자율화되는 기능을 맡기고 있음
생산성을 높인다는 이유만으로 시스템을 신뢰해서는 안 되며, 보안 신고 대응과 영향받은 사용자와의 소통, 수정 우선순위를 통해 신뢰를 얻어야 함
신뢰에는 책임이 필요하고 책임에는 소통이 필요하지만, 사용자와 연구자, 공개 플랫폼이 수개월간 기본적인 상태 업데이트조차 받지 못하면 그 책임을 확인하기 어려움
Mindgard는 조직이 노출 범위를 평가하고 보완 통제를 적용하며 보안 상태를 판단할 기회를 주기 위해 전체 세부 정보를 공개함
정보를 계속 숨기는 것이 사용자가 아니라 침묵만 보호하는 단계에 이르면, 불편하더라도 사용자 안전을 우선해야 함

Read Entire Article