Google MCP Toolbox 취약점: 셀프 호스팅 AI 사용자가 확인해야 할 사항

표지 이미지: Google Cloud — MCP Toolbox 아키텍처.

CVE-2026-93328은 구체적인 소프트웨어 권고를 홈 서버의 더 큰 문제와 연결합니다. AI 도구 서비스가 에이전트에 요청된 작업의 범위를 넘어서는 파일 및 클라우드 스토리지 권한을 보유할 수 있다는 점입니다. 모든 MCP 서버가 동일한 결함을 공유한다고 가정하지 말고, 정확히 영향받는 구성요소부터 확인하세요.

이 가이드는 공개된 사건과 실제 구현을 구분합니다. 소프트웨어 소스에서 확인되는 내용과 근거의 한계를 설명하고, 뛰어난 모델이나 최신 서버가 제한된 액세스 및 검토의 필요성을 없앤다고 가정하지 않고 비공개 파일 워크플로를 평가하는 방법을 안내합니다.

권고문은 어떤 소프트웨어를 설명하나요?

GitHub Advisory Database 항목은 Google Cloud MCP Toolbox for Databases의 클라우드 스토리지 소스에서 경로 순회 및 권한 부재 문제가 발생한다고 설명합니다. 영향받는 버전 범위는 특정 구성요소에 한정됩니다. 관련 없는 MCP 구현, 해당 소스를 전혀 실행하지 않는 커넥터 또는 다른 버전은 각각 별도로 평가해야 합니다. 애플리케이션 표시 이름만 보고 추정하는 대신 비교 내용을 검증할 수 있도록 설치된 이미지 다이제스트, 릴리스 태그 및 구성을 보존하세요.

확인 시 데이터베이스 항목은 미검토로 표시되어 있었으므로, 완성된 공급업체 배포 권고로 제시해서는 안 됩니다. 해당 항목의 참조를 따라 업스트림 저장소로 이동해 현재 릴리스 노트와 비교하세요. 링크된 풀 리퀘스트에는 버킷 및 로컬 경로 제한이 추가되어 있지만, 더 이른 병합 날짜가 공개 날짜인 것은 아닙니다. 프로젝트가 이번 주에 모든 문제를 처음으로 해결했다고 기록하면 근거를 왜곡하게 됩니다.

업데이트는 왜 경계를 구성하는 여러 요소 중 하나일 뿐인가요?

업데이트된 이미지에 제어 기능이 포함되어 있어도 설정이 지나치게 관대하거나, 불필요한 마운트가 있거나, 광범위한 권한을 가진 클라우드 자격 증명을 사용하고 있을 수 있습니다. 설정 이름만 보고 배포 환경의 권한이 제한되어 있다고 가정하지 말고 실제 적용 구성을 검토하세요. 도구가 호스트 파일 시스템을 읽고 원격 버킷에 쓸 수 있다면 모델 자체가 다른 곳에서 호스팅되더라도 데이터 전송 경로가 생깁니다. 도구가 접근할 수 있는 범위는 도구를 실행하는 주체에 따라 결정됩니다.

로컬 루트, 버킷 접근 권한, 런타임 사용자, 네트워크 노출을 목록화하세요. 전용 작업 디렉터리와 특정 목적에만 사용하는 서비스 계정을 우선 사용하세요. 프로세스가 가족 기록 보관소나 관련 없는 클라우드 버킷에 접근할 수 없다면, 도구 호출을 잘못해도 오용될 수 있는 권한은 줄어듭니다. 제한은 프롬프트 계층 아래에서 적용되어야 합니다. 운영체제 권한, 컨테이너 마운트, 클라우드 IAM은 에이전트가 요청을 오해하거나 검색된 콘텐츠에 악의적인 지시가 포함되어 있을 때도 유효한 보호 장치입니다.

연결된 업스트림 풀 리퀘스트에는 allowedBuckets와 allowedLocalRoot가 명시되어 있고, 기본값이 관대하다는 점이 언급되어 있습니다. 배포된 소스의 실제 적용 값을 확인하세요. 최신 바이너리에서 해당 설정을 볼 수 있다는 사실만으로 배포 환경의 권한이 제한되어 있음을 입증할 수는 없습니다. 같은 기록에서는 6월의 1.5.0 릴리스도 언급하므로, 최근 공개된 권고를 10월에 새로 병합된 수정 사항이라고 설명해서는 안 됩니다.

공격을 재현하지 않고 노출 여부를 확인하는 방법

먼저 구성과 런타임 메타데이터를 확인하세요. 배포된 소스 유형과 정확한 버전, 그리고 신뢰할 수 없는 네트워크에서 엔드포인트에 접근할 수 있는지 파악하세요. 그런 다음 스테이징 환경에서 일회용 테스트 데이터로 허용된 로컬 루트와 버킷을 확인하세요. 과도한 권한을 가진 자격 증명이나 마운트가 있는지 확인하는 데 프로덕션 비밀 정보를 전송하거나 데이터 유출 과정을 재현할 필요는 없습니다.

