저장소가 자신의 신뢰 여부에 투표해서는 안 됩니다

2026년 4월 24일, Anthropic는 CVSS 7.7 등급의 Claude Code 신뢰 대화상자 우회 취약점인 GHSA-q5hj-mxqh-vv77을 공개했습니다. 그보다 37일 앞선 3월 18일, 같은 프로젝트는 동일한 CVSS 점수의 GHSA-mmgp-wc2j-qcv7을 공개했습니다. 6주라는 동일한 기간 안에 같은 에이전트 런타임에서 두 건의 신뢰 대화상자 우회 취약점이 발생한 것은 우연이 아닙니다.¹²

공통된 양상이 바로 교훈입니다. 3월 버그에서는 프로젝트가 제어하는 .claude/settings.json이 작업 공간 신뢰 검사보다 먼저 읽혔고, 해당 파일의 bypassPermissions 권한 모드는 게이트를 손쉽게 통과했습니다.² 4월 버그에서는 악의적인 저장소가 .git/ 내부에 조작된 commondir 파일을 포함시키고, 신뢰 평가기가 사용자가 이미 신뢰하고 있는 디렉터리로 포인터를 따라가, 작업 공간이 대화상자를 한 번도 표시하지 않은 채 그 신뢰를 상속받았습니다.¹

아무도 아직 열어보지 않은 저장소 안에 있는 두 줄의 텍스트가 작업 공간을 신뢰됨으로 투표할 수 있었습니다. 저장소가 함께 배포하는 프로젝트 수준의 표면들(훅, MCP 서버 구성, 스킬, 서브 에이전트)은 그 투표를 기준으로, 세션 시작 시 즉시 또는 호출 시 지연 방식으로 확인될 수 있습니다. 모든 에이전트 런타임의 하위 방어 수단은 그것들이 존재하기 전에 런타임이 내리는 결정에 의해 통제됩니다.

TL;DR

• 37일 만에 발생한 두 건의 Claude Code 신뢰 대화상자 우회 CVE는 저장소가 제어하는 바이트가 작업 공간 신뢰에 영향을 미칠 때 무엇이 무너지는지 보여줍니다.
• 즉각적인 사용자 측 해결책은 2.1.84 이상으로 업그레이드하고, ~/.claude.json에서 신뢰된 경로를 좁히며, ~/Projects와 같은 광범위한 상위 경로 신뢰를 피하는 것입니다.
• 구조적 해결책은 로드 순서 불변 조건입니다. 작업 공간 경로가 명시적으로 신뢰되기 전까지는 작업 공간의 어떤 바이트도 해석하지 않는 것입니다.

두 권고문이 실제로 패치한 내용

문서와 함께 패치를 읽어보면 로드 순서의 실패가 드러납니다. 수정된 버전들은 신뢰 평가기가 어떤 바이트를 참조할 수 있는지 그 순서를 재배열합니다.

3월 권고문은 Claude Code가 작업 공간 신뢰를 확인하기 전에 프로젝트 설정을 확인하는 상황을 설명합니다. 2.1.53의 수정 사항은 그 순서를 뒤집어, 사용자가 결정을 내리기 전에 신뢰 검사가 작업 공간 내부의 .claude/settings.json을 더 이상 읽지 않도록 했습니다.² 4월 권고문은 신뢰 평가기가 작업 공간 경로 자체를 확인하는 도중에 저장소의 .git/ 디렉터리에 있는 commondir 파일을 따라가는 상황을 설명합니다. 2.1.84의 수정 사항은 신뢰 평가 도중 저장소가 제어하는 commondir 콘텐츠를 더 이상 인정하지 않도록 평가기를 막았습니다.¹ 두 패치는 동일한 불변 조건을 복원합니다. 신뢰 결정은 후보 작업 공간 내부에 존재하는 바이트를 참조해서는 안 된다는 것입니다.

