13개의 AI 에이전트 프레임워크에서 56개 이상의 보안 취약점(6개의 치명적인 RCE) 발견 — 체계적인 감사 (Systematic Auditing)를 통해 배운 점

AI 에이전트 생태계는 보안 관행이 따라잡을 수 없을 정도로 빠르게 성장하고 있습니다. 지난 6주 동안, 우리는 CrewAI, AutoGen, AG2, LlamaIndex, Haystack, LiteLLM, Semantic Kernel, LangChain, Dify, FastMCP, MCP Python SDK, Griptape, 그리고 Docker MCP를 포함한 13개 이상의 주요 AI 에이전트 프레임워크(AI agent frameworks)에 대해 체계적인 보안 감사(Systematic security audit)를 실시했습니다. 결과는 엄중했습니다. MSRC, ZDI, HackerOne, 그리고 GitHub Security에 책임 있는 공개(Responsibly disclosed)를 완료한 7개를 포함하여 56개 이상의 검증된 보안 취약점이 발견되었습니다. 그중 6개는 CVSS 점수가 9.8 또는 9.3인 원격 코드 실행 (RCE, Remote Code Execution) 취약점입니다. 하나는 기존의 가드레일(Guardrail) 보호를 우회하는 치명적인 SSRF(Server-Side Request Forgery)입니다.

이것은 이론적인 연습이 아닙니다. 여기에 나열된 모든 취약점은 작동하는 개념 증명(PoC, Proof of Concept)을 통해 검증되었으며, 가능한 경우 공식 버그 바운티(Bounty) 채널을 통해 제출되었습니다. 일부는 Microsoft의 보안 응답 센터(Security Response Center)로부터 당일 응답을 받기도 했습니다.

책임 있게 공개된 7가지 취약점

1. CrewAI MCP StdioTransport RCE (CVSS 9.8)

CrewAI의 StdioTransport.__init__() 메서드는 사용자 제어 명령 문자열을 검증 없이 stdio_client()에 직접 전달합니다. 악의적인 명령을 가리키는 모든 MCP 서버 설정은 임의의 OS 프로세스 실행을 유발합니다. CrewAI는 우리가 테스트한 주요 프레임워크 중 가장 취약했습니다. 허용 목록(Allowlist)도, 입력값 정제(Input sanitization)도, 아무것도 없었습니다. 우리는 이를 MSRC에 제출하여 당일 케이스 번호(126356)를 받았습니다. 현재 이는 CVE-2026-2287로 추적되고 있습니다.

2. AutoGen Studio RCE (CVSS 9.8)

2. AutoGen Studio RCE (CVSS 9.8)

Microsoft AutoGen의 magentic-one-cli는 경로 검증(path validation) 없이 Python의 open() 함수로 직접 전달되는 --config 파라미터를 허용합니다. 이는 captainagent에서 발생하는 AutoGen의 exec() 사용(MSRC에 보고된 또 다른 RCE)과 결합되어, 공격자가 설정 파일 경로를 제어할 수 있다면 호스트에 대한 완전한 원격 코드 실행 (RCE)을 달성할 수 있습니다. 저희는 경로 탐색 (path traversal) 노출과 함께 두 가지 벡터 모두를 MSRC에 제출했습니다.

3. AG2 eval() __str__ 우회 RCE (CVSS 9.8)

AG2 (AutoGen의 커뮤니티 포크)는 에이전트 그룹 채팅 중 문자열 보간 (string interpolation)을 위해 context_expression.py에서 eval()을 사용합니다. 코드는 이스케이프 (escape) 문자열 값을 처리하지만, 사용자 정의 __str__() 메서드를 구현하는 객체는 해당 이스케이프 메커니즘을 완전히 우회합니다. 소스 코드에는 심지어 "사용자 정의 __str__ 주입은 범위 외 (out of scope)이다"라고 명시적으로 인정하는 주석이 포함되어 있습니다. 정교하게 제작된 __str__ 메서드를 가진 LLM 제어 context_variables 값은 추가적인 익스플로잇 (exploit) 단계 없이 완전한 RCE를 유발합니다. GitHub Issue #3073로 접수되었습니다.

