CVE-2026-75130: Context7의 MCP 문서 서버가 9.0점을 기록했으며, 기록에는 수정된 버전이 명시되지 않았다

2026년 8월 18일 VulnCheck는 Context7에 대해 CVE-2026-75130을 공개했습니다. Context7은 Upstash가 Model Context Protocol을 위해 운영하며 코딩 에이전트가 버전별 문서를 조회하는 라이브러리 문서 서버입니다. 이 취약점은 Upstash가 Custom AI Instructions라고 부르는 기능에 있습니다. 라이브러리 소유자가 문서 항목에 지침을 첨부하면 Context7은 해당 라이브러리를 조회하는 모든 에이전트의 컨텍스트 창에 그 지침을 제공하며, 그 경로 어디에서도 이를 정제하지 않습니다. 선임 AI 취약점 연구원 Eli Ainhorn이 발견자로 인정받는 Noma Security는 오염된 항목이 연결된 에이전트로 하여금 프로젝트 루트의 .env 파일을 읽고, 그 내용을 공격자가 제어하는 GitHub 저장소에 이슈로 전송하며, ‘정리’라는 명분으로 로컬 폴더를 삭제하게 만들 수 있음을 입증했습니다. 이 모든 것은 일상적인 문서 조회 요청만으로 이루어집니다. 피해자는 기록되지 않았습니다. 문서화된 나머지 에이전트 사고들은 각각 고유한 심각도, 신뢰도 등급 및 분쟁 플래그를 갖추고 있으며, 이들은 AI 사고 아카이브에 있습니다. 여기서 이 기록과 인접한 항목들을 나란히 볼 수 있습니다.

Context7의 서버는 작으며, 바로 이 점이 먼저 이해할 가치가 있는 부분입니다. Noma의 글은 이 서버가 두 가지 도구인 resolve-library-id 및 query-docs를 노출한다고 지적합니다. 또한 이 서버는 자체적으로 코드를 실행하거나 파일을 작성하거나 네트워크에 접근할 수 없습니다. 문서화된 모든 영향은 개발자의 머신에서 파일 시스템, 셸 및 네트워크 접근 권한을 실제로 보유한 상대편 에이전트에 의해 수행됩니다. npm 레지스트리는 설치 기반이 얼마나 큰지 보여줍니다: @upstash/context7-mcp는 4,064,176회 다운로드되었습니다. 이 수치는 2026년 7월 22일부터 8월 20일까지의 30일 동안, 즉 발표 무렵의 기간에 해당합니다.

메커니즘: 오염된 라이브러리 하나, 그리고 그것을 질의하는 모든 에이전트

Noma의 시연은 2026년 3월 5일 ContextCrush 게시물에 설명된 대로, 서버가 아니라 에이전트가 수행하는 세 단계로 진행되었습니다. 이 시연은 오염된 규칙이 첨부된 라이브러리를 Context7의 레지스트리에 등록했습니다. 해당 규칙 속 지시는 에이전트에게 프로젝트 루트의 모든 .env 파일을 검색하고 읽도록 지시했습니다. 추가 지시는 그 내용을 공격자가 제어하는 GitHub 저장소에 이슈로 게시하도록 했습니다. 마지막 지시 세트는 “정리”를 위해 로컬 폴더와 파일을 삭제하라고 했습니다. 이 모든 것을 컨텍스트로 불러오는 요청은 지극히 평범한 것입니다 — 코딩 어시스턴트에게 라이브러리 사용 도움을 요청하는 일입니다.

공급망 문제이지 일반적인 프롬프트 인젝션이 아닌 이유는 페이로드가 존재하는 위치에 있다. 공격자는 피해자의 컴퓨터에 결코 도달하지 않으며, 사용자가 여는 문서에 텍스트를 심을 필요도 없다. 오염된 지침은 Context7 자체의 레지스트리에 존재하고, Context7 자체 인프라에서 호스팅되고 제공되며, 합법적인 문서와 동일한 신뢰 채널을 통해 도착하여 그것과 구분되지 않는다. Noma는 라이브러리를 그 배후의 GitHub 이력으로 평가하는 Context7의 신뢰 점수가 이에 대해 방어하지 못한다고 지적한다. 오래 유지된 계정은 매수되거나 탈취되거나 인위적으로 만들 수 있기 때문이다. 이 구조적 요점에 대한 회사 자체의 요약은 노골적이다. “공격 표면은 MCP 서버가 할 수 있는 일에 있지 않다. 그것은 MCP 서버가 AI 에이전트로 하여금 할 수 있게 만드는 일에 있다.”