CVE 분류도 같은 진단을 가리킵니다. 3월 버그는 보안 결정에서 신뢰할 수 없는 입력에 대한 의존인 CWE-807로 등록되었습니다.³ 4월 버그는 commondir 해석이 저장소가 제어하는 바이트를 권위 있는 것으로 취급했기 때문에, 부적절한 입력 검증과 특수 요소의 부적절한 무력화인 CWE-20과 CWE-77로 등록되었습니다.¹ 다른 CWE이지만 같은 잘못된 가정입니다. 자신이 보호해야 할 산출물에서 데이터를 읽는 보안 게이트입니다.

신뢰 이전 표면은 설정 참조 문서가 암시하는 것보다 넓습니다

Claude Code는 신뢰 게이트 뒤에 머물러야 하는 프로젝트가 제어하는 세션 시작 표면들을 문서화합니다. 이 부류의 두 CVE는 그중 어느 하나라도 신뢰 결정 자체에 진입할 때 불변 조건이 무너진다는 사실을 증명합니다. 표면들은 신뢰 분석이 분리해서 유지해야 하는 두 가지 범위로 나뉩니다. 복제된 저장소와 함께 배포되는 바이트, 그리고 사용자가 커밋하지 않고 작업 공간에 로컬로 추가하는 바이트입니다.⁴⁵⁶⁷

저장소에 커밋되는 표면(git clone과 함께 배포됨). 이는 공급망 표면입니다. 이 그룹에 속하는 모든 것은 공격자가 악의적인 저장소를 만들 때 통제할 수 있는 대상입니다.

작업 공간 로컬 표면(기본적으로 커밋되지 않음). 이들은 공급망을 타고 작업 공간에 들어오지 않습니다. 로컬 사용자가 만들 때 나타납니다. 그래도 작업 공간 경로 내부에 존재하므로, 신뢰 게이트는 경로가 승인될 때까지 이들을 신뢰할 수 없는 것으로 취급해야 합니다.

훅은 별도 파일이 아닌 .claude/settings.json 내부에 존재합니다. 4월 권고문은 공격자가 그 키를 직접 채우는 상황을 설명합니다.¹⁶ 4월 버그는 또한 Claude Code 구성 참조 문서에 전혀 포함되지 않은 표면을 드러냈습니다. 워크트리를 상위 저장소로 다시 연결하는 git 내부 파일인 commondir입니다.⁸ 조작된 commondir 레이아웃을 배포하는 악의적인 저장소는, Claude Code가 신뢰 평가 도중 그 포인터를 따라갈 때 대상 경로의 신뢰를 상속받습니다. git 내부 표면이 프로젝트 구성 표면 카운트를 무너뜨렸다는 것이 진짜 교훈입니다. 분류는 닫혀 있지 않습니다. 공격 표면은 대화상자가 발동하기 전에 어떤 바이트가 읽히는지에 의해 정의되며, 경로 해석이나 구성에 영향을 줄 수 있는 모든 것이 공격 대상이 됩니다.

이 패턴은 MCP 서버는 새로운 공격 표면이 다른 고도에서 명명한 것과 같습니다.⁹ MCP 서버는 생태계가 그 의미를 따라잡기 전에 도구 제공자 표면을 폭발시켰습니다. 신뢰 대화상자 우회는 한 층 더 아래에서 동일한 양상입니다. 저장소가 에이전트를 사전 구성할 수 있게 해주는 모든 편의 기능은 위 분류표에 한 행씩 추가합니다. 모든 행은 이 부류의 다음 CVE 후보입니다.

캐비닛의 뒷면: 더 똑똑한 대화상자가 아닌 로드 순서 불변 조건

폴 잡스는 스티브에게 캐비닛 아랫면도 마감면과 같은 정성을 받을 자격이 있다고 가르쳤습니다.¹⁰ 캐비닛 비유는 여기서 장식이 아닙니다. 해결책의 척추입니다.

