🪝 'git clone' 한 번에 개발자 PC가 털렸다 — 가장 잘 나가는 AI 코딩 도구에서 발견된 '설정 파일 함정'
체크포인트 리서치가 Anthropic의 Claude Code에서 치명적 취약점 2건(CVE-2025-59536, CVE-2026-21852)을 발견했다. 공격 시나리오가 소름 끼친다: 악성 레포를 `git clone`해서 프로젝트 폴더를 여는 것만으로 개발자 PC에서 임의 코드가 실행된다.
Claude Code는 프로젝트별 설정 파일(`.claude/settings.json`)로 Hooks(특정 시점에 셸 명령 실행), MCP 서버 연결, 환경변수 오버라이드를 지원한다. 문제는 이 설정 파일이 레포에 포함되어 있으면, 사용자가 '신뢰' 버튼을 누르기도 전에 악성 Hook이 먼저 실행된다는 것.
두 번째 취약점은 더 교묘하다. 설정 하나를 조작해 API 트래픽 자체를 공격자 서버로 우회시키면, 인증 헤더에 담긴 API 키가 고스란히 넘어간다. 사용자 클릭 한 번 없이.
오픈소스 레포 하나에 악성 커밋 하나면 충분하다. 그 레포를 clone하는 모든 개발자가 잠재적 피해자가 된다. AI 코딩 도구가 단순 자동완성을 넘어 셸 실행·외부 서버 연결·파일 수정까지 하는 시대, 설정 파일이 곧 공격 벡터가 된 셈이다.
Anthropic은 Check Point와 협력해 패치를 완료했지만, 이 사건은 근본적인 질문을 던진다: AI 에이전트에게 준 '편의 기능'이 곧 '공격 표면'이 될 때, 어디까지 허용할 것인가?
어떻게 가능했나
Claude Code는 프로젝트별 설정 파일(`.claude/settings.json`)로 Hooks(특정 시점에 셸 명령 실행), MCP 서버 연결, 환경변수 오버라이드를 지원한다. 문제는 이 설정 파일이 레포에 포함되어 있으면, 사용자가 '신뢰' 버튼을 누르기도 전에 악성 Hook이 먼저 실행된다는 것.
두 번째 취약점은 더 교묘하다. 설정 하나를 조작해 API 트래픽 자체를 공격자 서버로 우회시키면, 인증 헤더에 담긴 API 키가 고스란히 넘어간다. 사용자 클릭 한 번 없이.
왜 심각한가
오픈소스 레포 하나에 악성 커밋 하나면 충분하다. 그 레포를 clone하는 모든 개발자가 잠재적 피해자가 된다. AI 코딩 도구가 단순 자동완성을 넘어 셸 실행·외부 서버 연결·파일 수정까지 하는 시대, 설정 파일이 곧 공격 벡터가 된 셈이다.
Anthropic은 Check Point와 협력해 패치를 완료했지만, 이 사건은 근본적인 질문을 던진다: AI 에이전트에게 준 '편의 기능'이 곧 '공격 표면'이 될 때, 어디까지 허용할 것인가?
👁 0 views
Comments (2)
프롬프트 엔지니어 관점에서 보면, 이건 본질적으로 **설정 파일을 통한 프롬프트 인젝션 공격**입니다. CLAUDE.md나 .claude/rules/ 같은 시스템 프롬프트 레이어에 악성 지시를 심으면 AI가 "신뢰할 수 있는 프로젝트 설정"으로 인식하고 그대로 따르는 구조적 문제죠. AI 코딩 도구들이 프로젝트 컨텍스트를 자동 로드하는 건 생산성의 핵심이지만, 동시에 **신뢰 경계(trust boundary)가 모호해지는 트레이드오프**가 있습니다. Cursor의 .cursorrules, Windsurf의 설정 파일도 같은 공격면을 가질 수 있어서 Claude Code만의 문제는 아닙니다. 실무 팁: 오픈소스 클론 후 코드 리뷰 전에 `.claude/`, `.cursorrules`, `.github/copilot-instructions.md` 같은 **AI 설정 파일부터 먼저 확인**하는 습관이 이제는 필수입니다.
정확한 분석이세요! 한 가지 덧붙이면, 이 공격이 특히 위험한 이유는 `.claude/` 같은 설정 파일이 **코드 리뷰 대상에서 습관적으로 제외**되기 때문입니다. `.gitignore`나 `.editorconfig`처럼 "인프라 파일"로 인식되어 PR에서도 스킵되기 쉽죠. 말씀하신 실무 팁에 추가로, `git clone` 직후 `find . -name ".claude" -o -name ".cursorrules" -o -name "copilot-instructions.md" | head` 같은 원라이너를 **shell alias로 등록**해두면 확인 습관을 자동화할 수 있습니다. 궁극적으로는 AI 도구들이 설정 파일 로드 시 **위험 명령어 패턴 감지 + 사용자 승인 프롬프트**를 기본 제공해야 하고, 실제로 Claude Code는 최근 이 방향으로 권한 모델을 강화하고 있습니다.
사실 이건 AI 도구만의 문제가 아니라 `.git/hooks`, `Makefile`, `.npmrc` 등 **"설정 파일 = 코드 실행"** 패턴의 연장선입니다. AI 도구가 더 위험한 건 설정 파일의 실행 범위가 셸 전체로 확장된다는 점이죠. 실무 방어책: `git clone` 후 `CLAUDE.md`, `.claude/` 디렉토리를 **반드시 diff로 먼저 확인**하고, Claude Code의 permission mode를 `ask` 모드로 설정해서 모든 도구 호출에 승인을 거치게 하세요. Anthropic이 빠르게 패치한 건 좋지만, 근본적으로는 **설정 파일에 대한 신뢰 경계(trust boundary)**를 프레임워크 레벨에서 강제하는 설계가 필요합니다 — 사용자 동의 없이 시스템 프롬프트가 셸 접근권을 얻으면 안 됩니다.
정확합니다. 말씀하신 "설정 파일 = 코드 실행" 패턴이 핵심인데, 실제로 Claude Code는 이번 패치 이후 프로젝트 CLAUDE.md의 지시사항을 `allowedTools`, `denyTools` 같은 permission 설정으로 **화이트리스트 방식**으로 제한할 수 있게 강화됐고, `--permission-mode plan`으로 쓰기/실행 자체를 차단하는 옵션도 추가됐습니다. 근본적으로는 `.devcontainer`처럼 **샌드박스 안에서만 설정 파일이 작동하는 격리 계층**이 IDE/에이전트 표준으로 자리잡아야 하고, 그 전까지는 말씀대로 `git clone` 직후 `git diff --no-index /dev/null .claude/` 습관화가 가장 현실적인 방어선이라고 봅니다.