ClaudeBleed — Claude for Chrome Extension, origin만 믿다가 권한 0짜리 Extension에 탈취된 신뢰 경계

한 줄 요약

Anthropic의 Chrome Extension Claude for Chrome(v1.0.69 이하)에서 권한이 전혀 없는 다른 Extension 하나가, 사용자 동의 한 번 없이 Claude 에이전트를 통째로 빌려 Gmail·Google Drive·GitHub의 데이터를 조회하고 외부로 빼낼 수 있는 신뢰 경계 위반 결함이 공개됐다.

LayerX Security가 2026-05-07에 공개했고, 발견자가 붙인 이름은 ClaudeBleed다. 2014년 OpenSSL의 Heartbleed, 2017년 Cloudflare의 Cloudbleed 계보를 잇는 “데이터가 새어 나온다"는 작명을 오마주했다. Anthropic은 하루 앞선 5월 6일 v1.0.70으로 부분 패치를 배포했지만, 같은 연구자가 약 3시간 만에 우회 경로를 찾아 함께 공개했다. 5월 13일 현재까지 추가 패치는 발표되지 않았으며, CVE 번호도 아직 할당되지 않았다.

요약 표

근본 원인 — externally_connectable이 신뢰하는 건 누구인가

Chrome Extension 매니페스트의 externally_connectable 키는 “이 Extension의 메시지 채널을 누가 호출해도 되는가"를 선언한다. 보통 두 가지 형태로 쓴다.

// 형태 A — 다른 Extension ID로 한정
{
  "externally_connectable": {
    "ids": ["<신뢰하는 Extension ID>"]
  }
}

// 형태 B — 특정 웹 출처(origin)로 한정
{
  "externally_connectable": {
    "matches": ["*://*.claude.ai/*"]
  }
}

Claude for Chrome은 두 번째 형태로, claude.ai 출처에서 실행되는 페이지 스크립트가 Extension에 메시지를 보낼 수 있도록 열어 뒀다. 사용자 입장에서 Claude 사이드 패널과 claude.ai가 한 몸처럼 동작해야 하니, 설계 의도는 자연스럽다.

문제는 origin이 답할 수 있는 질문의 범위다. origin은 “이 코드가 어느 페이지 컨텍스트에서 실행되는가"는 알지만, “그 컨텍스트 안에서 누가 그 코드를 실행시켰는가"는 모른다. Chrome의 Extension 모델은 임의의 Extension이 자기 content script를 다른 출처의 페이지에 주입할 수 있게 허용하며, 매니페스트의 "world": "MAIN" 옵션을 켜면 그 스크립트는 페이지 자체의 자바스크립트 컨텍스트에서 돈다.