신뢰 대화상자는 캐비닛의 뒷면입니다. 사용자는 로드 순서를 보지 않습니다. 사용자는 대화상자를 보고, 신뢰를 클릭하며, 그 클릭 이전까지 작업 공간 내부의 모든 바이트가 비활성 상태라고 가정합니다. 구현은 그 가정을 마땅히 받을 만한 것으로 만들어야 합니다. 그렇지 못할 때, 그 가정 자체가 공격 표면이 됩니다.

로드 순서는 그 가정이 마땅한지 결정하는 불변 조건입니다. 두 권고문과 공개된 Claude Code 설정 문서가 암시하는 최소한의 모델은 대략 다음과 같습니다.²¹⁶

1. ~/.claude/settings.json에서 사용자 설정을 읽습니다.
2. ~/.claude/settings.local.json에서 사용자 설정을 읽습니다.
3. 현재 작업 공간 경로가 신뢰되는지 평가합니다.
4. 신뢰되지 않으면 대화상자를 표시합니다. 사용자가 신뢰를 클릭하면 경로를 저장합니다.
5. 저장소 내부의 프로젝트 범위 .claude/settings.json을 읽습니다.
6. 프로젝트 범위 .claude/settings.local.json을 읽습니다.
7. 병합된 설정에서 훅, MCP 서버, 스킬, 서브 에이전트를 확인합니다.
8. SessionStart 훅을 실행합니다.

권고문은 모든 단계를 정확히 문서화하지는 않으며, 설정 병합과 관련해 스킬, 서브 에이전트, MCP의 위치는 사용자에게 보이지 않는 구현 세부 사항입니다. 권고문이 분명히 확립하는 것은 3단계의 경계입니다. 3단계 이전에 확인되는 모든 것은 신뢰된 입력 영역에 있습니다. 3단계 또는 그 이후에 확인되는 모든 것은 작업 공간 바이트를 참조해서는 안 됩니다. 3월 버그는 3단계와 5단계의 순서를 바꿨습니다. 프로젝트 설정이 먼저 확인되었고, 해당 설정이 지정한 권한 모드(bypassPermissions)가 3단계의 신뢰 검사를 손쉽게 통과했습니다.² 4월 버그는 공격을 3단계 자체로 옮겼습니다. 작업 공간 경로 해석이 저장소가 제어하는 commondir 파일을 참조했고, 위조 파일이 공격자가 선택한 신뢰된 경로로 신뢰 검사가 해석되도록 만들었습니다.¹ 어느 쪽이든, 7단계나 8단계에 도달할 때쯤이면 작업 공간은 이미 신뢰된 상태이며, 모든 프로젝트 수준 표면이 그 투표를 기준으로 로드됩니다.

캐비닛의 뒷면이 요구하는 규칙은 한 문장입니다. 사용자가 작업 공간 경로를 명시적으로 신뢰하기 전까지는 작업 공간 내부의 어떤 바이트도 해석하지 않는 것입니다. .claude/settings.json도 아닙니다. commondir도 아닙니다. CLAUDE.md도 아닙니다. 파일명 목록도 아닙니다. 훅 파일도 아닙니다. MCP 서버 구성도 아닙니다. 작업 공간 내부에 존재하는 것이라면, 신뢰를 결정하는 코드는 그것을 보지 않습니다.

Visual Studio Code는 2021년 5월에 워크스페이스 트러스트(릴리스 1.57)로 이 수정을 출시했습니다. 핵심 폴더 신뢰 클래스는 기능 출시 이후 공개된 우회 사례를 만들지 않았지만, 신뢰된 도메인과 확장 동작과 관련된 인접 이슈는 계속 나타나고 있습니다.¹¹¹² 3월 권고문이 참조한 수정 버전인 2.1.53은 3단계와 5단계의 순서를 재배열함으로써 Claude Code 버전의 불변 조건을 구현했습니다.² 4월 권고문이 참조한 수정 버전인 2.1.84는 신뢰 평가 도중 저장소가 제어하는 commondir 파일을 따라가지 않도록 함으로써 그 불변 조건을 구현했습니다.¹ 두 패치 모두 새로운 방어를 발명한 것이 아니라 불변 조건을 복원하는 패치입니다.

