MCP 에이전트 간 통신을 노린 프로토콜 피버팅 취약점이 드러났다

Ars Technica4일 전조회 3

AI 에이전트를 내부망에 붙여 쓰는 조직이라면 MCP(Model Context Protocol) 구성를 다시 점검할 시점이다. 한 에이전트에 심어진 악성 지시가 다른 에이전트로 넘어가 그대로 실행되는 공격이 실제 조직 다섯 곳에서 확인됐다. 보안 업계에서 '프로토콜 피버팅(protocol pivoting)'이라 부르는 이 기법은 LLM 자체가 아니라 번역이나 데이터 분석처럼 특정 목적만 수행하는 에이전트를 겨냥한다.

독립 연구자 사이드 아나스 모히우딘은 구글, JP모건체이스, 위비에이트, 래피드7, 프랑스 정부의 부처 간 디지털 담당국, 미국 연방정부 등의 에이전트를 대상으로 개념 증명 공격을 수행했다. 이들 조직은 AI 에이전트를 쓴다는 것 외에 공통점이 거의 없다. 그런데도 같은 방식이 통했다는 점이 이 사안의 무게를 만든다.

출발점은 프롬프트 인젝션이지만 겨냥 대상이 LLM이 아니라 체인 중간의 에이전트라는 점이 다르다. 특수 목적 에이전트에는 가드레일이 없거나 있어도 느슨한 경우가 많다. 악성 텍스트를 읽은 에이전트는 그것을 정상적인 위임 작업으로 판단해 다음 에이전트로 넘기고, 다음 에이전트는 앞의 에이전트를 신뢰하기 때문에 지시를 그대로 따른다. MCP 서버가 에이전트별 자격 증명을 보관하고, 에이전트는 내부의 다른 에이전트를 무조건 신뢰하도록 만들어져 있어 LLM 단계에서 걸렸을 지시가 통과된다.

모히우딘이 래피드7 네트워크에서 찾아낸 취약점에는 CVE-2026-97228이 부여됐다. 심각도는 10점 만점에 2.7로 낮은 편이었고 지난달 수정됐다. 반면 구글 쪽 취약점은 심각도 8로 훨씬 높았다. 데이터베이스용 MCP 툴박스(googleapis/mcp-toolbox)가 HTTP 클라이언트를 초기화하면서 CheckRedirect 정책을 적용하지 않았고, 대상 IP 주소 검증도 빠져 있었다. 조작된 경로 파라미터를 넣으면 툴박스가 내부 엔드포인트로 리다이렉트를 따라가 공격자를 대신해 요청을 보내게 되는데, 이는 전형적인 서버 측 요청 위조(SSRF)다. 구글은 IP 대역 허용 목록과 차단 목록을 적용하고, 첫 요청 시점이 아니라 시작 시점에 안전하지 않은 베이스 URL을 거부하도록 고쳤다.

모히우딘이 '프로토콜 피버팅'이라는 이름을 붙인 이유는 공격이 프로토콜 경계를 넘어가기 때문이다. 앱이나 서버가 MCP로 에이전트에 작업을 할당하고, 그 에이전트가 구글의 A2A(Agent-to-Agent) 프로토콜이나 에이전트 네트워크 프로토콜 같은 다른 통신 방식으로 악성 지시를 다음 에이전트에 전달하는 과정에서 신뢰와 인가 정보가 사실상 사라진다. 그는 이를 하나의 프로토콜로 초기 접근을 얻고 프로토콜 간 신뢰 가정을 악용해 다른 프로토콜로만 닿을 수 있는 권한으로 확대하는 다단계 공격이라고 규정한다.

명칭에는 이견도 있다. X41 D-Sec 연구원 마르쿠스 베르비어는 더 정확한 용어는 여전히 프롬프트 인젝션이며 프로토콜 피버팅은 그 하위 분류에 불과하다고 본다. 악성 프롬프트가 다른 프로토콜에서 와서 또 다른 프로토콜을 통해 발현되는 것이 이런 공격이 성립하기 위한 필수 조건은 아니라는 것이다. 다만 예상 밖의 경로로 나타나 방어가 어렵다는 점은 인정한다.

배경에는 MCP의 빠른 확산이 있다. MCP는 나온 지 얼마 되지 않았는데 이미 내부망 곳곳에 들어가 있고, 충분히 검증되고 단단해지기 전에 퍼졌다. 조직들이 에이전트 아키텍처를 급하게 키우면서 제로 트러스트 원칙도 함께 밀어낸 상태다. 제로 트러스트는 네트워크 노드 일부가 이미 감염됐을 수 있다고 가정하고, 민감한 트랜잭션 전에는 반드시 인가를 요구하도록 설계하는 모델이다.

개발자에게 실무적 결론은 분명하다. LLM에서 도구로 넘어오는 모든 입력은 인터넷에서 온 낯선 사람의 입력처럼 다뤄야 한다. 프롬프트 인젝션 상황에서 그것은 실제로 그렇다. 근본 원인은 인젝션과 SSRF 같은 오래된 결함이고 해법도 20년째 크게 달라지지 않았다. 다만 에이전트 체인에서는 각 구성 요소가 설계대로 정상 동작하기 때문에 문제를 잡아내기가 더 어렵다. 각 프로토콜은 독립적으로 동작한다고 가정하고 설계됐기 때문에, 프로토콜 사이 구간을 지켜보는 주체가 없다는 점이 이 문제를 놓치게 만든다.

전제도 짚어야 한다. 공격이 통했다는 사실은 확인됐지만 이것이 모든 MCP 배포 환경에 똑같이 적용된다는 뜻은 아니다. 취약점별 심각도 평가도 2.7과 8로 크게 갈렸다. MCP 기반 에이전트 아키텍처를 운영한다면 에이전트 간 위임 경로에서 인가가 실제로 검증되는지, 아웃바운드 요청이 허용 목록으로 제한되는지부터 확인하는 것이 순서다.