pile·
보안·gitlab-engGitLab Blog·

Serena MCP 에이전트의 치명적 원격 코드 실행 취약점 분석

GitLab 보안팀이 AI 코딩 에이전트 Serena(월 PyPI 다운로드 13.6만 건)에서 치명적 원격 코드 실행 취약점을 발견했다. Jinja2 비샌드박스 환경과 신뢰 모델의 미검사 경로가 결합해 개발자가 악의적 저장소를 열기만 해도 코드가 실행된다. serena-agent 1.7.0에서 SandboxedEnvironment 교체로 수정 완료됐다.

핵심 포인트
  • Serena는 Claude, Cursor 등 AI 어시스턴트가 로컬 코드베이스를 탐색·편집하도록 MCP 서버로 동작해 개발자 OS 권한 전체를 가짐
  • jinja2.Environment()(비샌드박스)가 프로젝트 설정 파일에서 오는 사용자 제어 문자열을 렌더링해 임의 코드 실행 가능
  • .serena/project.yml의 added_modes 경로 항목이 신뢰 검사(is_trusted()) 없이 로드되어 템플릿 주입 경로 형성
  • 신뢰 게이트(activation_command 차단)는 작동했으나 템플릿 주입 경로는 게이트 적용 외 → 보호 메커니즘 우회(CWE-693)
  • 저장소 클론 후 Serena로 열기만 해도 LLM에 첫 응답 전 코드 실행됨
상세 정리
  • MCP 서버 위협 모델: CI/CD는 격리 환경·범위 자격증명으로 동작하는 반면, MCP 서버는 개발자 로컬 머신의 SSH 키·클라우드 자격증명·.env 파일·브라우저 세션까지 접근 가능한 권한으로 실행됨
  • Serena 아키텍처: 로컬 MCP 서버로 실행되며 trusted_project_path_patterns로 신뢰 저장소 정의. activation_command(프로젝트 오픈 시 쉘 명령)는 신뢰 저장소에서만 허용
  • 취약 소스: src/interprompt/jinja_template.py에서 jinja2.Environment() 생성(샌드박스 없음). Python 객체 그래프를 타고 os·subprocess에 도달하는 기법은 잘 알려진 방식
  • 주입 경로: added_modes에 경로 유사 문자열 지정 시 context_mode.py:130-135의 load()가 해당 파일을 읽고 prompt 필드를 비샌드박스 렌더러에 전달. yaml.safe_load는 YAML 역직렬화 가젯을 차단하지만 렌더링 단계는 관여하지 않음
  • 신뢰 우회: is_trusted() 검사는 activation_command와 ls_specific_settings에만 적용. added_modes 처리 경로는 검사 대상 외 → 신뢰 설정 empty여도 템플릿 주입은 자유롭게 실행됨
  • 완전한 공격 체인: .serena/project.yml(공격자 제어) → SerenaAgentMode.load() → JinjaTemplate.render() → 임의 코드 실행. 코드는 Serena가 LLM에게 첫 응답 전에 실행됨
  • 영향 범위: GitHub 스타 27,800개, PyPI 월 13.6만 다운로드. Claude Code·Cursor·VS Code·JetBrains·Claude Desktop·OpenWebUI 통합
  • 공격 시나리오: 공격자가 라이브러리·샘플 프로젝트·CTF 도전 등을 공개하고, 개발자가 클론 후 Serena로 열면 코드 실행. CI 환경에서 저장소를 자동 처리 시 인간 상호작용도 불필요
  • 근본 원인 패턴 3가지: ① 사용자 데이터를 비샌드박스 템플릿 엔진에 직접 전달, ② 저장소 설정 파일을 신뢰 입력으로 취급, ③ 신뢰 게이트가 일부 경로만 적용하고 신규 경로 추가 시 검토 누락
  • 공개 타임라인: 2026-08-01 취약점 발견·제보 → 2026-08-05 수락 → 2026-08-09 serena-agent 1.7.0 수정 배포(GHSA-pp25-4cg4-qcr9)
왜 읽나MCP 서버 개발자·AI 코딩 도구 개발자·보안팀이 로컬 에이전트의 신뢰 모델 설계 시 반드시 점검해야 할 템플릿 주입 취약점의 실전 분석 사례.
gitlab-eng
GitLab Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 보안·cloudflare-blogCloudflare Blog·

    내부 앱을 한 번에 보호하기 — Cloudflare Access for Workers

    Cloudflare가 Workers에 Access를 직접 연결해 내부 애플리케이션을 도메인 단위가 아닌 Worker 단위로 보호하는 기능을 출시했다. 개발자가 각자 Access를 설정하지 않아도 계정 수준에서 모든 Workers를 기본 비공개로 만들 수 있고, 코드에서 인증된 사용자 정보를 JWT 파싱 없이 바로 꺼낼 수 있다.

    요약 이어보기
    #zero-trust#authentication#serverless+2