AI 코딩 에이전트가 폴더를 열기만 해도 악성 git 설정의 명령이 실행된다

핵심 요약

• AI 코딩 에이전트가 저장소 폴더를 여는 순간, 그 저장소의 .git/config에 심어진 명령이 개발자 권한으로 실행된다.
• Manifold Security가 2026년 9월 1일 공개한 "GitSpawn" 취약점 클래스로, 7개 에이전트에서 8건이 확인됐다.
• Claude Code와 Codex, Cursor는 패치됐지만 Qwen Code, Grok Build, Claude Code의 ultrareview 경로, Hermes는 게시 시점까지 미패치로 남았다.
• 명령은 에이전트의 샌드박스 밖에서, 승인 프롬프트 없이, 워크스페이스 신뢰를 수락하기 전에 실행된다.
• 위험 경로는 원격 저장소가 아니라 공유 압축 파일, 드라이브, 동기화 폴더, USB로 전달된 폴더다. git clone은 .git/config를 복사하지 않는다.
• 이 취약점은 새로 발견된 것이 아니라 회귀다. VS Code는 2021년에 같은 클래스를 고쳤고, 뒤늦게 등장한 코딩 에이전트가 문을 다시 열었다.
• 실측으로 core.fsmonitor가 git status에서 실행되고 -c core.fsmonitor=false로 차단되는 것을 직접 확인했다.

폴더를 여는 것만으로 실행되는 코드

GitSpawn은 AI 코딩 에이전트가 저장소를 열 때 백그라운드에서 돌리는 git 호출이 그 저장소 자신의 .git/config를 제거하지 않아, 설정 파일에 심어둔 명령이 사용자 권한으로 실행되는 취약점 클래스입니다. Manifold Security가 2026년 9월 1일 공개했고, Cloud Security Alliance와 The Hacker News가 잇따라 다뤘습니다.

출발점은 사소해 보이는 관찰이었습니다. CLI형 코딩 에이전트는 시작할 때 프로젝트 맥락을 모으기 위해 git을 실행합니다. 어떤 에이전트는 프롬프트를 입력하기 전에, 어떤 에이전트는 워크스페이스 신뢰 프롬프트를 수락하기도 전에, 인증조차 하기 전에 git status를 돌립니다. Manifold가 지목한 명령은 git status --porcelain=2 --branch, git diff --name-only HEAD처럼 우리가 직접 쓸 법한 평범한 것들이었습니다.

평범한 명령이 왜 위험한지가 이 취약점의 핵심입니다. 이런 명령은 대개 git 인덱스를 먼저 새로고침하는데, 바로 그 새로고침이 실행 지점이 됩니다.

git이 저장소의 명령을 대신 실행한다

git에는 대형 저장소를 위한 성능 설정 core.fsmonitor가 있습니다. 디스크의 모든 파일을 검사하는 대신 헬퍼 프로그램에게 무엇이 바뀌었는지 물어보는 설정입니다. 문제는 이 설정의 값이 곧 실행할 명령이라는 점입니다. git은 인덱스를 새로고침할 때마다 이 명령을 그대로 실행합니다. 문서화된 의도된 동작입니다.

더 까다로운 대목은 git이 이 설정을 전역 위치가 아니라 저장소 자신의 .git/config에서 읽는다는 사실입니다. 그래서 저장소가 명령을 배송할 수 있습니다. 설정 파일에 core.fsmonitor 항목으로 명령을 적어두면, git status든 git diff든 인덱스를 새로고침하는 아무 명령에서나 그대로 실행됩니다. paddo.dev의 분석에 따르면 이 설정이 유일한 경로도 아닙니다. OpenAI가 공개한 세 개의 CVE가 각각 core.fsmonitor, core.hooksPath, attr.tree라는 서로 다른 키를 다룹니다.

전달 경로는 정확히 짚을 필요가 있습니다. git은 이 설정을 원격에서 가져오지 않습니다. 그래서 악성 URL을 clone하는 것만으로는 아무 일도 일어나지 않고, fetch나 pull도 마찬가지입니다. 위험한 것은 .git 디렉터리가 통째로 들어 있는 폴더를 파일로 받는 경우입니다. 공유 압축 파일, 공유 드라이브, 동기화 폴더, USB가 여기 해당합니다. 협업에서 흔히 오가는 바로 그 형태입니다.

실측, core.fsmonitor는 실행되고 플래그로 차단된다

이 글은 공개 자료를 그대로 옮기지 않고 메커니즘을 직접 확인했습니다. 임시 저장소를 하나 만들어 core.fsmonitor에 타임스탬프를 남기는 스크립트를 지정한 뒤 평범한 git status를 실행했습니다. 결과는 명확했습니다. 화면에 아무것도 출력되지 않았는데 표식 파일이 생성됐고, 이는 git status 한 번이 저장소가 지정한 명령을 실행했다는 뜻입니다.

이어서 호출 시점에 위험 키를 무효화하는 방식이 실제로 막는지도 확인했습니다. git -c core.fsmonitor=false status로 같은 저장소를 다시 조회하자 표식 파일은 생성되지 않았습니다. Manifold가 권고한 완화책이 동작함을 같은 환경에서 재현한 셈입니다. 다만 이 방식의 약점도 분명합니다. 호출 지점마다 플래그를 붙이는 구조라, git을 새로 호출하는 기능이 추가될 때마다 빠뜨릴 위험이 생깁니다. 실제로 Claude Code의 전체 저장소 리뷰 기능이 그렇게 추가됐고, 이 경로는 아직 막히지 않았습니다.

같은 실수가 4년 전에도 있었다

