프롬프트를 치기 전에 코딩 에이전트가 탈취된다: 깃 설정 한 줄로 뚫린 GitSpawn

매니폴드 시큐리티는 2026년 9월 2일 공개한 보고서에서 CLI 코딩 에이전트 7종에서 취약점 8건을 찾아냈고 이를 GitSpawn이라 이름 붙였다. 공격자가 저장소의 .git/config에 core.fsmonitor 한 줄을 심어 두면, 에이전트가 프로젝트 맥락을 파악하려고 실행하는 git status 단계에서 그 명령이 개발자 권한으로 실행된다. 사용자가 프롬프트를 한 글자도 입력하기 전이고 신뢰 승인 창이 뜨기 전이며 샌드박스 바깥이다. 클로드 코드와 커서와 오픈AI 코덱스와 구스는 패치됐고, 공개 시점 기준 클로드 코드의 ultrareview 경로와 헤르메스 에이전트와 Qwen Code와 그록 빌드는 패치되지 않은 상태였다. ASAP은 이 취약점의 작동 구조와 국내 개발팀이 오늘 확인할 항목을 정리한다.

에이전트는 사용자가 신뢰를 승인하기 전에 이미 깃 명령을 실행한다

CLI 코딩 에이전트는 시작하자마자 프로젝트 상태를 파악하려고 git status --porcelain=2 --branch나 git diff --name-only HEAD 같은 명령을 자동으로 돌린다. 어떤 브랜치인지, 수정된 파일이 무엇인지, 커밋되지 않은 변경이 있는지를 알아야 첫 응답부터 쓸모 있는 말을 할 수 있기 때문이다. 이 호출은 사용자가 무엇을 시키기 전에 일어나고, 대부분의 도구에서 작업 디렉터리를 신뢰하겠느냐고 묻는 확인 창보다도 앞선다.

문제는 깃이 이 명령을 처리하는 방식에 있다. 깃은 상태를 보고하기 전에 인덱스를 갱신하고, 그 과정에서 저장소 자신의 .git/config를 읽는다. 사용자 홈 디렉터리의 전역 설정이 아니라 지금 열린 폴더 안에 들어 있는 설정 파일이다. 저장소를 만든 쪽이 그 파일의 내용을 정한다.

매니폴드 시큐리티 보고서는 이 지점을 이렇게 정리했다. 맥락 수집 호출들이 저장소 자체의 깃 설정을 걷어내지 않은 채 실행됐고, 깃 설정 가운데 여럿은 명령 실행 싱크라는 것이다. 신뢰 경계가 뚫린 위치가 에이전트의 도구 호출이나 모델의 판단이 아니라 그보다 한 층 아래인 셈이다.

`core.fsmonitor`가 코드 실행 통로가 되는 이유

core.fsmonitor는 원래 대형 저장소의 속도를 높이려고 만든 성능 설정이며, 깃이 디스크의 모든 파일을 검사하는 대신 무엇이 바뀌었는지를 헬퍼 프로그램에 물어보고 그 프로그램을 실행하도록 지시한다. 설계 의도대로라면 파일 시스템 감시 데몬을 가리키는 항목이다. 그러나 깃은 이 값을 저장소의 .git/config에서 읽어 오며, 값이 무엇을 가리키는지 검증하지 않는다.

공격 저장소가 담는 내용은 다음 두 줄이면 충분하다.

[core]
    fsmonitor = <실행할 명령>

이 저장소를 에이전트로 여는 순간 표준 깃 명령 한 번으로 그 명령이 실행된다. 보고서가 요약한 결과는 승인 프롬프트도 없고 화면에 아무것도 표시되지 않은 채 샌드박스 바깥에서 개발자 권한으로 임의 코드가 실행된다는 것이며, 노출 대상에는 SSH 키와 클라우드 자격증명과 셸 토큰과 로컬 저장소 전체가 포함된다.

여기서 짚어 둘 점은 이 취약점이 모델의 결함이 아니라는 것이다. 모델은 아직 아무것도 판단하지 않았고 어떤 도구도 호출하지 않았다. 에이전트라는 제품이 모델 주위에 두른 얇은 껍데기, 즉 맥락을 모으는 셸 명령 몇 줄이 공격면이다. 에이전트 보안을 모델 정렬 문제로만 다루면 이런 층은 통째로 시야에서 빠진다.

공격 조건은 클론이 아니라 압축파일로 받은 저장소다

