DEEP DIVE REPORT

CVE-2026-121458: Instatic AI/MCP 콘텐츠 읽기 도구의 인가 누락, 무엇이 드러나나

SecurityDesk
• 2026.11.05 • 조회 5

Instatic의 AI/MCP 콘텐츠 읽기 도구에서 호출자별 권한 확인이 빠진 인가 우회 취약점이 공개됐습니다. VulnCheck 자문이 지정한 공식 영향 범위는 Instatic >= 0.0.12, < 0.0.21 이고, CVE 번호는 CVE-2026-121458 입니다. 공급자 보고는 같은 동작이 0.0.5부터 존재한 것으로 기재하지만 공식 영향 범위는 0.0.12부터로 표기돼 있어, 0.0.5~0.0.11 구간의 영향 여부는 현존 근거만으로 확정되지 않습니다. CVSS 4.0 기준 점수는 7.1(High)이며, 수정 릴리스인 0.0.21은 이미 제공되고 있습니다.

개요

개요 인포그래픽
- Instatic의 AI/MCP 콘텐츠 읽기 도구에서 콘텐츠 접근 시 사용자별 권한 확인이 수행되지 않는 인가 누락 취약점입니다. CWE-862(Missing Authorization)로 분류됩니다.
- 핵심 동작은 단순합니다. 인증된 사용자가 MCP 콘텐츠 읽기 도구를 통해 자신이 소유하지 않은, 다시 말해 다른 사용자의 콘텐츠를 조회할 수 있습니다.
- CVE 레코드에는 VulnCheck CNA 명의로 2026-11-03 등록됐으며, VulnCheck 독립 자문도 같은 날 심각도 High, CVSS 4.0 점수 7.1로 공개했습니다. 크레딧은 Sriman Aluvala로 표기돼 있습니다.
- 공급자 측면에서는 CoreBunch의 보안 자문 GHSA-x5cc-8486-8qqx가 동일 문제를 다루며, 수정 버전 0.0.21 릴리스가 현재 상태 확인의 기준점이 됩니다.

영향 범위

  • 자문이 명시한 공식 영향 범위는 Instatic >= 0.0.12, < 0.0.21 입니다. 이 구간에 해당하는 배포가 우선 점검 대상입니다.
  • 반면 공급자 자문서는 이 동작이 0.0.5부터 존재한 것으로 기재하고, 실제로 재현이 확인된 대상으로 Instatic 0.0.20(커밋 f92e8dc1dbedb3e472abe8016b1530103840c389) 을 꼽습니다.
  • 두 표기가 완전히 일치하지 않기 때문에 0.0.5 이상 0.0.11 미만 구간은 영향이 있는지 없는지 현존 근거만으로 확정할 수 없습니다. 이는 자료가 가진 한계입니다. 해당 구간 버전이 돌아가고 있다면 영향을 단정하지 말고, 원인을 가려내기보다 0.0.21 업그레이드로 함께 처리하는 편이 실무적으로 안전한 판단입니다.
  • 영향의 성격은 데이터 격리 문제입니다. 여러 사용자가 콘텐츠를 공유하는 Instatic 환경에서는 사용자 간 경계가 무너지는 결과로 이어질 수 있고, CVSS 세부 값은 기밀성 영향(VC:H)만 높고 무결성(VI:N)·가용성(VA:N) 영향은 없음으로 평가돼 있습니다. 즉 시스템이 망가지거나 데이터가 변조되는 형식의 사고가 아니라, 조용한 열람 사고에 해당합니다.

기술적 분석

인가 확인이 빠진 콘텐츠 읽기 경로

보고서에서 지목된 지점은 AI 도구 계층입니다. server/ai/tools/index.ts 등이 affected file 목록에 등장합니다. 제공된 근거가 확인하는 범위는 여기까지입니다. 즉 Instatic의 AI/MCP 콘텐츠 읽기 도구가 콘텐츠를 조회할 때 사용자별 권한 확인을 수행하지 않아, 인증된 저권한 사용자가 자신이 소유하지 않은 다른 사용자의 콘텐츠를 읽을 수 있다는 것이 확인된 동작입니다. 콘텐츠 저장소 계층이나 도구 바깥 경로에서 별도의 권한 확인이 어떻게 이루어지는지는 자문에 기재돼 있지 않아, 이 원고에서는 다루지 않습니다.

