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

 (mindgard.ai)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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는 조직이 노출 범위를 평가하고 보완 통제를 적용하며 보안 상태를 판단할 기회를 주기 위해 전체 세부 정보를 공개함
  • 정보를 계속 숨기는 것이 사용자가 아니라 침묵만 보호하는 단계에 이르면, 불편하더라도 사용자 안전을 우선해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 보안 보고서를 받는 입장에서 LLM이 생성한 저품질 보고서가 감당하기 어려울 만큼 쏟아지며, 대개 제품 설계나 보안 범위를 이해하지 못한 내용임. 간혹 매우 좋은 보고서도 있어 모두 직접 확인해야 하지만, LLM이 만든 장황한 “근거”를 더 보내는 방식은 해결책이 아니며 이 글도 대부분 LLM으로 작성된 듯함
    이번 건도 소프트웨어가 임의 코드나 바이너리를 실행할 수 있는 환경에 악성 바이너리를 놓은 경우라면, Cursor가 사용자 환경의 보안까지 책임지겠다고 하지 않는 한 작업 공간을 격리하고 보호하는 쪽의 책임에 가까워 보임
    LLM으로 CVE 보고서를 만들 때는 결정적으로 재현하는 과정에 활용하고, 본문은 직접 간결하게 작성하면서 LLM 특유의 불필요한 형용사와 과장을 걷어내길 바람

    • 새로 복제한 저장소를 Cursor로 열었다는 이유만으로 그 안의 바이너리가 자동 실행되어서는 안 됨
    • PATH 변수는 바로 이런 문제를 통제하려고 존재함. 이해한 내용이 맞다면 Cursor는 사용자 승인 없이 저장소를 PATH에 즉시 추가함
    • 쉬운 해결책은 없으며, 보안을 중시한다면 변화한 환경에 맞춰 검토 인력을 더 투입해야 함. LLM 검사를 한 단계 더 얹는다고 해결되지는 않음

  • 문제의 뿌리는 Cursor가 저장소 복제와 코드 실행을 서로 다른 보안 경계로 보지 않는 데 있음. Cursor는 기본적으로 Workspace Trust를 비활성화하며[0], .vscode/tasks.json에 "runOn": "folderOpen"이 들어간 저장소만 열어도 이미 임의 코드가 실행됨[1]
    [0] https://cursor.com/docs/agent/security#workspace-trust
    [1] https://www.oasis.security/blog/cursor-security-flaw

  • Mindgard는 2025년 12월 15일 취약점을 처음 발견해 당일과 이후 여러 차례 신고했지만, 6개월과 197개 이상의 새 버전이 지난 뒤에도 최신 Cursor에 남아 있다고 함
    처음에는 정보성·범위 외 보고서로 종결됐고, 이의 제기 후 HackerOne이 다시 열어 재현한 뒤 Cursor에 전달했으나 이후 업데이트 요청, 추가 문의, HackerOne을 통한 상향 조정, Cursor 경영진에게 보낸 연락까지 모두 답이 없었다니 Cursor가 이렇게 대응하지 않는 이유를 이해하기 어려움

    • CVE 처리 절차 자체가 망가졌음. 에이전트형 AI의 발전으로 HackerOne과 기업 취약점 공개 프로그램에는 저품질 보고서와 실제로 뛰어난 보고서가 동시에 급증했고, 같은 AI가 둘 다 작성하니 표면만 보고 구분하기가 거의 불가능함
      그 결과 기업들은 예전처럼 응답하지 않으며, 6월 사이버 보안 콘퍼런스에서도 책임 있는 공개는 죽었거나 죽어가고 있으므로 공개적으로 밝히는 편이 낫다는 분위기가 강했음. Microsoft와 Nightmare Eclipse 사건이 자주 인용됐음
    • 의도적인 백도어일 가능성도 떠오름. NSA나 FBI가 표적용 저장소에 git.exe를 넣고 표적이 복제하도록 하면 페이로드가 실행될 수 있음
      Cursor가 VS Code 기반인 만큼 VS Code에서도 같은 일이 일어나는지 궁금함

  • 이것이 중대한 취약점이라는 데 완전히 동의하기는 어려움. 실제로 악용하려면 공격자가 사용자 코드 폴더에 git.exe라는 악성 실행 파일을 먼저 넣어야 하며, 이는 .bashrc를 바꿔 ls가 /tmp/mega-big-virus.sh를 실행하도록 별칭을 만드는 일을 취약점이라고 부르는 것과 비슷함
    공격 경로인 건 맞지만 그런 파일이 이미 파일 시스템에 들어갔다면 선행 침해가 일어난 상태로 볼 수 있음

    • GitHub 저장소를 복제해 기본 편집기인 Cursor로 여는 것만으로 감염될 수 있음. 이는 CD를 넣자 autorun.exe가 실행되어 Windows가 감염되는 것과 같음
      모든 저장소 파일과 git.exe 같은 의심스러운 바이너리를 사용자가 격리 환경에서 직접 검사해야 한다고 할 수도 있지만, 현실에서는 사용자가 아니라 자동 실행을 막는 보안 정책이 이를 통제하며 Cursor도 마찬가지로 비활성화해야 함
    • .bashrc와 달리 코드 폴더는 신뢰할 수 없는 출처에서 자주 가져옴. GitHub 프로젝트를 검토하려고 열었다는 이유로 임의 코드 실행까지 허용해서는 안 됨
      다만 주요 IDE에서는 이미 이런 경계가 무너진 지 오래됐고, VS Code의 SSH와 devcontainer 원격 기능도 설계상 원격 코드 실행을 허용함
    • 페이지 첫 문단부터 Cursor가 프로젝트를 연 뒤 현재 작업 공간을 포함한 여러 위치에서 Git 바이너리를 찾고, 저장소 루트에 악성 git.exe를 두면 사용자 입력이나 확인 없이 실행한다고 두 문장으로 명확히 밝힘. 핵심 동작을 숨긴 글은 아님
    • 저장소를 복제해 IDE로 열기만 해도 저장소 소유자에게 원격 코드 실행 권한을 주는 셈이며, 이는 폴더를 여는 행위에 암묵적으로 포함된 계약이라고 보기 어려움
    • 30년 전에도 MP3나 사진 폴더에 감염된 대체 DLL을 넣어 Winamp나 Windows 사진 뷰어가 불러오게 하는 DLL 검색 순서 공격이 있었으며, 이번 건과 매우 비슷함

  • Cursor가 확인 없이 임의의 실행 파일을 실행하는 것은 이상하고, 연구진이 수개월 동안 제대로 된 답변을 받지 못한 것도 우려됨
    다만 계산기 실행 예시는 다소 오해를 부를 수 있음. 악성 실행 파일이 시스템에 이미 다운로드돼 있어야 하고, Cursor가 실행을 시도하면 ACL이 작동해 서명되지 않은 새 앱을 처음 실행할지 권한을 물을 것으로 이해함. 실제 악용에는 ACL이 완전히 비활성화돼 있어야 할 수 있음

    • 확인창에 “git.exe를 실행하시겠습니까?”라고 나오면 Cursor가 Git을 필요로 하는데 권한 설정이 꼬였다고 생각해 그대로 승인할 가능성이 큼
    • 현재 Git 브랜치를 표시하는 PS1을 쓰면서 현재 디렉터리를 PATH에 포함한 경우에도 같은 일이 생길 수 있음. 그렇다면 Bash에도 고위험 CVE를 제출해야 하는지 의문임

  • Cursor만의 버그라기보다는 Windows가 PATH를 보기 전에 현재 작업 디렉터리에서 실행 파일을 찾는 Windows 특유의 검색 순서와 관련 있어 보임. Windows의 여러 프로그램이 비슷한 공격에 노출될 가능성이 큼

    • 보안을 신경 쓰는 소프트웨어는 이 문제를 이미 수정함
      https://go.dev/blog/path-security에서 설명하듯 Command와 LookPath는 운영체제 관례에 따라 현재 PATH에 나열된 디렉터리에서 프로그램을 찾지만, 현대에는 현재 디렉터리를 포함하는 동작이 대개 예상 밖이며 보안 문제로 이어짐
      https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
    • 알려진 시스템 경로에서 실제 Git 실행 파일을 찾거나 사용자가 경로를 설정하게 하면 쉽게 완화할 수 있으며, VS Code도 그런 방식으로 처리하는 것으로 알고 있음
    • Windows용 소프트웨어를 개발할 때 반드시 방어해야 하는 오래되고 잘 알려진 보안 함정임
    • 그렇다면 결국 Cursor의 Windows 버전에 버그이자 취약점이 있다는 뜻으로 들림

  • 기업이 보안을 우선하지 않는 일은 너무 흔하며 안타깝지만 이해할 만한 면도 있음. 보안 스타트업이 기다리다 지쳐 투입 비용의 일부라도 홍보 효과로 회수하려고 공개하는 것도 이해되며, 공개적 취약점 공개가 필요한 때도 있음
    다만 정말 해결을 돕고 싶었다면 HackerOne에서 재촉하고 CISO에게 LinkedIn 메시지를 한 번 보내는 것보다 더 할 수 있었을 듯함. 이제는 아무도 진심으로 신경 쓰지 않는 것처럼 보여 씁쓸함

    • 어떻게 해야 해결을 진심으로 돕는 것이며, 여기서 말하는 매몰 비용이 정확히 무엇인지 불분명함. 전체적으로 지나치게 모호하게 들림

  • Cursor가 왜 실행 파일을 자동으로 실행하는지, 어떤 의사 결정 흐름에서 이런 동작이 나왔는지 궁금함. Vim도 %{expr} 같은 명시적 기능 때문에 파일 로드 시 예상치 못한 코드를 실행한 문제가 있었지만, Cursor가 왜 하필 git.exe를 찾는지와 누구에게 도움이 되는 기능인지 이해하기 어려움
    간단히 수정할 수 있어 보이는 중복적 CVE가 왜 존재하는지 Cursor를 써본 적 없는 입장에서도 궁금해짐

    • 흔한 흐름은 Cursor에 기존 저장소를 요약해 README를 작성해 달라고 요청하고, Cursor가 저장소와 코드를 읽은 뒤 개발 브랜치나 이전 태그 같은 메타데이터까지 제공하려고 Git 명령을 실행하는 것임
      문제는 원격 저장소를 평가하도록 했을 때 저장소를 복제한 뒤 작업 디렉터리에서 git ...을 실행하면, Windows가 그 디렉터리에 있는 git 파일을 실행 대상으로 판단할 수 있다는 데 있음. 신뢰하지 않는 저장소나 침해된 브랜치로 전환할 때도 즉시 코드가 실행될 수 있음
      일반적인 해결책은 시스템에 설치된 Git의 완전한 경로를 사용하는 것이며, 사람이 입력하기에는 번거로워도 Cursor에는 사소한 작업임
    • 내장 에이전트가 여러 브랜치와 worktree에서 맥락을 읽도록 사용자의 실제 Git을 찾으려는 의도로 보임. 더 안전한 방법이 있지만, 이런 약간의 편법은 AI 보조 작업 흐름에서 잘못되기 쉽고 AI를 활용한 버그 분류에서도 경보가 누락되기 쉬운 지점임

  • 개발 에이전트에 Git 저장소를 가져오고 올릴 권한을 흔히 주는 만큼 이는 거대한 공급망 공격 경로가 됨. 실행 중인 Cursor 에이전트가 최신 파일을 가져왔는데 공격자가 프로젝트에 실행 파일을 심어 놓았다면, 갑자기 수십만 명이 기본 사용자 권한으로 임의의 EXE를 실행할 수 있음

  • 보고서가 다소 AI가 쓴 글처럼 읽힘. 악용하려면 복제나 다운로드 등을 통해 악성 페이로드가 이미 PC에 있어야 하므로 심각성은 이해하지만, 애초에 그런 상황에 놓이지 않기를 기대하게 됨

    • 현대의 코딩 에이전트는 문서가 불분명한 API를 질문받으면 저장소를 복제하고 코드를 읽기도 하므로, 이 취약점은 실제로 악용 가능함
    • 악성 페이로드는 원격 저장소에 있을 수 있음. 저장소를 git clone한 뒤 Cursor로 열기만 하면 침해가 완료됨
    • 오픈소스 개발자라면 git.exe가 포함된 풀 리퀘스트를 받을 수도 있음
    • 저장소를 다운로드해 소스를 보는 행위가 악성 페이로드 활성화와 같다고 보통은 생각하지 않으며, 바로 그 부분이 우려스러움. AI 문체가 거슬리더라도 작성 방식보다 취약점의 내용을 비판해야 함
    • 페이로드가 미리 PC에 있어야 한다고 단정하기 어려움. 프롬프트 주입으로 download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;) 같은 명령을 유도할 수 있다면, 에이전트가 git.exe를 다운로드해 실행할 가능성이 있음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.