4. LlamaIndex Pickle 역직렬화 (Deserialization) RCE (CVSS 9.8)

LlamaIndex의 Workflows 직렬화기 (serializer)는 pickle.loads(base64.b64decode(value))를 호출합니다. 이는 가장 널리 사용되는 LLM 오케스트레이션 (orchestration) 프레임워크 중 하나를 대상으로 하는 전형적인 pickle RCE입니다. PickleSerializer는 워크플로 상태 지속성 (state persistence)을 위한 기본 직렬화기 중 하나로 등록되어 있어, 중간 상태를 직렬화하는 모든 워크플로가 취약할 수 있음을 의미합니다. 악의적인 워크플로 정의는 역직렬화 시점에 임의 코드 실행을 트리거합니다. GitHub Issue #22296으로 접수되었습니다.

5-6. Haystack 파이프라인 역직렬화 RCE (CVSS 9.8 및 9.3)

Haystack 2.31.0에는 두 개의 독립적인 역직렬화 RCE 경로가 있으며, 둘 다 치명적입니다.

첫 번째 (CVSS 9.8): Pipeline.loads()는 YAML 또는 JSON 입력으로부터 임의의 Python 클래스를 동적으로 임포트하기 위해 import_class_by_name()을 호출합니다. thread_safe_import()에 이어 getattr(module, class_name)이 실행되는 체인은 공격자에게 클래스 인스턴스화 (instantiation)에 대한 완전한 제어권을 부여하며, 모듈 허용 목록 (allowlist)이 강제되지 않습니다.

두 번째 (CVSS 9.3): deserialize_callable("os.system")는 호출 가능한 os.system 함수 객체를 직접 반환합니다. 이 역직렬화된 호출 가능 객체(deserialized callable)는 Tool.from_dict() 및 OutputAdapter.from_dict()에 의해 사용되므로, 직렬화된 도구 정의를 로드하는 모든 파이프라인이 하이재킹될 수 있습니다. 어떠한 타입 제한(type restrictions)이나 모듈 허용 목록 (module allowlists)도 적용되지 않습니다.

7. LiteLLM Guardrail SSRF (CVSS 8.6)

LiteLLM의 가드레일 훅 (guardrail hook) 시스템은 URL을 검증하기 위해 is_valid_url()을 사용하지만, 이 함수는 구문 검사 (syntax check)만 수행합니다. 플랫폼은 DNS 확인 (DNS resolution), IP 블랙리스트 확인, URL 재작성 (URL rewriting)을 수행하는 validate_url()을 별도로 제공하지만, 가드레일의 http_request() 경로에서는 이 함수가 결코 호출되지 않습니다. 이러한 격차로 인해 가드레일 설정을 주입할 수 있는 공격자는 구문 검사만 통과한 URL을 통해 클라우드 메타데이터 엔드포인트 (169.254.169.254), Azure Wire Server, 그리고 내부 네트워크 서비스에 접근할 수 있습니다. GitHub Issue #32862로 보고되었습니다.

문제의 규모

이 7가지 공개 사항은 훨씬 더 큰 발견의 일부분일 뿐입니다. Correctover CCS (Call Correctness Standard) v1.0 탐지 엔진을 사용한 자동 스캐닝 결과, 오탐 (false positive) 필터링 및 수동 PoC 검증을 거친 후 13개 이상의 프레임워크에서 56개 이상의 확인된 취약점을 식별했습니다.

취약점이 발생하는 가장 큰 단일 원인은 우리가 **MCP readOnlyHint 격차 (readOnlyHint gap)**라고 부르는 것입니다. modelcontextprotocol/python-sdk는 도구에 읽기 전용 의도를 나타내는 readOnlyHint 불리언 (boolean) 값을 정의하지만, 런타임 (runtime)에서 이를 강제하지 않습니다. 모든 다운스트림 (downstream) 프레임워크가 이 깨진 계약 (broken contract)을 상속받습니다. 우리는 AutoGen, Semantic Kernel, FastMCP, Dify, Griptape, 그리고 MCP Python SDK 자체를 포함한 6개 프레임워크에서 보호되지 않은 도구 호출 (unguarded tool invocation) 사례 87개를 실제 운영 코드에서 발견했습니다. readOnlyHint는 런타임 상의 결과가 전혀 없는 단순한 문서 역할만 수행합니다.