로그 또는 기타 증거에서 무단 활동이 의심되면 정기 정리 전에 관련 기록을 보존하고 노출된 서비스와 연결된 자격 증명을 교체하세요. 버전을 업그레이드해도 복사된 키를 무효화하거나 이미 시스템 밖으로 나간 파일을 회수할 수는 없습니다. 개선 조치 기록은 탐색적 테스트 기록과 분리하고, 변경 후 정상적인 워크플로가 작동하는지 확인하세요. 목표는 단순히 컨테이너가 성공적으로 다시 시작되는 것이 아니라, 권한 범위가 명확하게 제한된 도구 서비스입니다.

이 워크플로를 신뢰하기 전에 무엇을 측정해야 하나요?

배포된 각 인스턴스의 노출 기록을 작성하세요. 이미지 다이제스트, 소스 설정, 런타임 ID, 마운트된 경로, 클라우드 ID, 접근 가능한 엔드포인트를 기록합니다. 구성 요소가 설치되어 있는지와 영향을 받은 소스가 활성화되어 있는지는 구분하세요. 컨테이너 레이블이나 잠금 파일에 나열된 패키지는 유용한 단서이지만, 실행 중인 프로세스에서 어떤 설정이 활성화되어 있는지는 알려 주지 않습니다. 각 결론에 도달할 때 사용한 증거를 보존하세요.

무해한 테스트 데이터로 통제 기능을 평가하세요. 전용 테스트 루트 내에서 허용된 작업은 성공해야 하고, 해당 루트 밖의 요청은 부적절한지 모델이 판단하도록 하지 않아도 실제 통제 기능에 의해 거부되어야 합니다. 버킷 범위와 IAM에도 같은 원칙을 적용하세요. 디스크에 있는 설정 파일만으로 통제가 적용된다고 추정하지 마세요. 서비스가 해당 파일을 불러왔는지, 배포 시 재정의 설정으로 의도한 제한 범위가 넓어지지 않았는지 확인하세요.

결과를 검토하고 복구할 수 있게 하려면 어떻게 해야 하나요?

노출이 의심되면 타임라인을 기록하는 운영상 사건으로 다루세요. 정기적인 정리 작업을 하기 전에 관련 액세스 로그, 배포 기록, 자격 증명 식별자를 보존하되, 해당 기록에 대한 불필요한 접근은 제한하세요. 확인된 사실과 아직 확인할 수 없는 사항을 기록하세요. 취약한 버전이 존재한다고 해서 데이터에 접근했음이 입증되는 것은 아니며, 찾기 쉬운 로그 항목이 없다고 해서 접근이 불가능했음이 입증되는 것도 아닙니다.

복구 방법은 영향을 받은 권한 주체에 따라 다릅니다. 노출된 소스를 제한하거나 비활성화하고, 필요한 경우 취약한 소프트웨어를 교체하고, 관련된 자격 증명을 교체하며, 덮어쓴 파일은 필요하면 신뢰할 수 있는 사본에서 복원하세요. 그런 다음 권한을 축소한 상태에서도 일반적인 승인 작업이 계속 작동하는지 검증하세요. 조치 후 배포된 다이제스트와 실제 적용되는 허용 목록을 기록하세요. 업그레이드하면 실행 코드가 바뀔 수 있지만, 지나치게 광범위한 마운트나 허용적인 기본 설정 또는 이미 노출된 자격 증명이 바로잡히는 것은 아닙니다.

중요한 파일에 사용하기 전에 워크플로를 어떻게 테스트할 수 있나요?

다음은 편집 검증 프로토콜이며, ZimaSpace가 해당 서비스를 벤치마크했다는 주장이 아닙니다. 폐기 가능한 테스트 데이터나 사용 승인을 받은 테스트 데이터로 실행하고, 테스트 조건을 결과와 함께 보관하세요.

1. 실행 중인 구성 요소와 영향받는 소스의 목록을 작성하세요. 배포된 버전을 권고 범위와 비교하고, 정확한 이미지 다이제스트와 구성 ID를 보존하세요.
2. 권고 내용과 업스트림 변경 사항을 함께 확인하세요. 공개 날짜와 이전 구현 이력을 구분하고, 업데이트 버전을 선택하기 전에 최신 릴리스 정보를 확인하세요.
3. 실제 권한 범위를 파악하세요. 로컬 루트 디렉터리, 컨테이너 마운트, 런타임 권한, 버킷 범위, IAM 및 엔드포인트 도달 가능성을 점검하고, 의도된 작업에 필요하지 않은 권한을 식별하세요.
4. 스테이징 환경에서 폐기 가능한 테스트 데이터로 제한을 검증하세요. 프로덕션 비밀 정보를 테스트 요청에 넣지 말고 허용되거나 거부되는 경로와 버킷을 확인하세요.
5. 활동이 의심되면 증거를 보존하고 노출된 자격 증명에 대응하세요. 사고 관련 관찰 내용과 가정을 바탕으로 한 탐색적 테스트를 구분하세요.
6. 문제 해결 후 일반적인 승인 절차에 따라 다시 작업을 수행하세요. 변경 사항을 독립적으로 검토할 수 있도록 최종 버전, 로드된 구성 및 적용 결과를 기록하세요.