CVSS 벡터로 읽는 공격 조건

벡터는 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N 입니다. 여기서 읽히는 조건은 다음과 같습니다.

  • AV:N, AC:L: 네트워크 경로로, 특별한 장애물 없이 시도할 수 있습니다.
  • PR:L: 어딘가에 로그인한 저권한 계정이 필요합니다. 익명 원격 공격이 아니라 인증된 사용자·등록 계정 관점의 위험입니다.
  • UI:N: 다른 사용자의 조작이나 클릭을 필요로 하지 않습니다.
  • VC:H: 노출은 콘텐츠 기밀성에 집중됩니다.
  • SC:N/SI:N/SA:N: 이후 시스템(subsequent system)에 대한 기밀성·무결성·가용성 영향은 없음으로 평가됐다는 뜻입니다.

이 조합을 실제 배포 환경에 대입하면, 위험의 크기는 계정 발급 정책에 크게 좌우됩니다. 등록만 하면 계정이 생기는 개방형 배포나 외부 초대 사용자를 받아들이는 공유 워크스페이스에서는 PR:L 조건이 거의 장벽이 아니므로 실질 위험이 올라가고, 초대 전용이고 사용자 풀이 통제되는 환경에서는 같은 취약점에서도 노출면이 좁아집니다. 어디에 해당하는지는 제공된 근거로 판단할 수 없으므로 자사 배포 모델, 즉 계정을 누가 발급할 수 있는지를 먼저 확인해 보시길 권합니다.

공개 PoC·익스플로잇 분석

  • 출처: 공개된 근거는 CoreBunch 공급자 자문 GHSA-x5cc-8486-8qqx 와 VulnCheck의 독립 자문 Instatic before 0.0.21 Authorization Bypass via MCP Content Read Tools 두 갈래입니다. 자문에는 affected file 목록(server/ai/tools/index.ts 등)과 재현에 쓴 버전·커밋이 그대로 기재돼 있어, 별도 내부 정보가 없어도 동작을 따라가 볼 수 있는 수준으로 절차가 공개돼 있습니다. 다만 독립적인 제3자 익스플로잇 코드 저장소나 별도 도구 릴리스의 존재와 그 성숙도(대량 자동화, 상용화 여부)는 이 원고가 확인한 근거 안에 없어 판단할 수 없습니다.
  • 전제조건: 자문은 Prerequisites로 인증된 사용자 계정을 명시합니다. CVSS의 PR:L, UI:N, AV:N, AC:L 값과 이 전제조건이 서로 맞아떨어지므로, 필요한 것은 네트워크 도달성과 저권한 로그인 자격뿐입니다. 즉 이 취약점을 평가할 때는 계정을 누가 만들 수 있는가가 곧 공격면의 크기가 됩니다.
  • 입증 범위: 자문은 Instatic 0.0.20, 커밋 f92e8dc1dbedb3e472abe8016b1530103840c389 에서 재현이 확인됐다고 기재하고, 해당 동작이 0.0.5부터 존재한 것으로 보고합니다. VulnCheck는 공식 영향 범위를 >= 0.0.12, < 0.0.21 로 표기했습니다. 반대로 야생 악용 증거와 CISA KEV 등재 여부는 제공된 근거에서 확인되지 않았습니다. 따라서 "재현 가능한 취약점"이라는 사실과 "실제로 악용되고 있다"는 사실은 여기서는 분리해서 다뤄야 합니다.
  • 운영 의미: 재현에 필요한 정보가 충분히 공개돼 있으므로, 취약한 버전이 살아 있는 동안에는 이론적 위험이 아니라 언제든 확인할 수 있는 상태로 보는 편이 맞습니다. 다만 확인된 영향이 기밀성(VC:H) 단일 축이고 이후 시스템에 대한 영향(SC:N/SI:N/SA:N)은 없음으로 평가돼 있으므로, 가용성 장애 대응처럼 무거운 사고 대응 체계보다는 버전 확인, 필요시 도구 접근 제한, 로그 점검의 순서로 빠르게 정리하고, 근본 조치는 0.0.21 업그레이드로 잡는 것이 근거에 맞는 대응입니다. 익스플로잇 코드 유포 동향이나 IOC 기반 탐지처럼 이번 근거로 뒷받침되지 않는 지침은 이 원고에서는 다루지 않습니다.