하나의 버그에 두 개의 점수

권고문에는 CVSS 3.1 9.0 (치명적) 및 CVSS 4.0 6.4 (중간)가 실려 있습니다. 두 벡터는 모두 할당 CNA인 VulnCheck가 제공했으며, NVD는 두 벡터를 변경 없이 수록하면서 각각을 VulnCheck에 귀속시킵니다. 이 분리는 실수가 아니라, 두 프레임워크가 동일한 피해를 서로 다른 시스템을 기준으로 집계한 결과입니다. CVSS 3.1은 Scope를 Changed로 표시합니다 — 인젝션이 서버에서 개발자의 시스템으로, 그리고 그 너머로 넘어가기 때문입니다 — 따라서 에이전트 기능의 높은 기밀성, 무결성 및 가용성 영향 전체를 최대 가중치로 반영합니다. CVSS 4.0은 Scope를 취약한 시스템과 그 이후 시스템에 대한 별도 지표로 대체합니다: Context7 자체에는 기밀성, 무결성 또는 가용성 영향이 없음(VC:N/VI:N/VA:N)을 기록하고, 다운스트림 시스템에는 높은 영향(SC:H/SI:H/SA:H)을 기록하는데, 공식에서는 이를 더 낮게 가중합니다. 서버는 전달자일 뿐 피해자가 아닙니다.

이 분열은 데이터베이스로까지 번진다. GitHub의 보안 권고, GHSA-97r6-3rgm-v39r은 8월 18일 18:32 UTC에 CVE가 공개된 지 30분 후 게시되었고, 요약 심각도는 중간으로 표시된다. 같은 기록의 CVSS 3.1 벡터가 9.0을 기록하는데도 말이다. ENISA의 EU Vulnerability Database는 이 항목을 EUVD-2026-61099로 미러링하며 버전 4.0에서만 기본 점수 6.4를 저장한다. 이 기사가 따르는 아카이브 기록은 해당 사건에 높음 — 공개된 두 점수 중 어느 것도 아닌 — 이라는 등급을 매기며, 이는 아카이브의 등급이지 그 자체의 측정값이 아니다.

3월에 공개된 사항에 대해 8월에 발표된 CVE

CVE 식별자는 2026년 8월 17일에 예약되었고 8월 18일 18:02 UTC에 공개되었으며, 이는 기록에 명시된 날짜입니다. CNA 컨테이너에는 애그리게이터 페이지에 나타나지 않는 두 번째 날짜도 포함되어 있습니다: datePublic, 2026년 3월 5일 — 식별자가 존재하기 다섯 달 반 전이며, Noma가 ContextCrush를 공개한 바로 그날입니다. 권고문의 유일한 기술 참조는 그 3월 분석 글이며, VulnCheck는 이 글을 기술 설명과 익스플로이트 양쪽에 태그합니다.

노마의 공개 타임라인은 그 간극을 설명한다. 노마는 2026년 2월 18일 전체 보고서와 증명용 개념 코드(PoC)를 포함해 그 취약점을 업스타시(Upstash)에 신고했고, 2월 19일 업스타시가 조사 결과를 수용하고 수정 작업에 착수한 것을 기록했으며, 2월 23일 “규칙 정제와 가드레일을 갖춘 수정 사항이 프로덕션에 배포”되었다고 밝히고, 공개 및 노마의 최종 검증 일자를 3월 5일로 명시한다. 노마의 설명에 따르면 2월의 버그는 수일 만에 해결되었다.

npm 레지스트리의 날짜는 그 타임라인과 맞아떨어지는데, 그 때문에 영향 범위가 이상해 보인다. @upstash/context7-mcp 2.1.2는 2026년 2월 23일 10:06 UTC에 게시되었으며, 이는 Noma가 수정 사항이 프로덕션에 도달했다고 말하는 날이다. 해당 변경 로그에는 “불필요한 경고를 제거하고 도구 설명을 업데이트”라고 적혀 있다. 2.1.3은 2026년 3월 4일, Noma의 글이 나오기 하루 전에 이어졌으며, MCP 엔드포인트에서 GET 요청을 거부하고 검색 결과에 source 필드를 추가하는 내용이 포함되어 있었다. 어느 릴리스 노트에도 정화, 가드레일, 인젝션에 대한 언급은 없다. CNA의 영향 범위는 2.1.2에서 끝나므로, 2.1.3이 그 범위를 벗어나는 첫 버전이 된다.