ZimaOS 서버는 어디에 적합한가요?

프로젝트에 여러 드라이브, SSD 작업 계층 또는 증가하는 아카이브에 대한 공유 액세스가 실제로 필요한 경우 ZimaCube 2 개인용 클라우드 NAS를 로컬 스토리지 및 애플리케이션 계층으로 활용할 수 있습니다. 보관할 원본 데이터, 활성 서비스 및 백업 정책을 고려해 하드웨어를 선택하세요. 이 제품 추천은 아키텍처 측면의 참고 정보일 뿐, 이 클라우드 모델, 프리뷰 서비스 또는 연구 시스템이 NAS에서 로컬로 실행된다는 근거는 아닙니다.

추론과 데이터 보관을 분리하세요. 호스팅 모델에는 승인된 발췌본을 전달하면서 원본 데이터는 서버에 보관할 수 있습니다. 선택적 로컬 인덱싱, 변환 또는 소형 모델 서비스에는 각각 별도의 메모리 및 컴퓨팅 평가가 필요합니다. 복구 가능한 사본을 주 장치 외부에 하나 더 보관하고, RAID나 업로드 성공을 완전한 백업 전략으로 간주하지 마세요. 기존의 소형 서버가 측정된 작업 부하를 이미 처리할 수 있다면 계속 사용해도 괜찮습니다.

자주 묻는 질문

이 권고의 영향은 모든 MCP 서버에 미치나요?

아니요. 언급된 항목은 googleapis/mcp-toolbox 버전 1.2.0–1.4.0의 클라우드 스토리지 소스를 설명합니다. 다른 구현과 배포 환경은 각각 별도로 평가해야 합니다.

이미지를 업데이트하면 문제가 완전히 해결되나요?

업데이트는 평가의 일부일 뿐입니다. 실제로 적용되는 로컬 루트 및 버킷 제한, 마운트된 경로, 런타임 ID와 클라우드 자격 증명을 확인하세요. 최신 바이너리도 과도한 권한으로 작동할 수 있습니다.

프로덕션 데이터를 대상으로 파일 내보내기를 재현해야 하나요?

설정 근거와 무해한 스테이징 테스트 데이터를 사용해 노출 범위를 평가하세요. 지나치게 광범위한 마운트, ID 또는 허용 목록을 검증하는 데 프로덕션 비밀 정보나 비공개 파일은 필요하지 않습니다.

비공개 아카이브 전체를 AI 도구에 공개해야 하나요?

적절히 제한된 계정이나 작업 디렉터리를 사용해 작업에 필요한 자료만 제공하세요. 해당 서비스가 어떤 데이터를 업로드하고, 기록하고, 보존하는지 확인하세요. 비공개 스토리지 위치에 있다고 해서 연결된 도구의 처리가 로컬에서 이루어진다는 보장은 없습니다.

더 큰 NAS는 언제 유용한가요?

측정된 원본 데이터 증가량, 공유 액세스, 활성 애플리케이션 또는 보존 요구 사항에 따라 스토리지 토폴로지가 필요하다고 판단될 때입니다. 그렇다고 모델 액세스, 지원되지 않는 런타임, 네트워크 업로드 한도 또는 조사 결과의 불확실성이 자동으로 해결되는 것은 아닙니다.

프로덕션 사용 전 중단 조건은 무엇인가요?

소프트웨어/모델의 정체, 입력 권한, 필요한 기능의 사용 가능 여부 또는 복구 경로를 확인할 수 없다면 중단하세요. 먼저 해당 조건을 해결한 다음 소규모 테스트를 반복하세요. 근거가 부족하다고 해서 권고를 더 확신에 찬 어조로 제시하지 마세요.

출처 및 참고 자료

• 공식 발표 또는 권고
• 상위 클라우드 스토리지 액세스 제어 변경 사항
• 상위 프로젝트 릴리스

2026년 10월 28일 기준으로 보고 내용을 확인했습니다. 제품 재고, 액세스 플랜 및 보안 권고는 변경될 수 있습니다. 상위 출처의 주장은 해당 출처를 명시했으며, 워크플로 권장 사항과 아키텍처 사례는 편집상의 분석이지 ZimaSpace 하드웨어 테스트를 통한 측정 결과가 아닙니다.

관련 가이드: 셀프 호스팅 AI 에이전트는 읽기 전용 파일 시스템 뷰를 통해 작동할 수 있을까요?.

관련 가이드: 에이전트 권한이 필요한 도구 작업만 허용하는지 테스트하는 방법.

관련 가이드: AI 취약점 탐지와 자동 패치: 각각 무엇을 해결할까요?.