악용 상태와 남은 불확실성

  • 공개 보고 GHSA-x5cc-8486-8qqx와 VulnCheck 독립 자문으로 취약점의 존재와 재현 가능성은 확인됐습니다.
  • 다만 야생에서의 악용 사례는 조사 범위 안에서 확인되지 않았고, CISA KEV 등재 여부도 현존 근거로 확인할 수 없었습니다. 재현 조건이 명확해 악용 가능성을 낮다고 보긴 어렵지만, 악용 증거가 없다는 사실과 악용될 수 없다는 사실은 다르다는 점을 대응 판단에서 분리해서 봐야 합니다.
  • 수정 커밋의 상세 코드 변경과 정확한 패치 방식도 제공된 근거에서는 확인되지 않습니다. 따라서 업그레이드 전후 검증은 동작 확인 중심으로 계획하는 것이 안전합니다.

대응 방안

지금 확인할 것

  • 실행 중인 Instatic 버전을 즉시 확인합니다. 공식 영향 범위(Instatic >= 0.0.12, < 0.0.21)에 해당하면 0.0.21 업그레이드 계획을 세우고, 0.0.5 이상 0.0.11 미만처럼 표기가 갈리는 구간에 있으면 영향 여부를 단정하지 말고 같은 업그레이드 대상으로 취급합니다.
  • AI/MCP 콘텐츠 읽기 도구에 접근할 수 있는 사용자 집합이 누구인지, 외부에게 열려 있는지부터 정리합니다.
  • 해당 도구의 호출 로그에서 요청한 사용자와 대상 콘텐츠의 소유자가 다른 건이 있는지 훑어봅니다. 이 취약점의 특징적인 신호가 바로 그 불일치입니다.

우선순위를 어떻게 볼까

  • 야생 악용 증거가 확인되지 않았으므로, 이 문제는 사고 대응보다 점검과 조기 탐지 중심으로 운영하는 것이 근거에 맞습니다.
  • 대신 노출 대상이 콘텐츠 데이터 그 자체이고 추가 상호작용 없이 성립하며 재현 절차가 공개돼 있으므로, 민감한 협업 문서나 미공개 원고를 다루는 환경일수록 패치 우선순위를 높게 잡을 근거가 됩니다. 영향 범위에 해당하면 근본 대응은 언제나 0.0.21 업그레이드이고, 로그 점검은 이를 대신하는 조치가 아니라 업그레이드 전후로 과거 노출을 확인하는 수단입니다.
  • 계정 발급이 열려 있는 배포에서는 업그레이드를 서두르는 것과 별도로, 패치 전 단계의 도구 접근 제한이 노출면을 가장 빨리 줄이는 임시 통제가 됩니다.

근원 조치와 임시 통제

  • 근본 대응은 Instatic 0.0.21 업그레이드입니다. 릴리스 v0.0.21이 제공되고 있으며, 업그레이드 전 변경 사항 검증과 롤백 계획을 함께 마련해 두십시오.
  • 업그레이드가 즉시 어려운 환경에서만 한시적으로, AI/MCP 콘텐츠 읽기 도구 접근을 일시 제한하거나 신뢰된 사용자 그룹으로 통제하고, 교차 사용자 조회가 눈에 띄면 즉시 경보하도록 모니터링을 임시 통제로 유지합니다.
  • 교차 접근 추세 모니터링은 업그레이드 이후에도 일정 기간 남기는 편이 좋습니다. 업그레이드 시점을 기준으로 이전 이력과 이후 이력을 나누어 보면, 과거에 실제로 발생한 일이 있었는지 판단하는 기준선이 생깁니다.
  • 공급자 패치 노트의 수정 방식 상세와 KEV 등재 여부는 이 원고에서 확인하지 못했습니다. 업그레이드 계획 승인 전 공급자 릴리스 노트와 추가 자문을 직접 확인하는 단계를 한계 보완책으로 남겨 두시길 권합니다.

참고자료

함께 읽으면 좋은 글

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9