세 가지 해석이 그 날짜들과 들어맞으며, VulnCheck도 Noma도 어느 것이 맞는지 밝히지 않는다. 첫째는 Digital Applied가 8월 18일 기사에서 주장하고 AI Security Wire가 8월 22일 반복한 것으로, 수정이 회귀했다는 것이다: 2월 패치를 담은 빌드가 8월의 영향 범위 안에 있다. 둘째는 그 범위가 단순히 연구자가 테스트한 빌드에 고정된 것이며, 공개 하루 전에 배포된 2.1.3이 실제 경계라는 것이다 — Feedly를 포함해 여러 애그리게이터가 기계적으로 내리는 추론으로, Feedly는 “2.1.3 이상으로 업데이트”를 완화책으로 나열한다. 셋째는 2월 수정이 클라이언트 패키지가 아니라 규칙이 제공되는 곳에 적용되었다는 것이며, 그렇다면 npm 버전 범위는 수정을 전혀 설명하지 못한다. 조용한 보안 수정은 충분히 흔해서 일치하는 체인지로그 항목이 없다는 사실만으로는 어느 쪽도 결론지을 수 없다.

무엇이 확립되었고, 무엇이 그렇지 않은가

• 기본 기록에 의해 확인되었습니다. CVE 식별자, 8월 18일 공개, CNA로서의 VulnCheck, LLM 프롬프트에 사용되는 입력의 부적절한 중화에 대한 CWE-1427 분류, Noma Security의 Eli Ainhorn에 대한 공로 인정, 그리고 2.1.2까지의 Context7 영향 범위.

• Noma의 연구로 확인되었습니다. Custom AI Instructions를 통한 주입 경로, 세 단계의 개념 증명, 해당 서버가 resolve-library-id와 query-docs만 노출한다는 관찰, 그리고 2월 버그에 대해 실제 환경에서 악용된 증거가 관찰되지 않았다는 진술.

• 레지스트리에서 설정되었습니다. 2.1.2 공개일은 2026년 2월 23일, 2.1.3 공개일은 2026년 3월 4일이며, 패키지 라인은 이후 4.0을 넘어 2026년 10월 19일 4.4.4까지 이르렀습니다.

• 확인되지 않음: 현재 빌드가 영향을 받는지 여부. 어떤 출처도 4.x 라인이 취약하다고 말하지 않으며, 어떤 출처도 해당 라인이 안전하다고 말하지 않습니다. CVE 기록, VulnCheck 권고 및 GitHub 권고 모두 수정된 버전을 명시하지 않았고, GitHub 권고의 취약한 버전 범위 목록은 비어 있습니다.

• 확인되지 않음: 피해자 또는 실제 환경에서의 사용 사례. 아카이브는 실제 피해를 거짓으로 기록한다. CISA가 8월 19일 해당 기록을 보강하면서 Exploitation은 “none”, Automatable은 “no”, Technical Impact는 “total”로 평가했다. 이 결함은 KEV 목록에 없으며, ENISA의 미러에는 EPSS가 0.49퍼센트로 기록되어 있다. Noma의 연구는 사고 보고서가 아니라 시연이다.

• 입증되지 않음: 회귀 해석 자체. 이는 수정 일정과 npm 게시 사이의 날짜 우연에 근거하고 있으며, 동일한 코드 경로가 두 번 실패했다고 단언하는 1차 출처는 없습니다.

보강: 반복 진술, 그리고 중요한 순간의 침묵

기록과 일치하는 문서들은 대부분 그 기록에서 파생된다. VulnCheck의 권고는 CVE 텍스트를 다시 서술하고 약점 분류와 연구원 공로 표시를 추가한다. GitHub 권고는 동일 제출물의 별칭으로, 같은 날 저녁에 게시되었으며 버전 범위가 없고 독립적 검토도 없다. ENISA의 항목은 복제본이다. 아카이브가 인용한 두 출처 중 하나인 Digital Applied는 8월 18일 분석을 게시하고 8월 22일 레지스트리에서 새로 가져온 데이터로 이를 업데이트했다. AI Security Wire는 8월 22일 두 번째 기사를 게시했다. 둘 다 권고를 다시 서술하고 회귀 추론을 전달하며, 어느 쪽도 이를 독립적으로 검증했다고 주장하지 않는다.

