개념 증명(Proof of Concept)은 이름이 바뀐 계산기입니다

보안 기업 Mindgard는 2025년 12월에 이 사실을 보고했습니다: 저장소(repository)의 루트 디렉토리에 git.exe라는 이름의 바이너리를 떨어뜨리고, 개발자가 Cursor에서 해당 저장소를 열게 하면, Cursor가 이를 실행합니다. "실행할지 물어볼 수도 있습니다"가 아닙니다. 실행합니다. 즉시 실행합니다. Cursor가 Git을 위해 셸(shell)을 호출할 때마다 반복적으로 실행됩니다.

그들의 개념 증명(Proof of Concept)은 심지어 교묘하지도 않았습니다 — 그들은 calc.exe의 이름을 git.exe로 바꿨습니다. 저장소를 열면 계산기 창이 스스로 팝업되기 시작합니다.

4:25:12.6209706 PM Cursor.exe 54880 Process Create
c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe SUCCESS
Command line: git rev-parse --show-toplevel

그게 전부입니다. 그것이 공격(exploit)의 전부입니다. Cursor는 Windows의 여러 위치에서 Git 바이너리를 검색하는데, 여기에는 워크스페이스(workspace) 디렉토리 자체도 포함됩니다. 만약 당신의 악성 git.exe가 그곳에 있다면, Cursor는 실제 Git을 찾기 전에 그것을 찾아냅니다. 샌드박스(sandbox) 확인도 없습니다. 서명(signature) 확인도 없습니다. "이 바이너리는 신뢰할 수 없습니다"라는 대화 상자도 없습니다. Mindgard가 표현했듯이: "클릭, 프롬프트, 승인 대화 상자 또는 경고가 전혀 없습니다. 결과는 임의 코드 실행(Arbitrary Code Execution)입니다."

이것이 실제 상황에서 무엇을 의미하는지 생각해 보십시오. 낯선 사람이 보내는 "여기 저장소가 있는데, 한번 봐줄 수 있나요?"라는 모든 메시지, 모든 CTF, 모든 과제, 당신이 무심코 git clone하여 여는 모든 오픈 소스 기여 — 이 모든 것이 공격자가 Cursor가 바이너리를 해결(resolve)하는 방식에 관한 블로그 포스트 하나를 읽는 수고만 들인다면 잠재적인 RCE(Remote Code Execution)가 됩니다.

타임라인이 진짜 이야기입니다

취약점 자체는 심각합니다. Cursor의 대응은 더 심각합니다:

• 2025년 12월 15일 — security-reports@cursor.com으로 보고됨
• 2026년 1월 15일 — 한 달간의 침묵, 그 후 HackerOne 자동화 시스템이 고장 나면서 Cursor의 CISO가 연구자를 버그 바운티 (Bounty) 프로그램에 수동으로 초대함
• 2026년 1월 16일 — 보고서가 "정보 제공용 및 범위 외 (Informative and out of scope)"로 종료되었다가 다시 재개됨
• 2026년 1월 20일 — 다시 한번, 보고서가 전달되었음을 확인받음
• 2026년 2월~6월 — 5개월 동안 업데이트 요청을 보냈으나, 아무런 응답이 없음
• 2026년 4월 30일 — 197번의 업데이트가 출시된 후에도, 연구자들은 버전 3.2.16에서 해당 버그가 여전히 작동함을 확인함
• 2026년 7월 14일 — 전체 공개 (Full public disclosure) 진행. 협력적 공개 (Coordinated disclosure)가 몇 달 전 이미 일방통행이 되어버렸기 때문임

197개의 버전이 출시되는 동안 git-binary-hijack 경로는 전혀 수정되지 않았습니다. 이것은 단순한 실수(Oversight)가 아니라, 이 회사가 이러한 유형의 버그를 감시하는 인력이 전혀 없음을 의미합니다. 여기서의 전체 공개는 공격적인 조치가 아니었습니다. 임의 코드 실행 (Arbitrary code execution) 취약점에 대해 벤더가 반년 동안 응답을 끊어버린 상황에서 남은 마지막 수단이었습니다.

이것은 Cursor의 문제가 아니라, 에이전트 (Agent)의 문제입니다

만약 이것이 단 하나의 제품에서 발생한 단 하나의 버그였다면, 괜찮습니다. 패치를 배포하고 넘어가면 됩니다. 하지만 그렇지 않습니다. 2026년에 발생한 다른 사례들을 보십시오:

• CVE-2026-26268 — AI 코딩 에이전트가 조작된 Git hooks를 통해 클론된 저장소(Repo)에 접근하는 즉시 익스플로잇 (Exploit)을 실행함
• DuneSlide (CVE-2026-50548 / CVE-2026-50549, CVSS 9.8) — Cursor의 샌드박스 (Sandbox)를 완전히 탈출하여 호스트 OS에서 실행되는 제로 클릭 프롬프트 인젝션 (Zero-click prompt injection)
• GhostApproval — 6개의 서로 다른 AI 코딩 어시스턴트 전반에서 나타나는 동일한 실패 모드. 인간 참여형 승인 (Human-in-the-loop approval) 과정을 우회하여, 에이전트가 사용자가 실제로 승인하지 않은 명령을 실행함