공격이 성립하려면 저장소가 .git 디렉터리를 그대로 달고 파일 형태로 전달돼야 하며, git clone으로 받은 저장소에서는 성립하지 않는다. 클론은 원격 저장소의 설정을 그대로 복사해 오지 않기 때문이다. 연구진은 .zip 파일로 시연했고, 동료나 외주 개발자가 실제로 프로젝트를 주고받는 방식을 그대로 흉내 냈다고 적었다. 공유 드라이브와 USB와 동기화 폴더가 그 목록에 들어간다.

이 조건이 공격 범위를 좁힌다고 읽을 수도 있지만, 국내 개발 환경을 놓고 보면 사정이 다르다. 발주처가 산출물을 압축파일로 넘기는 SI와 외주 계약, 폐쇄망 반입을 위해 USB로 옮기는 코드, 사내 그룹웨어나 메일로 오가는 프로젝트 사본, 보안 정책상 외부 깃 호스팅을 쓰지 못해 파일로 배포되는 레거시 저장소가 모두 여기에 해당한다. 깃 호스팅에 올라간 공개 저장소보다 오히려 검증 절차가 헐거운 경로다.

경로의 성격도 짚어 둘 만하다. 압축파일로 저장소를 받는 상황은 대개 상대를 어느 정도 신뢰하는 관계에서 발생한다. 낯선 링크를 누르는 것과 달리 경계심이 작동하지 않고, 협력사의 계정이 이미 털린 경우라면 신뢰 자체가 공격의 재료가 된다. 압축을 풀고 에이전트에게 코드 리뷰를 시키는 동작은 국내 팀에서 이미 일상이다.

7종 가운데 4종이 공개 시점까지 패치되지 않았다

매니폴드 시큐리티가 정리한 대응 현황은 제품마다 크게 갈렸다. 아래는 보고서가 밝힌 신고일과 확인된 버전이다.

제품	취약 버전	신고일	공개 시점 상태	CVE
클로드 코드 (`core.fsmonitor`)	2.1.193	2026년 6월 26일	패치됨 (2.1.196)	없음
커서	미공개	2026년 7월 8일	패치됨	없음
오픈AI 코덱스	미공개	2026년 7월 20일	패치됨	없음
구스	1.41.0	2026년 7월 13일	패치됨 (1.44.0)	CVE-2026-72718 (심각도 7.0)
클로드 코드 (ultrareview 경로)	2.1.210	2026년 7월 15일	미패치 (2.1.252에서 확인)	없음
Qwen Code	0.19.6	2026년 7월 7일	미패치 (0.22.3에서 확인)	없음
그록 빌드	0.2.93	2026년 7월 14일	미패치 (1.0.13에서 확인)	없음
헤르메스 에이전트	0.18.2	2026년 7월 20일	미패치 (0.21.0에서 확인)	CVE-2026-71963

이 표에서 눈에 띄는 것은 패치 여부보다 시간 간격이다. 클로드 코드의 첫 건은 6월 26일 신고에서 2.1.196까지 사실상 곧바로 막혔지만, 같은 제품의 ultrareview 경로는 7월 15일에 신고되고도 9월 2일 공개 시점까지 열려 있었다. 같은 회사, 같은 제품, 같은 종류의 결함인데 대응 속도가 갈렸다는 뜻이다. 보고서는 미패치로 남은 두 번째 경로에서 문제가 되는 깃 설정 키가 무엇인지는 밝히지 않았다.

헤르메스 쪽 기록은 성격이 다르다. 연구진은 다섯 개 채널로 여섯 차례 연락을 시도했지만 분류 단계의 응답조차 받지 못했다고 적었다. CVE는 발급됐고 제품은 계속 배포되는데 수신자가 없는 상태다. 관련 저장소들의 깃허브 스타 합계는 약 50만이고 클로드 코드의 npm 월간 내려받기는 2026년 7월 기준 7,700만 회다.

벤더 다수가 "중복 신고"라고 답한 사실이 더 무겁다

보고서에서 가장 시사적인 대목은 미패치 목록이 아니라 벤더들의 응답 형태다. 다수 벤더가 이 신고를 앞서 접수된 독립적인 보고와 중복이라고 회신했으며, 연구진은 이를 이 취약점이 여러 방향에서 각각 발견됐다는 신호로 읽었다.

중복 회신이 무엇을 뜻하는지 나눠 볼 필요가 있다. 좋게 읽으면 이미 인지하고 있었다는 뜻이고, 나쁘게 읽으면 여러 연구자가 독립적으로 도달할 만큼 찾기 쉬운 결함이라는 뜻이다. 후자가 더 중요하다. 서로 다른 팀이 각자 같은 지점을 짚었다면 그 지점은 우연한 실수가 아니라 이 제품군이 공유하는 설계 패턴의 결과다. 맥락을 모으려고 사용자 코드가 있는 디렉터리에서 셸 명령을 먼저 돌린다는 패턴은 지금 나온 모든 CLI 에이전트가 똑같이 쓰고 있다.