2026년 10월 29일 CVE에 대한 뉴스룸 보도를 찾지 못했습니다. BleepingComputer, The Register, SecurityWeek 어디에도 항목이 없었고, 검색 결과는 보도가 아닌 CVE 집계 사이트 페이지들이었습니다. 이러한 부재는 이 기록을 어떻게 읽어야 하는지에 중요합니다. 아카이브는 이 기록에 A 등급을 부여했으며, 일치하는 1차 출처로 잘 문서화되어 있고 그 1차 출처들은 실제로 일치합니다. 그러나 여기서의 일치는 CNA 기록과 그것이 인용하는 연구 사이의 일치이지, 두 개의 독립적인 측정 사이의 일치가 아닙니다. 여러 집계 페이지는 출처가 뒷받침하지 않는 주장을 덧붙입니다. 예를 들어 Feedly 항목은 패치가 제공된다고 명시하며 2.1.3을 지목하지만, 어떤 보안 권고문도 그렇게 하지 않습니다. 반면 VulDB 페이지는 내용 대신 봇 확인을 반환해 전혀 읽을 수 없었습니다.

무엇이 바뀌었고, 무엇이 바뀌지 않았는가

2월 버그의 경우 Upstash는 며칠 만에 움직였습니다. Noma의 설명에 따르면 2월 19일에 접수되었고 2월 23일에 수정되었습니다. 8월 기록의 경우 CVE가 참조하는 유일한 공급업체 진술은 Upstash의 LinkedIn 게시물인데, 해당 게시물에는 벤더 권고로 태그가 붙어 있으며 그 내용은 세션 없이는 읽을 수 없었습니다. 저장소를 대상으로 한 GitHub 보안 권고 중 수정 버전을 명시한 것은 없으며, NVD의 항목은 보류됨 상태로, CPE 구성이 없고 최종 수정일이 2026년 10월 22일이므로 NVD 자체의 분석은 기록에 포함되어 있지 않습니다.

패키지 자체는 계속 배포되었다. 2025년 4월 20일부터 2026년 10월 23일까지 upstash/context7 저장소는 163개의 릴리스를 발표했으며, 그 어느 릴리스 노트에서도 이 CVE를 언급하거나 인젝션을 담고 있는 사용자 지정 지침을 정제하는 방법을 설명하지 않는다. 이는 유지관리자들이 기록으로 남기기로 선택한 내용을 보여주는 것이지, 아무것도 수정되지 않았다는 증거는 아니다.

기록이 운영자에게 남기는 것은 패치 라인이라기보다 노출 관리입니다. Noma의 권고는 MCP 통합을 검토하고 런타임에서 에이전트와 서버 사이를 오가는 내용을 점검하는 데 중점을 둡니다. OpenCVE가 제안하는 조치는 업그레이드하고, Custom AI Instructions 기능을 비활성화하거나 제한하고, 서버에 입력 유효성 검사를 추가하는 것입니다. 이 모든 것의 운영상 형태는 동일한 세 가지 조치입니다. 즉, 최신 버전에 표류하지 않고 MCP 서버 버전을 고정하고, 에이전트가 읽을 수 있는 일반 텍스트 환경 파일에 프로덕션 자격 증명을 두지 않으며, 도구 응답을 에이전트가 따를 수 있는 문서로 취급하지 말고 신뢰할 수 없는 입력으로 취급하는 것입니다.

게시된 지 열 주가 지났지만 공개 기록은 여전히 8월 18일에 멈춘 지점에서 끝납니다. 식별자 하나, 두 등급만큼이나 떨어진 두 개의 점수, 상한이 2월에 출시된 빌드인 영향 범위, 그리고 이름이 붙은 수정 버전은 없습니다. CVE-2026-75130을 분류하는 사람은 자신의 에이전트가 닿을 수 있는 범위를 기준으로 결정해야 합니다. 기록이 어떤 버전을 설치해야 하는지 알려주지 않기 때문입니다.