스티브 테스트는 다음 실마리를 끌어냅니다. 블레이크라면 여기에 자기 이름을 서명하겠는가?¹³ 이 6주 동안 Claude Code에 대한 답은 아니오입니다. 공급사가 이 부류의 우회를 두 번이나 서명하고, 출시하고, 패치했기 때문입니다. 이는 공급사가 해결해야 할 기준입니다. 최소한의 가치 있는 제품이 그 서명이 가리키는 기준입니다.¹⁴ 최소한이라는 것은 범위 제약이지 품질의 할인이 아닙니다. 최소한의 실행 가능한 신뢰 대화상자는 손쉬운 사례를 차단하는 대화상자입니다. 최소한의 가치 있는 신뢰 대화상자는, 사용자가 결정을 내리기 전에는 어떤 저장소 바이트도 해석하기를 거부하는 로드 순서의 첫 단계입니다. 여러분이 출시하는 제품은 허용되기 전까지 해석하기를 거부하는 바이트들입니다.

불변 조건이 요구하는 세 가지 수정

규칙은 불변 조건입니다. 거기서 직접적으로 세 가지 패턴이 따라옵니다.

일방향 게이트. 신뢰를 결정하는 코드는 경로, 사용자의 클릭, 그리고 작업 공간 외부에 있는 ~/.claude.json에 저장된 신뢰 상태만 읽습니다.¹⁵ 그 외에는 아무것도 읽지 않습니다. 작업 공간 파일이 신뢰 결정에 기여하는 모든 리팩터링은 회귀입니다.

경로 해석을 통한 전이적 신뢰 금지. 선호되는 불변 조건은 워크트리, 서브모듈, 포함 파일, 심볼릭 링크 대상이 각각 자신의 프롬프트를 받는 것입니다. 반면 Visual Studio Code의 워크스페이스 트러스트는 상위 폴더 신뢰가 하위 폴더에도 적용되도록 허용하며, 이러한 선택은 경로 해석이 위조될 때 ~/Projects 같은 광범위한 상위 경로 신뢰가 악용되는 부분입니다. 더 엄격한 규칙은 약간의 추가 대화상자를 감수하지만 전이적 신뢰 표면 전체를 제거합니다. 더 느슨한 규칙은 마찰을 낮게 유지하지만 경로 해석 버그가 신뢰 해석 버그가 된다는 사실을 받아들입니다.¹¹

신뢰 읽기 순서 회귀 테스트의 적대적 픽스처. 카나리 작업 공간 파일을 커밋하는 의도적으로 조작된 적대적 저장소입니다. 테스트는 대화상자가 확인되기 전에 어떤 코드 경로도 그 카나리들을 읽지 않는다고 단언합니다. 만약 런타임에 대한 향후 변경이 신뢰 평가 도중 어떤 카나리 파일이라도 읽으면 빌드가 실패합니다. 신뢰 경계 위반을 의미하는 CWE-501은, 공개된 권고문이 이미 사용하는 더 구체적인 CWE-807과 CWE-20/CWE-77 분류와 함께 테스트 분류 체계에서 추적할 가치가 있는 더 넓은 부류입니다.¹⁶

세 가지 모두 비용이 크지 않습니다. 첫 번째는 코드의 부재입니다. 두 번째는 사용자에게 보이는 마찰을 비용으로 합니다. 세 번째는 한 번의 엔지니어링 작업과 그 이후의 규율입니다. 신뢰 부트스트랩 손상은 통상의 심층 방어 자세가 적용되지 않는 부류입니다. 신뢰 하위의 모든 계층은 작업 공간이 방금 만들어내는 데 일조한 신뢰 결정을 기반으로 실행되기 때문입니다. 신뢰 외부에서의 방어는 비계 계층에서 구축하기가 불가능합니다. 비계는 신뢰가 해석되는 순간 작업 공간이 읽게 되는 바로 그것이기 때문입니다.

