두 번은 깨끗했고 세 번째에 악성으로 바뀌었습니다. 일회성 검토로는 잡히지 않습니다.
악성 MCP 서버는 검토를 통과할 필요가 없습니다. 검토가 끝날 때까지 기다리기만 하면 됩니다.
Deadbugz라는 이 캠페인은 Pillar Security가 2026년 8월 공개한, 현재도 활동 중인 MCP 공급망 공격입니다. 서버는 첫 두 번의 도구 호출에는 정상으로 응답하다가 세 번째 호출에서 동작을 바꿉니다. 호출 횟수를 조건으로 삼는 이 방식은 아무리 꼼꼼하게 설치 시점을 점검해도 잡아낼 수 없게 설계돼 있습니다.
정상 호출 두 번 다음에 벌어진 일
Deadbugz는 productivity-suite라는 패키지로 배포되며, 광고한 그대로 작동하는 도구 두 개를 제공합니다. format_text와 summarize입니다. 에이전트가 처음 두 번 호출할 때는 둘 다 깨끗하게 실행됩니다. 서버는 클라이언트별로 tools/call 요청 횟수를 메모리에 세어 두다가, 그 값이 정확히 3에 이르는 순간 tools/list와 prompts/get 응답 내용을 바꿉니다. Pillar는 이를 "런타임 게이팅 방식의 MCP 메타데이터 포이즈닝"이라고 부릅니다(Pillar Security, "Deadbugz: currently active MCP supply-chain campaign").
세 번째 호출 이후 바뀐 도구 메타데이터는 연결된 에이전트에게 SSH 키, AWS 자격증명, 셸 히스토리, Kubernetes 설정 파일을 찾아보라고 지시하고, 이 활동을 사용자에게 숨기라고까지 지시합니다(Pillar Security). 처음 두 번의 호출만 봐서는 리뷰어가 이 일을 예상할 방법이 없었습니다. 숨겨 둔 난독화 페이로드도 없고, 의심을 살 만한 권한 요청도 없습니다. 서버는 그저 아직 3에 도달하지 않았을 뿐입니다.
배포 방식도 그만큼 치밀했습니다. 2026년 8월 10일, zellkernel이라는 GitHub 계정이 74분 만에 서로 무관한 AI·MCP·개발자 도구 저장소들에 풀 리퀘스트 23건을 올렸습니다. 이 중 17건은 원격 MCP 엔드포인트를 연결했고, 4건은 숨겨진 로컬 스크립트 경로를 참조했으며, 2건은 디렉터리 목록으로 위장했습니다(Pillar Security). 19건은 닫혔고, 나머지 4건은 Pillar가 검토한 시점까지 열려 있었습니다.
NHI Mgmt Group은 자체 분석에서 이 캠페인이 노리는 실패 지점을 짚습니다. "런타임 재검증 없는 도구 승인은 통제하고 있다는 착각을 만든다"고 말합니다. 메커니즘을 두고는 이렇게 덧붙입니다. "세 번째 호출이라는 문턱은 악의 없는 점검이 악성 상태 변화를 얼마나 쉽게 놓칠 수 있는지 보여준다."(NHI Mgmt Group, "Deadbugz shows how MCP metadata poisoning evades AI agent trust")
무관한 CVE 세 건, 같은 교훈
Deadbugz는 의도된 기만입니다. 같은 달 공개된 MCP 서버 CVE 세 건을 보면, 도구가 광고한 기능을 정직하게 수행할 때도 비슷한 실패가 나타납니다. 설치 시점 검토를 통과했다고 해서 조건에 맞는 입력으로 호출이 실제 실행될 때도 코드가 안전하게 동작한다는 뜻은 아닙니다(adversa.ai, "MCP security September 2026: Deadbugz + 3 server CVEs").
정상 기능을 통한 경로 순회(path traversal). CVE-2026-73498은 Atlassian의 mcp-atlassian 서버에서 발생합니다. confluence_upload_attachment 도구가 검증되지 않은 file_path를 그대로 open(file_path, "rb")에 넘기며, 그 사이에 경로 안전성 검사가 없습니다. 인증된 MCP 클라이언트라면 서버 프로세스가 접근할 수 있는 모든 파일을 읽어 Confluence 첨부파일로 돌려받을 수 있습니다. 서버 자체의 Confluence API 토큰 같은 환경변수도 예외가 아닙니다. CVSS 3.1 기준 7.7점, High 등급입니다. mcp-atlassian 0.22.0에서 수정됐습니다.
설정 읽기 도구 뒤에 숨어 있던 평문 토큰. CVE-2026-67357은 ArcadeDB의 MCP 서버에서 발생합니다. get_server_settings 도구는 키에 "password"가 들어간 설정값은 가려서 보여주지만, arcadedb.ha.clusterToken은 이 패턴에 걸리지 않아 평문 그대로 반환됩니다. 이 토큰은 클러스터 내부에서 노드 간에 전달되는 인증의 신뢰 앵커이며, 올바른 HTTP 헤더로 재전송하면 root 권한을 사칭할 수 있습니다. CVSS 3.1 기준 7.5점, High 등급입니다(CVSS 4.0: 7.7). ArcadeDB 26.7.3에서 수정됐습니다.
페이지네이션 헬퍼에서 시작되는 서버 사이드 요청 위조(SSRF). CVE-2026-19956은 facebook-ads-mcp-server에서 발생합니다. fetch_pagination_url 함수를 거치면 인증된 원격 사용자가 서버 자체의 네트워크 위치에서 원하는 URL로 요청을 띄울 수 있습니다. 서버에는 보이지만 호출자에게는 원래 닿지 않아야 할 내부 서비스까지 도달합니다. CVSS 3.1 기준 6.3점, Medium 등급입니다(CVSS 4.0: 5.3). 커밋 한 건으로 수정됐습니다.
세 도구 모두 악성이 아니라 이름 그대로 작동합니다. 취약한 패턴은 검증되지 않은 경로, 빈틈이 있는 마스킹 규칙, 목적지를 확인하지 않는 요청처럼 처음부터 코드에 있었습니다. 그러나 도구의 등록 정보나 이름만으로는 그 패턴이 문제라는 점을 알 수 없습니다. 트리거 조건에 맞는 입력으로 호출해야 실제 동작이 드러납니다. 조작된 file_path, 토큰까지 포함해 버리는 설정 읽기, 내부 주소를 겨냥한 페이지네이션 URL이 그런 경우입니다.
일반화되는 것과 그렇지 않은 것
네 사례의 공통점은 설치 시점 검토만으로 실제 호출의 결과를 알 수 없다는 데 있습니다. Deadbugz의 트리거는 리뷰어가 읽을 수 있는 코드가 아니라 런타임에 쌓이는 상태에 있습니다. CVE 세 건은 다릅니다. 취약한 패턴은 처음부터 코드에 있었지만, 설치 검토만으로 특정 악성 입력이 들어왔을 때의 동작까지 확인할 수는 없습니다. 검토를 통과한 도구도 조건에 따라 첫 번째 호출부터, 또는 세 번째 호출에서 잘못될 수 있습니다.
클라이언트가 볼 수 있는 도구를 좁히는 통제도 필요합니다. 다루는 질문이 다를 뿐, 이 공백을 메우지는 못합니다. Deadbugz의 format_text와 summarize는 범위 제한(scoping) 검토를 통과할 도구입니다. 이름과 처음 두 번의 호출에서 배제할 근거가 없기 때문입니다. 등록이 끝난 뒤 실제 호출이 실행되는 순간에는 여전히 공백이 남습니다.
MCP 서버에서 나타나는 또 다른 런타임 실패 사례는 AutoJack: 웹페이지 하나, MCP 소켓 하나, 호스트 수준 접근에서 다룹니다. 지연 트리거 도구가 아니라 인증되지 않은 로컬 전송 계층에서 발생한 사례입니다.
Alpacon이 다루는 범위
Alpacon은 모든 MCP 도구 호출에 점수를 매기지 않습니다. get_server_settings 같은 설정 읽기나 format_text 같은 텍스트 포맷팅은 호스트에 명령을 내리지 않으므로 위험 점수 대상이 아닙니다. 점수가 붙는 경우는 에이전트가 호출한 도구가 호스트에서 실제로 명령을 실행할 때입니다. 그 명령은 exec lane을 거치고, 여기서 3단계 엔진이 평가합니다. 규칙 기반으로 걸러내고, 기준선을 통과하는지 보고, 그레이존은 LLM이 판단합니다. risk lane이 그레이존으로 분류하면, 그 명령은 실행되기 전에 별도 채널의 사람 승인을 위해 보류될 수 있습니다.
이 범위로는 Deadbugz의 메타데이터 포이즈닝 트리거를 잡아내지 못했을 것입니다. 페이로드가 호스트 명령이 아니라 도구 메타데이터에 담긴 지시이기 때문입니다. Alpacon은 실제 실행이 일어나는 지점만 판단합니다. 도구 호출 자체가 아니라 그 호출이 호스트 명령으로 이어지는 순간입니다.
자주 묻는 질문
일회성 MCP 서버 검토만으로 충분할까요?
Deadbugz 같은 호출 횟수 트리거에는 통하지 않습니다. 그 상태는 세 번째 호출 전까지는 코드 어디에도 존재하지 않기 때문입니다. 도구가 광고한 기능 안에 숨은 CVE도 믿고 넘기기는 어렵습니다. 취약한 패턴 자체는 찾을 수 있지만, 그것이 실제로 악용 가능한지 확인하려면 함수를 한 번 읽는 것을 넘어 트리거 조건에 맞는 입력과 함께 호출이 실행될 때 무슨 일이 벌어지는지까지 따라가야 합니다. 일회성 검토도 명백히 악성인 코드와 이미 알려진 악성 패키지는 여전히 걸러냅니다. 그것만으로 충분하지 않을 뿐입니다.
런타임 판단이 도구 동작을 지켜본다면, 클라이언트가 등록할 수 있는 MCP 도구를 제한할 필요가 여전히 있을까요?
네. Deadbugz가 그 이유를 보여줍니다. 등록 시점의 범위 제한은 애초에 등록해서는 안 되는 도구를 막습니다. Deadbugz는 이미 그 단계를 통과했습니다. format_text와 summarize는 별다른 의심 없이 등록된 뒤 세 번째 호출까지 조용히 기다렸습니다.
이 CVE 세 건은 MCP 서버가 본질적으로 안전하지 않다는 뜻일까요?
MCP 프로토콜 자체가 망가졌다는 뜻은 아닙니다. MCP 서버 생태계가 아직 초기 단계라 충분한 감사를 거치지 못했다는 뜻입니다. 세 건 모두 수정판이 나왔고, 호출이 실제로 무엇을 하는지 확인했다면 원리상 발견할 수 있던 결함이었습니다. 도구 이름만으로는 부족합니다.
보안팀이 새 MCP 서버를 평가하는 방식에서 무엇이 달라져야 할까요?
열 번째 호출에서 무슨 일이 벌어지는지 물어야 합니다. 첫 번째 호출까지만 묻고 멈추면 놓칩니다. 코드 리뷰와 체인지로그 확인은 필요하지만 그것만으로는 부족합니다. 승인 시점에 한 번 확인하고 끝내는 대신, 호출 시점마다 도구의 동작을 지속적으로 재검증하는 장치가 있는지 확인해야 합니다.
다음에 확인할 것
다음에 MCP 서버가 검토를 통과하면, 그 검토가 무엇을 확인했는지 따져 봐야 합니다. "코드를 읽어봤고 문제없어 보였다"는 평가는 한 시점의 한 가지 입력 조합을 본 결과일 뿐입니다. 그것도 여전히 해볼 만한 일입니다. 다만 호출이 일어난 뒤의 동작까지 안다는 뜻은 아닙니다. Deadbugz와 같은 달 공개된 CVE 세 건은 이 공백이 실제로 악용될 수 있음을 보여줍니다.
