# Cursor 제로데이: 완전 공개만이 남은 보호 수단이 된 이유 > Clean Markdown view of GeekNews topic #31461. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31461](https://news.hada.io/topic?id=31461) - GeekNews Markdown: [https://news.hada.io/topic/31461.md](https://news.hada.io/topic/31461.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-15T21:35:12+09:00 - Updated: 2026-07-15T21:35:12+09:00 - Original source: [mindgard.ai](https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left) - Points: 1 - Comments: 1 ## Topic Body - 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](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) 기록에는 `Cursor.exe`가 저장소 내부의 `git.exe`를 실행하면서 다음 명령을 전달한 내역이 남아 있음 ```text git rev-parse --show-toplevel ``` - 마지막 검증은 **2026년 4월 30일**, Windows용 Cursor 3.2.16에서 이뤄짐 ### 대규모 사용자 기반에 남아 있던 취약점 - [Cursor](https://cursor.com/)는 다음 규모로 사용되는 AI 지원 개발 환경임 - 활성 사용자 700만 명 이상 - 일일 사용자 100만 명 이상 - 유료 사용자 100만 명 이상 - 사용 기업 5만 곳 이상 - [보고된 시장가치는 600억 달러](https://www.forbes.com/sites/richardnieva/2026/06/08/cursor-4-billion-annualized-revenue/)임 - Mindgard는 2025년 12월 15일 취약점을 발견하고 같은 날 신고함 - 서두 기준으로 6개월 이상과 **197개 이상의 새 버전**이 지난 뒤에도 최신 테스트 버전에 취약점이 남아 있었음 - 대응 경과를 다룬 본문에는 기능 추가와 발표가 이어지는 동안 **70개 이상의 버전**이 출시됐지만 문제가 유지됐다고 기록돼 있음 - 단순하고 재현하기 쉬운 임의 코드 실행 취약점이 수개월간 해결되지 않아 Cursor를 배포한 개인과 조직 모두가 영향을 받음 ### 패치 전 적용할 수 있는 임시 대응 - 관리형 Windows 시스템에서는 AppLocker나 Windows App Control 정책으로 개발 작업공간 디렉터리의 해당 실행 파일 이름을 차단할 수 있음 - 바이너리마다 해시가 달라질 수 있으므로 **해시 기반 차단 목록**보다 저장소·작업공간 루트로 범위를 제한한 경로 기반 거부 규칙이 적합함 ```text %USERPROFILE%\source\repos\*\filename.exe ``` - Windows에는 특정 부모 프로세스가 실행한 경우에만 임의의 자식 실행 파일을 차단하는 일반 내장 규칙이 없음 - 부모 프로세스를 인식하는 통제에는 EDR이나 맞춤형 엔드포인트 보안 제품이 필요함 - 일반 사용자는 IDE가 패치될 때까지 신뢰할 수 없는 저장소를 **격리된 VM**, Windows Sandbox 또는 폐기 가능한 환경에서만 열어야 함 - 바이너리를 바꿀 때마다 해시가 달라질 수 있으므로 이 취약점에는 파일 해시 차단 목록을 신뢰해서는 안 됨 ### 신고 후 멈춰 버린 조율 절차 - 최초 신고는 Cursor의 [security.txt](https://cursor.com/.well-known/security.txt)에 지정된 보안 신고 이메일로 전달됐지만 수신 확인이 오지 않음 - Mindgard는 후속 이메일과 [공개 연락 요청](https://www.linkedin.com/posts/aaronportnoy_can-anyone-put-me-in-touch-with-a-security-share-7416965166954868736-agkL/)을 통해 적절한 보안 담당자를 찾으려 함 - 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는 조직이 노출 범위를 평가하고 보완 통제를 적용하며 보안 상태를 판단할 기회를 주기 위해 전체 세부 정보를 공개함 - 정보를 계속 숨기는 것이 사용자가 아니라 침묵만 보호하는 단계에 이르면, 불편하더라도 **사용자 안전**을 우선해야 함 ## Comments ### Comment 61872 - Author: neo - Created: 2026-07-15T21:35:14+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48910676) - 보안 보고서를 받는 입장에서 **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]()` 같은 명령을 유도할 수 있다면, 에이전트가 `git.exe`를 다운로드해 실행할 가능성이 있음