그렇다면 core.fsmonitor는 목록의 첫 항목일 뿐이다. 깃에는 외부 프로그램을 지정하는 설정이 여럿 있고, 에이전트가 맥락 수집에 쓰는 명령도 깃 하나로 끝나지 않는다. 패키지 매니저의 설정 파일, 빌드 도구의 스크립트 훅, 에디터 워크스페이스 설정이 모두 같은 성격을 가진다. 이번 건이 닫혀도 같은 형태의 다음 건이 남는다는 뜻이다.

프롬프트 인젝션에 쏠려 있던 논의가 놓친 층

2026년 에이전트 보안 논의는 대체로 모델이 무엇을 읽고 무엇에 속는가를 중심으로 진행됐다. 이슈 트래커에 심긴 가짜 버그 리포트, 풀 리퀘스트 제목에 숨긴 지시문, 웹페이지에 박아 둔 명령문이 그 예다. 이 논의의 전제는 모델이 오염된 입력을 읽고 잘못된 도구 호출을 한다는 것이며, 대응책도 그 전제 위에 서 있다. 도구 호출 승인, 샌드박스, 권한 최소화가 전부 모델의 행동을 겨냥한다.

GitSpawn은 그 전제 바깥에 있다. 모델은 오염된 텍스트를 읽지 않았고 잘못된 도구를 부르지도 않았다. 실행된 것은 에이전트 실행 파일이 스스로 돌린 셸 명령이다. 그래서 승인 프롬프트가 무력하다. 승인 프롬프트는 모델이 무언가를 하려 할 때 뜨는 장치인데, 여기서는 모델이 개입하기 전에 끝났다.

샌드박스도 같은 이유로 비켜 간다. 에이전트 제품들이 자랑하는 격리는 대개 모델이 요청한 명령을 가두는 데 쓰이며, 제품 자신이 시작 단계에서 돌리는 맥락 수집 명령은 그 바깥에서 돈다. 보고서가 "샌드박스 바깥에서"라고 명시한 이유가 여기 있다. 방어선을 어디에 그었는지가 아니라 방어선보다 앞서 일어나는 일이 무엇인지를 따져야 하는 문제다.

국내 팀이 오늘 확인할 것과 남는 질문

지금 당장 할 수 있는 조치는 두 가지 층으로 나뉜다. 사용하는 쪽에서는 보고서 권고대로 압축파일이나 USB나 공유 드라이브로 받은 저장소를 에이전트로 열기 전에 .git/config를 먼저 열어 보면 된다. 프로그램 이름을 지정하는 설정이 있다면 그 프로그램은 실행될 수 있다. .git 디렉터리를 아예 지우고 새로 초기화하는 방법도 확실하다.

만드는 쪽에서는 맥락 수집 호출에 저장소 설정이 끼어들지 못하게 막으면 된다. 보고서가 제시한 형태는 git -c core.fsmonitor=false status처럼 실행 시점에 설정을 무력화하는 방식이다. 사내에서 에이전트를 감싸 배포하고 있다면 래퍼 단계에서 같은 처리를 넣을 수 있다.

조직 차원에서는 자산 파악이 먼저다. 미패치 목록에 오른 Qwen Code와 그록 빌드와 헤르메스 에이전트가 사내에 깔려 있는지, 클로드 코드 버전이 2.1.196 이상인지 확인해야 한다. ultrareview 경로가 열려 있다는 점을 감안하면 버전 갱신만으로 끝나지 않으므로, 신뢰하지 않는 저장소를 에이전트로 여는 관행 자체를 손보는 편이 안전하다.

남는 질문도 분명하다. 이 취약점이 실제로 악용된 사례가 있는지는 보고서에 없고, 미패치로 남은 네 제품이 언제 고쳐질지도 알 수 없다. 클로드 코드의 두 번째 경로에서 쓰이는 설정 키가 공개되지 않은 상태이므로 사용자가 직접 점검할 방법도 제한된다. 무엇보다 이번 건은 깃 설정 하나를 막는 문제가 아니라, 에이전트가 사용자 승인 이전에 어디까지 실행해도 되는가라는 질문을 처음으로 표면에 올렸다. 그 질문에 답을 내놓은 제품은 아직 없다.

출처: Manifold Security, "GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok"(2026년 9월 2일, 프란시스코 로살레스) 기반 ASAP 정리.