공급사가 이 불변 조건을 출시해야 합니다. 신뢰 대화상자 우회 CVE는 관찰자가 공급사가 그 기준을 충족하는지 측정하는 방식입니다. 6주에 두 건은 잡음이 아닙니다. 그것은 빌드가 강제하는 단언으로서 그 불변 조건이 테스트 슈트에 인코딩되지 않았다는 신호입니다. 인코딩되기 전까지, 이 부류의 다음 CVE는 열 번째 입력을 찾는 시간 문제일 뿐입니다.

저장소가 자신의 신뢰 여부에 투표할 수 있어서는 안 됩니다. 신뢰는 평가 대상인 산출물이 결정에 도움을 줘서는 안 되는 단 하나의 결정입니다. 에이전트의 다른 모든 방어 계층(훅, 스킬, 검증기, 탐지기, 가드)은 그 단 한 번의 투표 하위에 존재합니다. 투표가 조작되면 하위의 작업은 가구일 뿐입니다. 캐비닛의 마감면이 뒷면을 구해주지는 못합니다.

FAQ

Claude Code 신뢰 대화상자 우회란 무엇인가요?

Claude Code 신뢰 대화상자 우회는 사용자가 명시적으로 승인하기 전에 신뢰되지 않은 작업 공간이 신뢰된 것으로 처리될 때 발생합니다. 2026년 3월 CVE에서는 저장소가 제어하는 설정이 신뢰가 평가되기 전에 권한 모드에 영향을 미쳤습니다. 2026년 4월 CVE에서는 조작된 git 워크트리/commondir 레이아웃이 이미 신뢰된 경로를 통해 신뢰가 해석되도록 만들었습니다.

~/.claude.json에서 신뢰된 경로를 어떻게 좁혀야 하나요?

~/.claude.json을 열어 projects 맵을 살펴보세요. hasTrustDialogAccepted가 true로 되어 있는 항목 중에서, 더 이상 활성 코드가 없는 디렉터리, ~/Projects 같은 광범위한 상위 경로, 워크트리 인접 레이아웃과 겹치는 모든 경로를 찾으세요. 저장소별 신뢰는 대화상자를 늘리지만, 승인된 하나의 상위 경로가 모든 자식을 조용히 포괄하는 일을 방지합니다.

Claude Code에서 상위 경로 신뢰가 위험한 이유는 무엇인가요?

상위 경로 신뢰가 위험한 이유는 승인된 디렉터리 하나가 여러 자식 작업 공간을 포괄할 수 있기 때문입니다. 경로 해석이 위조되거나 악의적인 워크트리가 그 상위 경로를 다시 가리키면, 자식 저장소는 부여된 적 없는 신뢰를 상속받을 수 있습니다. 저장소별 신뢰는 마찰을 더하지만, 관련 없는 저장소들 사이의 전이적 신뢰를 방지합니다.

어떤 불변 조건이 신뢰 대화상자 우회를 방지하나요?

불변 조건은 다음과 같습니다. 사용자가 작업 공간 경로를 명시적으로 신뢰하기 전까지는 작업 공간 내부의 어떤 바이트도 해석하지 않는다는 것입니다. 신뢰 코드는 경로, 사용자의 클릭, 저장소 외부에 저장된 신뢰 상태를 읽을 수 있습니다. 대화상자 이전에는 .claude/settings.json, CLAUDE.md, .mcp.json, 훅, 스킬, commondir, 또는 저장소가 제어하는 어떤 파일도 읽어서는 안 됩니다.

참고 문헌