readOnlyHint 격차 외에도, 세 가지 취약점 패턴이 프레임워크 전반에 걸쳐 일관되게 나타났습니다:

• 도구 인자 주입 (Tool argument injection): 프레임워크가 LLM이 생성한 도구 호출 인자(tool call arguments)를 검증이나 이스케이프(escaping) 처리 없이 subprocess.Popen()과 같은 OS 레벨 함수로 직접 전달합니다. 이는 CrewAI에서 가장 심각하게 나타났으나(완화 조치 없음), LiteLLM(우회 가능한 허용 목록 방식)에서도 발견되었습니다.
• 설정 로더에서의 경로 탐색 (Path traversal in config loaders): CLI 인자 및 설정 파일 내의 사용자 제어 파일 경로가 open() 호출로 직접 전달됩니다. AutoGen과 Dify 모두 CVSS 9.8 수준의 이 패턴을 가지고 있었습니다.
• 환경 변수 유출 (Environment variable leakage): CLI 도구가 os.environ을 자식 프로세스에 전달하여 API 키와 비밀 정보(secrets)를 유출합니다. MCP Python SDK와 FastMCP에서 발견되었습니다.

발견 방법: 방법론 (Methodology)

감사 프로세스는 자동 스캐닝과 수동 검증을 결합합니다:

1. 24개의 CCS 탐지 규칙 (24 CCS detection rules) — 6개월간의 에이전트 프레임워크 분석을 통한 실제 취약점 연구를 바탕으로 컴파일되었습니다. 각 규칙은 특정 익스플로잇 클래스(exploit class)를 대상으로 합니다: eval/exec 오용, 안전하지 않은 역직렬화 (pickle, yaml.load, import_by_name), subprocess 주입, 경로 탐색 (path traversal), SSRF, 그리고 환경 변수 유출.
2. 이중 경로 탐지 (Dual-path detection) — AST 스캐닝은 구조적 패턴(예: eval(), pickle.loads(), subprocess.Popen()에 대한 함수 호출)을 식별하며, 정규 표현식(regex) 검증은 알려진 익스플로잇 시그니처와 교차 확인합니다. 이 이중 경로 접근 방식은 오탐(false positives)을 크게 줄여줍니다.
3. PoC 기반 분류 (PoC-gated classification) — 모든 후보 발견 사항은 확인된 취약점으로 분류되기 전에 작동하는 개념 증명(PoC, proof of concept)을 거칩니다. PoC로 검증된 발견 사항만이 최종 집계에 포함됩니다.

24개의 탐지 규칙은 github.com/Correctover/standards에 있는 CCS v1.0 표준의 일부로 공개되어 있습니다. 함께 제공되는 오픈 데이터셋에는 13개의 LLM 제공업체와 33개의 모델로부터 수집된 20,000개의 프로덕션 API 트레이스(traces)가 포함되어 있으며, 이는 실제 API 측정을 통해 수집된 총 80,000개 트레이스 코퍼스(corpus)의 일부입니다.

런타임 검증 지연 시간(Runtime verification latency)은 P50=22 마이크로초(100만 개의 샘플을 통해 측정)로, 인지할 수 있는 오버헤드 없이 프로덕션 에이전트 호출 경로(call paths)에 삽입하는 것이 가능합니다.

이것이 프로덕션 환경의 AI 에이전트에게 중요한 이유

우리가 발견한 취약점들은 우려스러운 공통 패턴을 공유하고 있습니다. 즉, 이들은 모호한 엣지 케이스(edge cases)가 아닙니다. 에이전트 프레임워크가 LLM으로부터 오는 신뢰할 수 없는 입력(untrusted input)을 처리하는 방식에 존재하는 근본적인 아키텍처적 격차(architectural gaps)입니다.