GitSpawn은 새로운 발견이 아닙니다. Justin Steven이 2022년 3월에 core.fsmonitor 악용과 숨겨진 bare 저장소 문제를 이미 공개했습니다. 그때 문제가 된 소프트웨어 목록에는 VS Code, JetBrains, Atom, Visual Studio, 브랜치명을 표시하는 셸 프롬프트가 모두 들어 있었습니다.

대응도 이미 있었습니다. VS Code는 CVE-2021-43891로 1.63.1부터 워크스페이스를 신뢰하기 전에는 git을 실행하지 않도록 고쳤고, JetBrains도 CVE-2022-24345로 뒤따랐습니다. git 자체도 2.38 버전에서 safe.bareRepository를 추가했습니다. Sonar는 2026년 4월 Claude Code에서 같은 버그를 찾아냈고, 그 경로는 2.0.71에서 패치됐습니다.

정리하면 이렇습니다. 4년 전 IDE가 닫아둔 문을, 그 뒤에 등장한 코딩 에이전트가 다시 열었습니다. 취약점이 모델의 지능이나 안전 정렬에 있는 것이 아니라, 그 아래의 평범한 서브프로세스 배관에 있다는 점이 이 사건의 본질입니다.

에이전트별 현황과 남은 구멍

Manifold가 공개한 8건의 처리 결과는 벤더마다 크게 갈렸습니다.

눈에 띄는 사실이 두 가지 있습니다. 첫째, 여덟 건 가운데 다섯 건이 다른 연구자가 이미 독립적으로 제출한 보고의 중복으로 반려됐습니다. 같은 결함이 여러 방향에서 동시에 발견된 것입니다. 둘째, 게시 시점까지 네 건이 미패치로 남았습니다. 특히 Hermes는 벤더가 아닌 독립 CVE 번호 발급 기관이 CVE-2026-71963을 부여했고, Grok Build와 Qwen Code는 여전히 열려 있습니다.

영향 범위도 작지 않습니다. GitHub 공개 별 수를 2026년 9월 16일 기준으로 직접 확인했습니다. Hermes 저장소는 약 24만 6천 개, Claude Code는 약 14만 5천 개, Codex는 약 12만 4천 개, Qwen Code는 약 2만 8천 개, Grok Build는 약 2만 7천 개의 별을 받았습니다. Manifold가 제시한 수치와 큰 차이가 없습니다.

무엇을 해야 하는가

파일로 받은 저장소는 열기 전에 검사하는 것이 가장 확실한 방어입니다. 해당 폴더에서 git config --local --list를 실행해 fsmonitor, hooksPath, attr.tree, filter 류 설정이 있는지 확인합니다. 이름이 프로그램을 가리키는 설정은 그대로 실행될 수 있습니다.

검사가 번거롭다면 .git 디렉터리를 지우고 신뢰하는 원본에서 다시 clone하는 편이 낫습니다. clone은 로컬 설정을 가져오지 않으므로 이 경우 위험이 사라집니다. 병행해서 사용하는 도구를 최신 버전으로 올리는 것을 권합니다. Codex CLI는 0.131.0 이상, Claude Code는 2.1.196 이상, Goose는 1.44.0 이상이 알려진 fsmonitor 경로를 닫습니다. 신뢰할 수 없는 폴더에서는 Claude Code의 클라우드 리뷰 기능을 쓰지 않기를 권합니다. 이 경로는 아직 열려 있고 관련 설정 키도 공개되지 않았습니다.

에이전트를 직접 만든다면 git 호출을 한 함수로 모으고, 신뢰 이전에는 git을 실행하지 않는 VS Code 방식을 따르는 것이 안전합니다. 호출마다 -c core.fsmonitor=false를 붙이는 방식은 호출 지점이 늘어날 때마다 빠뜨릴 위험이 있습니다. 이번 사례에서 회귀가 반복된 이유도 정확히 그 구조 때문입니다.

판단과 한계

이 사건의 교훈은 에이전트를 조심하라는 것이 아니라 신뢰 경계의 위치에 관한 것입니다. 에이전트는 워크스페이스 신뢰 프롬프트나 권한 확인 창으로 사용자를 보호한다고 믿게 하지만, 정작 그 확인이 뜨기도 전에 git 서브프로세스가 저장소의 명령을 실행합니다. Manifold는 이 지점을 권한 모델이 이 실행을 전혀 보지 못한다고 표현했습니다. 사용자가 승인할 기회 자체가 없는 것입니다. 안전장치가 촘촘한지는 결국 모델이 무엇을 거부하는지의 문제이고, 이 코드는 모델에게 묻지도 않습니다.

한계도 분명히 해둡니다. 이것은 원격 코드 실행이 아닙니다. 공격자는 .git이 그대로 들어 있는 폴더를 피해자가 받아서 에이전트로 열게 만들어야 하고, 페이로드는 최고 권한이 아니라 사용자 권한으로 실행됩니다. 이미 패치된 경로는 구버전이고 자동 업데이트가 대부분의 설치를 덮습니다. 그럼에도 남은 네 건과, 설정 키 하나로 코드가 실행된다는 구조 자체는 다음 기능이 추가될 때마다 같은 자리에서 되살아날 수 있습니다. 새 기능을 붙일 때마다 git 호출 지점을 다시 점검해 보십시오.

참고 링크

• Manifold Security, GitSpawn 1차 공개
• Cloud Security Alliance, GitSpawn 리서치 노트
• paddo.dev, GitSpawn과 VS Code 2021 회귀 분석
• Justin Steven, 2022년 fsmonitor 악용 권고문
• Sonar, Claude Code 임의 코드 실행