• 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일

2026년 7월 14일

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

• 일반적인 조율 공개는 신고, 대화, 심각도 논의, 엔지니어링 조사, 수정 개발, 사용자 보호, 공개 순으로 진행됨

• 이 절차는 모든 참여자가
  위험 감소라는 목표를 공유할 때 작동함

• 이번 사례에서는 7개월 동안 공급사의 의미 있는 참여가 없어 위험 감소 단계까지 나아가지 못함

• 대규모로 빠르게 변화하는 플랫폼은 수정에 시간이 걸릴 수 있지만, 수개월간 소통이나 업데이트, 가시적 진전이 없는 상황에서는 계속 기다리기 어려움

• 연구자에게는 두 가지 선택지만 남았음

• 침묵을 유지해 사용자가 안전하다는 잘못된 전제 아래 계속 작업하도록 둠

• 공개를 통해 조직이 위험을 파악하고 대응 여부를 판단할 수 있도록 함

• Mindgard는 다른 모든 경로가 실패했을 때 사용하는
  완전 공개를 선택함

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

• 해결이 지연된 원인을 두고 다음 가능성을 질문함

• 현대의 버그 바운티 프로그램이 과부하 상태인지

• Mythos처럼 역량이 높아진 모델 때문에 신고량을 감당하기 어려워졌는지

• Cursor가 SpaceX 인수에 집중하면서 사용자 안전의 우선순위를 낮췄는지

• 수십억 달러가 걸린 상황에서 사용자 안전이 실제 관심사인지

• AI 제품 확산으로 보안 발견 건수가 크게 늘고 있으며, 상당수는 기존 취약점 분류에 깔끔하게 들어맞지 않음

• 약 20년간 의존해 온 분류·접수 절차는 AI 환경에서 기반 가정이 흔들리면서 빠르게 실패하고 있음

• 공개 파이프라인이 과부하 상태라면 업계가 이를 투명하게 알려 연구자와 고객, 사용자가 상황을 판단할 수 있어야 함

• 급성장하는 기업은 보안 실패를 해결하는 동시에 사용자를 구매 실험 대상이 아닌
  가치 있는 고객으로 대해야 함

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

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