이것은 여러 벤더에 걸쳐 동일한 12개월 동안 발생한 네 가지의 뚜렷하고 심각한 취약점 클래스이며, 모두 동일한 설계 결함에 뿌리를 두고 있습니다: 이 도구들은 LLM에 셸 명령 (Shell commands)을 실행할 수 있는 권한을 부여하면서, 저장소의 콘텐츠가 무엇이 안전한지를 알려줄 것이라고 신뢰한다는 점입니다.

Git은 명령어를 실행하는 사람이 자신이 무엇을 실행하고 있는지 이해하고 있다는 가정하에 설계되었습니다. AI 코딩 에이전트(AI coding agents)는 그 가정을 버렸습니다. 이제 그 "사람"은 적대적인지 알지 못하는 저장소의 파일을 읽고, 사용자의 권한을 사용하여 사용자의 기기에서 어떤 명령어를 실행할지 사용자를 대신해 결정하는 모델입니다. .git/hooks/post-checkout 스크립트나 git.exe라는 이름의 바이너리는 해당 모델에게 이상한 예외 사례가 아닙니다. 그것은 단지 읽고, 그리고 분명히 실행해야 할 또 다른 파일일 뿐입니다.

이 분야의 모든 벤더(vendor)들은 더 많은 자율성(autonomy)—명령어 자동 실행, diff 자동 적용, 머지 충돌(merge conflicts) 자동 해결—을 제공하기 위해 경쟁하고 있습니다. 하지만 입력값이 신뢰할 수 없는 git 저장소일 때 그 "자율성"이 무엇을 의미하는지 감사(audit)하려는 속도보다 훨씬 빠르게 말입니다. 이제 에이전트가 공격 표면(attack surface)이며, 대부분의 기업은 보안 보고서를 마치 고객 지원 티켓(support tickets)처럼 취급하고 있습니다.

이에 대해 실제로 취해야 할 조치

"단순한 저장소"가 비활성 상태라고 가정하는 것을 멈추십시오. 만약 Cursor, Copilot workspaces, Claude Code, Windsurf 또는 체크아웃된 코드에 대해 에이전트가 셸 명령어(shell commands)를 실행할 수 있게 하는 다른 도구를 사용한다면 다음을 준수하십시오:

• 에이전트 모드(agent-mode)가 활성화된 상태에서 알 수 없거나 신뢰도가 낮은 저장소를 절대 열지 마십시오. 먼저 읽기 전용(read-only)으로 검토하고, 그 다음에 에이전트를 사용하십시오.
• 특히 Windows의 경우, AppLocker 또는 Windows App Control을 사용하여 워크스페이스 디렉토리로부터의 실행을 차단하십시오. IDE가 대신 해줄 것이라고 믿지 마십시오. IDE는 그렇게 하지 않을 것입니다.
• 신뢰할 수 없는 저장소인가요? 그렇다면 일회용 환경을 사용하십시오. Windows Sandbox, 일회용 VM(가상 머신), 또는 비밀 정보(secrets)가 마운트되지 않은 컨테이너를 사용하십시오. SSH 키와 클라우드 자격 증명(credentials)이 그대로 놓여 있는 여러분의 데일리 드라이버(daily-driver) 기기를 사용하지 마십시오.
• 공격적으로 업데이트하되, 업데이트를 보안 경계(security boundary)로 신뢰하지 마십시오. 이 버그가 살아있는 상태로 197개의 릴리스(releases)가 배포되었습니다. 버전 업그레이드가 곧 패치 확인은 아닙니다.
• 에이전트 도구를 직접 만든다면, 바이너리 결정 순서(binary resolution order)와 명령어 실행 경로(command execution paths)는 인증 코드(auth code)와 동일한 수준의 정밀한 검토가 필요합니다. "LLM이 실행하기로 결정했다"는 것은 보안 모델이 아닙니다.

이러한 도구들의 홍보 방식은 그것들이 매우 빠르고 유능한 팀원처럼 행동한다는 것입니다. 아직 완전히 신뢰할 수 없는 팀원처럼 대하기 시작하십시오. 최소 권한 (least privilege) 원칙을 적용하고, 민감한 저장소 (repos)에 대한 감독 없는 접근을 허용하지 마십시오. 그리고 벤더 (vendor)가 명백한 문제들을 잡아냈을 것이라고 맹목적인 믿음을 가져서는 안 됩니다. 현재 여러 도구들이 그러한 문제들을 잡아내지 못하고 있습니다.