우리가 테스트한 모든 프레임워크는 LLM의 출력이 권위적(authoritative)이라고 가정합니다. 아키텍처는 "LLM이 말하는 내용"을 신뢰할 수 있는 것으로 취급하며, 중간에 검증 계층(verification layer) 없이 이를 도구 실행(tool execution)으로 직접 라우팅합니다. 이는 웹 애플리케이션에서 사용자 입력에 대해 eval()을 실행하는 것과 같으며, 보안 업계에서는 이미 20년 전에 더 이상 용납하지 않게 된 관행입니다.

보안 조치를 구현한 프레임워크들 — LiteLLM의 허용 목록(allowlist), AutoGen의 부분적인 완화 조치(partial mitigations) — 도 알려진 우회 방법(bypasses)이 존재하여 일관성 없게 적용되고 있습니다. MCP의 readOnlyHint가 가장 명확한 사례입니다. 이는 프로토콜 명세(protocol specification)에 정의된 보안 계약(security contract)이지만 런타임(runtime)에서는 전혀 강제되지 않아, 개발자들에게 잘못된 안전감을 제공합니다.

에이전트 프레임워크가 내부 API, 데이터베이스, 파일 시스템 및 코드 실행 권한을 가진 채 프로덕션 환경에서 실행될 때, 이러한 취약점 하나하나가 잠재적인 데이터 유출이나 호스트 전체의 침해(full host compromise)로 이어질 수 있습니다.

런타임 호출 검증: 누락된 보안 계층

AI 에이전트 생태계에 필요한 것은 취약점이 발견된 후에 프레임워크별로 보안 패치를 추가하는 것이 아닙니다. 어떤 프레임워크를 사용하든 상관없이 정책을 강제할 수 있도록, LLM과 도구 실행 사이의 실행 경로(execution path)에 위치하는 **검증 계층(verification layer)**이 필요합니다.

Correctover CCS SDK는 이를 동기식 인터셉터(synchronous interceptor)로 구현합니다. 즉, 도구가 실행되기 전에 @govern() 데코레이터(decorator)가 정책에 따라 모든 도구 호출(tool call)을 검증합니다. 옵저버 패턴(observer-pattern) 훅(hook)과는 다릅니다(옵저버 패턴 훅은 콜백을 생성할 뿐 실행을 차단하지 못하며, 이는 우리가 감사한 모든 주요 프레임워크에서 발견된 CWE-636 fail-open 패턴입니다). CCS 인터셉터는 실행 경로(execution path) 자체에서 작동합니다. 거버넌스(governance)가 충돌하면 도구 실행이 차단됩니다. 즉, fail-open이 아닌 fail-closed 방식으로 작동합니다.

이 SDK는 단 2~4줄의 코드만으로 CrewAI, AutoGen, LangChain, LangGraph와 통합됩니다. CCS v1.0 표준, 탐지 규칙(detection rules), 그리고 통합 키트(integration kit)는 모두 github.com/Correctover에서 오픈 소스로 제공됩니다.

우리가 발견한 56개 이상의 취약점은 타인의 문제만이 아닙니다. 만약 여러분이 오늘날 내부 API, 데이터베이스 또는 코드 실행 권한을 가진 AI 에이전트를 프로덕션(production) 환경에 배포하고 있다면, 여러분 또한 동일한 공격 표면(attack surfaces)에 노출되어 있습니다. 문제는 여러분의 프레임워크에 이러한 취약점이 있느냐가 아니라, 이러한 취약점이 프로덕션에 도달하기 전에 이를 잡아낼 수 있는 런타임 검증 계층(runtime verification layer)을 갖추고 있느냐입니다.

본 연구는 Correctover 보안 연구팀에 의해 수행되었습니다. 책임 있는 공개(Responsible disclosure) 일정 및 개별 권고(advisory) 세부 사항은 github.com/Correctover/standards 및 github.com/Correctover/mcp-security-audit에서 확인할 수 있습니다.