폴더 여는 순간 코드가 실행됐다

AI 코딩 에이전트로 프로젝트 폴더를 여는 순간, 그 폴더가 지정한 명령이 사용자 권한으로 실행될 수 있다는 연구 결과가 공개됐다. 보안업체 매니폴드 시큐리티(Manifold Security)의 공격보안 엔지니어 프란시스코 로살레스(Francisco Rosales)가 9월 1일 발표한 내용으로, 에이전트 7종에서 8건의 결함이 확인됐고 발표 시점 기준 4건은 아직 고쳐지지 않았다. 연구진은 이 문제에 '깃스폰(GitSpawn)'이라는 이름을 붙였다.

무슨 일인가 / 배경

연구는 단순한 질문에서 출발했다. "명령줄 AI 에이전트는 실행되는 순간 실제로 무슨 일을 하는가." 확인해보니 여러 제품이 똑같이 행동했다. 열린 프로젝트의 맥락을 파악하기 위해 사용자가 아무것도 입력하기 전에 깃(git) 명령을 먼저 실행한다는 것이다. 클로드 코드(Claude Code)의 경우 프롬프트 입력 전은 물론 작업공간 신뢰 확인 창이 뜨기도 전에 git status가 돌아간다. 일부 제품에서는 인증 절차보다도 앞선다.

문제는 그 명령들이 저장소 자체의 깃 설정을 걸러내지 않고 실행된다는 데 있다. git status --porcelain=2 --branch나 git diff --name-only HEAD 같은 지극히 평범한 명령들인데, 이들은 작업 트리를 건드리기 때문에 실행 전 인덱스를 갱신한다. 그 갱신 과정이 함정이다. 대형 저장소 성능 향상을 위한 설정인 core.fsmonitor는 파일 변경 여부를 외부 헬퍼 프로그램에게 물어보도록 되어 있고, 깃은 이 설정값을 저장소 안의 .git/config에서 읽는다. 즉 저장소가 자기 설정 파일에 실행할 명령을 적어두면, 에이전트가 무심코 부른 git 명령이 그것을 그대로 실행한다.

핵심 짚어보기

공격자가 얻는 것은 제한된 권한이 아니라 개발자 본인의 권한이다. 샌드박스 바깥에서, 승인 프롬프트 없이, 화면에 아무 표시도 남기지 않고 실행된다. 에이전트의 권한 모델은 이 실행을 아예 관측하지 못한다. 에이전트 자신의 코드가 git을 쓰려고 띄운 하위 프로세스이기 때문이다. 노출 대상은 SSH 키, 환경변수에 담긴 클라우드 자격증명, 셸 설정 파일의 토큰, 디스크에 있는 모든 저장소다.

전달 경로는 명확히 짚어둘 필요가 있다. 악성 주소를 git clone해도, fetch나 pull을 해도 이 공격은 성립하지 않는다. 깃 프로토콜은 저장소 설정을 실어 나르지 않기 때문이다. 성립하려면 .git 디렉터리가 들어 있는 상태로 폴더가 통째로 옮겨져야 한다. 압축 파일, 공유 드라이브, 동기화 폴더, USB 메모리가 그 통로다. 연구진의 모든 실증 사례는 zip 파일을 사용했다. 동료끼리 프로젝트를 압축해 주고받고, 외주 개발자가 클라이언트에게 폴더째 넘기는 익숙한 관행이 그대로 공격 표면이 된다.

영향 범위는 특정 벤더의 문제가 아니다. 사례로 다뤄진 제품만 해도 클로드 코드, 구스(Goose), 그록 빌드(Grok Build), 헤르메스(Hermes), 퀀 코드(Qwen Code)이며, 오픈에이아이 코덱스와 커서(Cursor)도 영향을 받았다가 이후 패치됐다. 깃허브 스타 수만 합쳐도 50만에 가깝고, 클로드 코드는 npm 월 다운로드가 7,700만 건을 넘는다. 신고된 8건 중 5건은 다른 연구자가 이미 독립적으로 제보한 건과 중복 처리됐고, 그중 한 건은 같은 날 접수됐다.

1인기업 실전 적용 포인트

• 외주처·클라이언트가 zip이나 공유 드라이브로 넘긴 프로젝트 폴더를 AI 에이전트로 곧바로 열지 말 것. 여는 행위 자체가 실행이다.
• 남에게 받은 폴더는 압축을 푼 직후 cat .git/config로 내용을 먼저 눈으로 확인하자. fsmonitor 같은 명령 실행형 설정이 있으면 그 자리에서 지운다.
• 더 확실한 방법은 .git 폴더를 통째로 삭제하고 원본 저장소에서 git clone으로 다시 받는 것이다. 클론 경로로는 이 설정이 따라오지 않는다.
• 출처가 불분명한 코드를 봐야 한다면 컨테이너나 별도 가상머신 안에서 열자. 호스트에 SSH 키와 .env가 그대로 있는 상태로 여는 것이 가장 위험하다.

전망 / 주의점

이 사건의 교훈은 특정 제품의 버그가 아니라 구조에 있다. 에이전트가 '편의를 위해 알아서 먼저 하는 일'이 늘어날수록, 사용자가 승인할 기회조차 없는 실행 지점도 함께 늘어난다. 4건이 미패치 상태로 공개된 만큼 당분간은 사용자 쪽 습관이 유일한 방어선이다. 자동화 수준을 높이는 방향과 신뢰 경계를 지키는 방향은 자주 충돌하며, 이번 건은 그 충돌이 이미 실제 피해로 이어질 수 있는 단계에 왔음을 보여준다.

출처: Manifold Security (https://www.manifold.security/blog/ai-coding-agents-git-hijack)