오픈소스 AI 에이전트 플랫폼 루플로, 인증 없는 MCP로 원격 코드 실행 뚫림

• 오픈소스 AI 에이전트 플랫폼 루플로에서 꽤 센 취약점이 나왔음. 이름은 루프루트, 식별번호는 CVE-2026-59726이고 루플로 3.16.3 이전 버전이 영향권임

  • 깃허브 기준 CVSS 3.1 점수는 만점인 10.0
  • 노마시큐리티의 연구조직 노마랩스가 발견했고, 루플로 유지관리자는 통보 후 24시간 안에 수정판을 냈음
  • 루플로는 2026년 7월 기준 깃허브 스타 약 6만6000개, 노마랩스 추산 다운로드 약 1000만회, 활성 이용자 약 100만명 규모로 소개된 플랫폼임

• 문제의 핵심은 MCP 브리지가 인증 없이 열려 있었다는 점임

  • 루플로의 기본 Docker Compose 배포 설정에서 MCP 브리지 3001번 포트와 MongoDB가 모든 네트워크 인터페이스에 바인딩됐음
  • 실제 외부 노출 여부는 방화벽이나 보안그룹 설정에 따라 달라지지만, 기본 구성만 보면 사고 나기 좋은 모양새였음
  • POST /mcp와 POST /mcp/:group 엔드포인트에는 토큰, API 키, 헤더 검사, IP 허용목록 같은 인증 절차가 없었음

• 더 무서운 건 이 MCP 브리지가 그냥 챗봇용 API가 아니라는 거임. 셸, DB, 에이전트, 기억 저장소까지 만지는 233개 도구가 HTTP로 열려 있었음

  • 연구진은 POST /mcp에 인증 없는 단일 HTTP 요청을 보내 terminal_execute 도구를 호출함
  • 그 결과 MCP 브리지 컨테이너 안에서 Node 사용자 권한으로 임의의 셸 명령이 실행됐음
  • 관련 약점으로는 중요 기능 인증 누락, 운영체제 명령 삽입, 과도한 CORS 정책이 지목됐음

• 노마랩스의 개념증명은 꽤 현실적인 순서로 진행됐음
  • AWS EC2에 루플로 기본 배포 환경을 만들고 tools/list로 233개 도구를 확인함
  • 이후 셸 명령을 실행하고 외부 서버와 통신해 원격 코드 실행을 검증함
  • 컨테이너 환경변수에 저장된 OpenAI, Anthropic, Google, OpenRouter 같은 AI 공급자 API 키에도 접근했음

sequenceDiagram
    participant 공격자
    participant MCP브리지
    participant 컨테이너
    participant MongoDB
    participant 기억저장소
    공격자->>MCP브리지: 인증 없는 POST /mcp 요청
    MCP브리지->>컨테이너: terminal_execute 도구 실행
    컨테이너-->>공격자: 셸 명령 결과 반환
    공격자->>컨테이너: 환경변수에서 API 키 조회
    공격자->>MongoDB: 대화와 메타데이터 추출
    공격자->>기억저장소: 악성 패턴 기록

• 피해 범위가 단순 코드 실행에서 끝나지 않는 게 이번 사건의 포인트임

  • 공격자는 탈취한 자격증명과 피해 시스템의 연산자원을 써서 자기 통제 아래 있는 AI 에이전트 군집을 만들 수 있었음
  • MongoDB에는 인증이 없어 저장된 대화, 제목, 메타데이터를 추출해 외부로 보낼 수 있었음
  • /app 디렉터리에 재접속용 파일을 만들고 컨테이너 재시작 때 다시 불러오게 한 뒤 셸 명령 기록을 지우는 흐름도 검증됐음

• 특히 “지속형 AI 기억 오염”이 골치 아픈 지점임

  • 공격자가 AgentDB 학습 저장소에 악성 패턴을 기록하면, 취약점 패치 이후에도 에이전트가 그 기억을 참고할 수 있음
  • 연구진은 배포 스크립트에 공격자 소유 인터넷주소를 넣도록 유도하는 가짜 규제준수 정책을 예시로 들었음
  • 그러니까 서버만 업데이트했다고 “끝”이 아니라, 에이전트의 기억 저장소까지 뒤져야 함

• 루플로 3.16.3은 기본 보안값을 꽤 강하게 바꿨음

  • MCP 브리지는 기본적으로 로컬호스트에만 바인딩됨
  • 관리자가 외부 공개를 명시적으로 선택하면 인증 토큰을 요구함
  • 셸 명령 도구는 기본 비활성화됐고, 관리자가 따로 켜야 쓸 수 있음
  • MongoDB는 시작 단계부터 인증과 루트 비밀번호를 요구함
  • 컨테이너에는 읽기 전용 실행과 임시 파일시스템이 적용됐고, CORS도 허용목록 방식으로 바뀜

• 이미 취약한 버전을 외부에 노출했다면 확인할 게 많음

  • 3001번 포트와 27017번 포트가 외부에 열려 있었는지 먼저 봐야 함
  • 루플로에 저장한 AI 공급자 API 키는 유출 가능성을 전제로 교체해야 함
  • MongoDB의 대화, 제목, 메타데이터, 저장 정보가 무단 열람되거나 변경됐는지 확인해야 함
  • AgentDB에서는 승인되지 않은 agentdb_pattern-store 항목이 있는지 봐야 함
  • 기존 컨테이너에 남은 변경 사항을 믿지 말고 깨끗한 이미지로 다시 구축하는 쪽이 맞음

• 이 사건은 기업 내부의 섀도우 AI 문제와도 이어짐

  • 개발자나 업무팀이 자체 호스팅한 루플로를 보안팀이 모를 수 있음
  • 이런 도구가 사내 API 키와 대화 데이터, 자동화 권한을 들고 있으면 노출 한 번으로 영향 범위가 커짐
  • 이제 AI 에이전트 점검은 “어떤 모델 쓰냐”가 아니라 “어떤 도구에 연결돼 있고, 어디까지 실행 권한이 있냐”를 봐야 하는 단계임

기술 맥락

• 이번 선택의 핵심은 MCP 브리지를 외부에 열어두면서 인증을 붙이지 않았다는 데 있어요. MCP는 에이전트가 도구를 쓰게 만드는 통로라서, 셸 실행이나 DB 접근 같은 강한 권한이 연결되면 일반 API보다 훨씬 위험해져요.

• 루플로 3.16.3이 로컬호스트 기본 바인딩으로 바꾼 이유도 여기에 있어요. 외부 공개가 필요한 사용자는 명시적으로 선택하고 토큰 인증을 붙이게 만들어야, 기본 설치만 한 개발자 환경이 바로 인터넷 노출 지점이 되는 일을 줄일 수 있거든요.

• 셸 명령 도구를 기본으로 끈 것도 중요한 변경이에요. AI 에이전트 플랫폼에서는 자동화를 위해 셸 접근이 매력적이지만, 인증이나 권한 분리가 약하면 그 기능이 곧 원격 코드 실행 취약점으로 바뀌어요.

• 복구가 패치 설치로 끝나지 않는 이유는 지속형 기억 때문이에요. 공격자가 AgentDB에 악성 패턴을 심어두면 바이너리나 컨테이너를 고쳐도 에이전트가 오염된 기억을 계속 읽을 수 있어서, 데이터 무결성 점검이 보안 업데이트만큼 중요해져요.