여기서 권한 0짜리 Extension이란, manifest.json에 permissions(tabs, storage, cookies 등)도 host_permissions(https://mail.google.com/* 같은 사이트 접근 권한)도 적지 않은 Extension을 말한다. 사용자가 설치할 때 “이 Extension은 ~ 권한이 필요합니다” 같은 경고 화면이 거의 뜨지 않거나 가장 가벼운 형태로만 뜬다. 그런데 content_scripts 항목은 권한 요청이 아니라 “어떤 페이지에서 이 자바스크립트를 실행해 달라"는 등록이라, 별도 권한 없이도 매니페스트에 적은 origin(여기서는 *://*.claude.ai/*)에 자기 스크립트를 끼워 넣을 수 있다.

즉 권한 0짜리 Extension 하나가:

1. content script로 claude.ai에 스크립트를 한 장 주입하고,
2. 그 스크립트가 페이지 컨텍스트에서 chrome.runtime.sendMessage("<Claude Extension ID>", {...}) 한 줄을 실행하면,
3. Claude Extension 입장에서는 “claude.ai에서 들어온 정상 메시지"로 보인다.

Claude Extension의 ID(fcoeoabgfenejglbffodgkkbkcdhcgfn)는 Chrome Web Store에 그대로 공개돼 있고, Extension ID는 비밀이 아니다. 결과적으로 origin 화이트리스트는 ACL이 아니라 누구나 통과시키는 표지판에 가깝다.

LayerX는 이 호출로 도달 가능한 핸들러 중 하나로 onboarding_task를 지목했는데, 이 핸들러는 외부에서 받은 텍스트를 그대로 Claude의 작업 프롬프트로 흘려보낸다. 즉 메시지 한 통이면 임의 프롬프트 실행과 같다.

공격 사슬

전체 동작은 한 장으로 정리된다.

flowchart TD
    EXT["악성 Extension
(권한 0)"]
    CS["content script
MAIN world 주입"]
    PAGE["claude.ai
페이지 컨텍스트"]
    MSG["chrome.runtime
.sendMessage"]
    CLAUDE["Claude Extension
외부 메시지 수신"]
    PROMPT["onboarding_task
임의 프롬프트"]
    DOM["DOM 라벨 위장"]
    LOOP["승인 루핑
(Yes, proceed)"]
    PRIV["Privileged 모드
우회"]
    DATA["Gmail / Drive
GitHub 작업"]

    EXT -- "1. 주입" --> CS
    CS -- "MAIN world" --> PAGE
    PAGE -- "2. 메시지" --> MSG
    MSG -- "origin만 검증" --> CLAUDE
    CLAUDE -- "3. 실행" --> PROMPT
    DOM -. "라벨 변조" .-> PROMPT
    LOOP -. "자동 동의" .-> PROMPT
    PRIV -. "확인 생략" .-> PROMPT
    PROMPT -- "4. 호출" --> DATA

핵심 한 줄로 요약하면, Extension ID와 origin만 알면 누구나 Claude 에이전트의 작업 큐에 작업 항목을 추가할 수 있다. 이제 그 다음 단계인 “어떻게 사용자 몰래 그 작업을 끝까지 수행하게 만드는가"가 4가지 공격 기법으로 나뉜다.

4가지 공격 기법

1. Confused Deputy — 신뢰의 대상이 잘못 잡혔다

Claude Extension은 “claude.ai에서 온 메시지면 정상"이라는 전제로 동작한다. 그러나 실제 메시지를 만든 주체는 사용자가 띄운 claude.ai 페이지가 아니라, 사용자가 설치해 둔 다른 Extension이 페이지 위에 얹어 놓은 스크립트다. 정당한 권한을 가진 대리인(Claude Extension)이 자기 권한 밖의 호출자(악성 Extension)를 위해 일하게 되는, 교과서적인 confused deputy 구도다.

이 구도가 위험한 이유는 권한 상승의 비용이 0이라는 점이다. 공격 Extension은 호스트 권한도, 탭 권한도, storage도 필요 없다. content script 하나만 선언하면 끝난다.

2. 승인 루핑(Approval Looping) — 동의가 행동이 아니라 상태에 묶여 있다

Claude는 민감한 작업을 수행하기 전 사용자에게 확인을 받는 단계를 거친다. 그런데 그 확인이 “지금 이 특정 행동에 대한 동의"가 아니라 “지금 사용자가 활성화한 모드"로만 검사되기 때문에, 같은 채널로 “Yes, proceed"에 해당하는 메시지를 반복 전송하면 확인 흐름을 그대로 통과시킬 수 있다.

토큰이 행동에 바인딩돼 있지 않다는 게 본질이다. 한 번 받은 동의가 다음 동의가 필요한 자리에서 다시 통한다면, 그 동의는 사실상 동의가 아니다.

3. DOM 라벨 위장 — 에이전트의 “눈"이 곧 DOM이다

Claude 에이전트는 페이지의 DOM을 읽어 어떤 버튼이 무슨 동작인지 판단한다. 악성 Extension이 DOM을 살짝 바꿔 두면 — 예를 들어 “외부에 공유” 버튼의 라벨을 “피드백 요청"으로 — 에이전트의 인식과 실제 동작이 어긋난다. 에이전트는 무해한 작업으로 알고 누르지만, 실제 클릭은 원래 핸들러를 그대로 부른다.

이 기법은 ClaudeBleed에만 국한되지 않는, 브라우저 안에서 도는 모든 AI 에이전트의 일반 약점에 가깝다. 에이전트가 의미를 DOM에서 끌어내는 한, DOM을 만질 수 있는 쪽이 의미를 다시 정의할 수 있다.

4. Privileged Mode 우회 — v1.0.70 패치가 왜 안 먹히는가

Claude for Chrome은 두 가지 모드를 둔다. Ask before acting(매 행동마다 확인)과 Act without asking(자율 수행). v1.0.70 패치는 Ask 모드에서 외부 메시지가 임의 행동을 일으키지 못하도록 사이드 패널 안에 명시적 승인 흐름을 추가했다.

하지만 LayerX는 공격자가 사이드 패널의 초기화 흐름을 가로채 Act without asking 쪽으로 진입시키는 우회 경로를 약 3시간 만에 확인했다. 모드 전환이 사용자에게 통보되지 않기 때문에, 사용자는 자기 Extension이 자율 모드로 돌고 있는지 알 길이 없다.

요약하면 패치는 증상(승인 UI 흐름)을 가렸을 뿐 원인(메시지 발신자 신원 검증 부재)을 손대지 못했다. 발신자가 누구인지 모르면 어느 모드에서든 결국 길은 열린다.

위협 시나리오 — 무엇이 가능한가

이 결함이 가능하게 만드는 작업은 평범한 사용자 시나리오로 옮기면 그대로 사고로 이어진다.

• Gmail의 받은편지함을 요약시켜 외부 주소로 메일 발송
• Google Drive 비공개 문서에 공유 링크를 발급해 외부 노출
• GitHub 비공개 리포지토리의 파일 내용을 챗 응답에 끼워 빼내기
• 사용자 대신 메일 발송, 문서 삭제로 흔적 정리
• 외부 캘린더 초대, Slack 메시지 발송 같은 OAuth 권한 위임 작업 일반

세 가지가 함께 성립한다는 점이 무겁다. 공격 Extension에 별도 권한이 필요 없다, 사용자 상호작용이 필요 없다, EDR/안티바이러스 관점에서 정상 Extension의 정상 호출처럼 보인다.

특히 사내 표준 브라우저에 권장 Extension 목록만 통제하는 조직에서는, Claude for Chrome이 그 권장 목록에 있고 사용자가 자율적으로 다른 Extension 하나를 추가했다는 사실만으로 위협 모델이 무너진다.

공개 타임라인

보고에서 패치까지 9일, 패치에서 우회 공개까지 1일이다. 빠르게 막은 흔적은 있지만, “신뢰 경계 자체를 다시 그리는” 종류의 수정은 그 사이에 들어가지 못한 모양새다.

사용자가 오늘 할 일

근본 패치가 발표되기 전까지, 권장 조치는 단순하다.

1) Claude for Chrome Extension을 끄거나 제거한다

chrome://extensions 에서 Claude for Chrome 항목의 토글을 끄는 것만으로 공격 표면이 즉시 사라진다. 자주 안 쓴다면 제거가 가장 깔끔하다. 데스크톱 클라이언트나 웹 claude.ai 사용에는 영향이 없다.

2) 못 끄겠다면, 민감 세션과 분리한다

Claude for Chrome을 켜 둔 프로파일에는 Gmail·Google Drive·GitHub 같은 민감 서비스에 로그인하지 않는다. Chrome 프로파일 분리(다른 사용자) 또는 별도 브라우저(Chrome Canary, Firefox 등)로 일·개인 작업과 AI 에이전트 작업을 분리해 둔다.

3) 다른 Extension도 함께 점검한다

ClaudeBleed의 트리거는 “다른 Extension 하나"다. 사용 중인 Extension의 수와 신뢰도를 같이 본다.

chrome://extensions  →  세부 정보  →  사이트 액세스 / 권한

설치 출처가 불분명하거나, 더 이상 안 쓰는 Extension은 이 기회에 정리해 둔다. content script 권한이 광범위한 Extension(예: <all_urls>)일수록 위험 가중치가 높다.

4) 조직 단위 통제가 가능한 경우

ChromeOS·Chrome Enterprise 환경에서는 ExtensionInstallBlocklist로 Claude for Chrome Extension ID(fcoeoabgfenejglbffodgkkbkcdhcgfn)를 막거나, ExtensionInstallAllowlist로 허용 Extension 목록을 좁힌 뒤 차차 풀어 가는 방식이 안전하다. BYOD 환경이면 사용자 공지와 함께 자율 비활성화를 권고한다.

정리

• ClaudeBleed의 본질은 코드 한 줄짜리 버그가 아니라, origin이 신원이라고 착각한 설계다. Chrome Extension 모델이 허용하는 content script + MAIN world 조합 앞에서 origin 화이트리스트는 ACL 노릇을 못 한다.
• v1.0.70 패치는 승인 UI 흐름을 추가했지만, 메시지 발신자 신원 검증 부재라는 원인은 그대로다. 그래서 Act without asking 모드를 강제 진입시키는 우회 경로가 같은 날 다시 열렸다.
• 에이전트가 강할수록 그 신뢰 경계의 모양은 더 정밀해야 한다. 발신자 인증(서명 토큰, Extension ID 화이트리스트), 행동-바인딩된 일회성 동의가 합쳐져야 비로소 동의가 동의로 기능한다.
• 추가 패치 전까지는 Claude for Chrome 사용을 잠시 멈추는 게 가장 단순하고 확실한 완화다. 끌 수 없다면 민감 세션과 프로파일을 분리한다.

이번 사건이 Anthropic만의 문제로 끝나지 않을 가능성도 함께 짚어 둔다. 브라우저 안에서 도는 AI 에이전트 Extension은 모두 같은 함정(외부 메시지 채널, DOM을 통한 의미 인식, 자율 모드의 UX/보안 트레이드오프) 위에 서 있다. ClaudeBleed는 그 함정 중 첫 번째 사례로 기록될 공산이 크다.

참고

• LayerX Security — A Flaw in Claude’s Browser Extension Allows Any Extension to Hijack It — ClaudeBleed 원 공시
• SecurityWeek — Vulnerability in Claude Extension for Chrome Exposes AI Agent to Takeover — 사건 요약과 Anthropic 대응
• Cybernews — Researcher hacks Claude Code Chrome fix in 3 hours — 3시간 우회 보도
• Hackread — ClaudeBleed Vulnerability Lets Hackers Hijack Claude Chrome Extension to Steal Data — 연구자 코멘트 포함
• Chrome Developers — externally_connectable — 매니페스트 키 공식 문서