Bifrost 관리 API에 대한 인증되지 않은 POST 요청 하나로 게이트웨이 사용자 권한으로 명령이 시작되었습니다

2026년 9월 14일, JFrog Security Research가 공개한 CVE-2026-90898은 Bifrost — Maxim이 유지 관리하는 오픈소스 AI 게이트웨이 — 의 명령 실행 취약점으로, 10점 만점에 9.8점을 받았습니다. 공격은 HTTP 요청 하나였습니다. 인증되지 않은 POST /api/mcp/client 요청은 stdio MCP 클라이언트를 등록하며, Bifrost는 이를 프로그램 이름과 인수 목록으로 읽어 MCP 핸드셰이크 이전에 게이트웨이를 실행 중인 사용자 권한으로 즉시 시작합니다. 공식 이미지에서 그 사용자는 appuser입니다. 게이트웨이는 운영자의 공급자 키와 가상 키가 있는 곳이기도 하므로, 그곳에서 실행되는 프로세스는 자격 증명에 접근할 수 있습니다. 이 요청을 익명으로 만든 것은 기본 제공 설정이었습니다. governance.auth_config.is_enabled가 false이며, JFrog의 표현대로 "인증이 꺼져 있다는 것은 모든 호출자가 로컬 관리자라는 뜻"입니다. 인용된 출처 중 취약점이 실제로 악용되었다고 보고한 곳은 없습니다. 해당 기록 자체의 출처, 심각도 등급, 신뢰도 평가는 AI 인시던트 아카이브에 있으며, 지난 한 해 동안 문서화된 다른 AI 게이트웨이 및 MCP 취약점들과 함께 있습니다.

Bifrost는 애플리케이션과 그 애플리케이션이 호출하는 언어 모델 사이에 위치한 단일 서비스입니다. 해당 저장소는 이를 "단일 OpenAI 호환 API를 통해 23개 이상의 제공자에 대한 접근을 통합"하는 Apache-2.0 라이선스의 오픈소스 게이트웨이로 설명하며, 기능으로는 MCP 프록시, 가상 키, 예산, 제공자별 로드 밸런싱 등이 있고, 2026년 10월 28일 기준 GitHub 스타는 약 9,150개였습니다. 바로 이 조합 때문에 이 특정 호스트에서 셸을 얻는 것이 치명적 점수에 해당할 만합니다. 요청을 라우팅하는 프로세스가 곧 자신이 라우팅하는 모든 업스트림의 자격 증명을 보관하는 프로세스이기 때문입니다. 9월 22일 이 결함을 보도한 Hacker News는 그 결과를 명확히 지적했습니다. 게이트웨이가 연결된 모든 제공자의 API 키를 저장하므로, 게이트웨이 프로세스에서 명령을 실행하면 공격자가 해당 자격 증명에 접근할 수 있게 된다는 것입니다.

전체 공격은 단일 POST였습니다.

JFrog의 권고문은 참조 번호 JFSA-2026-001686326으로 공개되었으며, 관리자가 MCP 서버를 추가할 수 있도록 존재하는 엔드포인트를 설명한다. MCP 사양의 stdio 클라이언트는 URL이 아니라 명령과 그 인수이며, 호스트 프로그램이 이를 실행할 것으로 기대된다. Bifrost는 관리 API를 통해 해당 구성을 받아들이고 클라이언트가 추가되는 즉시 프로그램을 시작한다. 기능 협상도, 서버 신원 확인도, 핸드셰이크가 먼저 성공할 필요도 없다 — 권고문은 핸드셰이크가 프로세스를 시작시키는 것이 아니라고 명시한다.

권고문의 개념 증명은 인증이 기본값 그대로인 게이트웨이로 전송되는 짧은 JSON 본문입니다. 이 PoC는 명령이 /bin/sh이고 인수로 마커 파일을 작성하는 클라이언트를 등록한 다음, 마커를 다시 읽습니다. JFrog는 인시던트 대응 중에 중요한 운영상 세부 사항을 덧붙입니다. Bifrost가 결코 오지 않는 핸드셰이크를 기다리는 동안 HTTP 요청이 시간 초과될 수 있으며, 로그의 시간 초과가 명령이 시작되지 못했다는 뜻은 아닙니다. 그 시점에는 프로세스가 이미 실행 중입니다.

CVE 번호 부여 기관인 JFrog가 할당한 CVE 레코드는 해당 결함을 CWE-306, 중요 기능에 대한 인증 누락, 및 CWE-284, 부적절한 접근 제어에 매핑하고, 핸들러와 그 미들웨어를 포함하는 두 파일인 transports/bifrost-http/handlers/mcp.go 및 transports/bifrost-http/handlers/middlewares.go를 명시합니다. 영향을 받는 모듈은 Linux 및 macOS에서 2.1.0 미만의 모든 버전에 해당하는 github.com/maximhq/bifrost/transports입니다.

요청을 익명으로 만든 기본값

그중 어느 것도 두 번째 조건 없이는 악용될 수 없으며, 그 두 번째 조건은 제품 자체의 기본값입니다. Bifrost의 관리 인증 미들웨어는 governance.auth_config.is_enabled로 제어되는데, 이 값은 기본적으로 false로 제공됩니다. 이 설정이 꺼져 있으면 미들웨어는 모든 호출자를 로컬 관리자로 취급합니다. 권고문 자체의 요약에서도 인증이 꺼져 있다는 것은 모든 호출자가 로컬 관리자라는 뜻이므로, 요청을 막았어야 할 검사는 애초에 경로에 포함되지 않았습니다.

수정 사항인 풀 리퀘스트 #6757은 2026년 9월 2일에 프로젝트에 병합되었으며, 이는 CVE가 공개되기 12일 전이자 해당 CVE를 포함한 릴리스가 나오기 6일 전이었습니다. 그 설명은 문제의 형태에 대해 이례적으로 솔직합니다. 해당 풀 리퀘스트는 동일한 등록 API에서 인증되지 않은 접근 기본 요소 두 개를 막으며, 하나가 아닙니다. 첫 번째는 stdio 클라이언트입니다. 두 번째는 루프백 또는 사설 네트워크 주소를 가리키는 http 또는 sse MCP 클라이언트로, 해당 풀 리퀘스트는 이를 내부 서비스에 대한 SSRF 기본 요소라고 부르며, "169.254.169.254 클라우드 메타데이터 엔드포인트를 포함합니다"라고 언급합니다. 이제 둘 다 요청이 진정한 자격 증명 확인 없이 핸들러에 도달하면 HTTP 403으로 거부됩니다. 인증된 관리자는 두 기능을 모두 유지하며, 운영자는 여전히 config.json을 통해 stdio 클라이언트를 프로비저닝할 수 있습니다.

두 번째 기본 요소는 CVE 본문에는 나타나지 않습니다. 그것은 패치에 있으며, 이 수정이 제거가 아니라 게이트인 이유입니다. 기능 자체는 결코 버그가 아니었습니다. 인증되지 않은 호출자를 관리자로 취급한 것이 버그였습니다.

관리 API가 실제로 수신 대기 중이던 위치

도달 가능성은 출처들이 가장 일관되게 설명하면서도 가장 적게 측정하는 기록의 부분이다. JFrog의 권고는 기본 바이너리의 기본값을 localhost:8080으로 제시하는데, 이는 공격자를 호스트 자체로 제한한다. 같은 팀의 동반 결함에 대한 권고는 공식 Docker 이미지가 대신 0.0.0.0에 바인딩한다고 밝히며, The Hacker News도 이를 반복한다: 이미지는 포트가 게시되면 관리 API를 컨테이너 외부에서 도달 가능하게 만든다. Bifrost 자체의 README 빠른 시작은 "docker run -p 8080:8080 maximhq/bifrost"를 실행하며, Docker의 -p는 주소가 지정되지 않는 한 모든 호스트 인터페이스에 컨테이너 포트를 게시한다. 해당 결함에 대한 GitHub 권고는 보고된 경로가 게시된 maximhq/bifrost:latest 이미지에 대해 검증되었음을 기록하는데, 여기서 인증되지 않은 요청이 /bin/sh를 실행하고 appuser로서 마커를 작성했다.

어떤 출처도 제공하지 않는 것은 숫자다. 인터넷에 노출된 Bifrost 인스턴스의 수나 스캔 결과, 텔레메트리, 피해자 어느 것도 없다. 기록에는 실제 피해가 담겨 있지 않으며, 그 부재는 안심의 근거라기보다 보도에 관한 사실이다. 이 취약점 유형은 노출된 리스너와 손대지 않은 기본값이라는 두 조건이 겹칠 때만 위험하며, 그 두 조건이 얼마나 자주 함께 나타났는지는 아무도 공개하지 않았다.

하나의 엔드포인트, 두 가지 결함, 하나의 근본 원인

MCP 권고가 나오기 8일 전인 2026년 9월 6일, 동일한 연구팀이 발표한 것은 CVE-2026-86242, 즉 동일한 프로세스로 들어가는 두 번째 인증 없는 경로입니다. Or Peles가 발견했고 8.1점을 받은 이 취약점은 POST /api/plugins를 악용합니다: Bifrost는 경로가 HTTP URL인 활성화된 사용자 정의 플러그인을 허용하고, 공유 객체 로더는 http로 시작하는 경로를 다운로드로 처리하여 본문을 임시 .so 파일에 쓴 뒤 해당 파일을 Go의 plugin.Open에 넘깁니다. 로드가 성공하면 선택적 Init 함수가 공격자의 구성으로 즉시 실행되며, 게이트웨이 사용자 권한으로 실행됩니다.

빌드 플레이버는 공격자가 무엇을 얻는지를 결정합니다. 프로젝트가 사용자 정의 Go 플러그인용으로 문서화한 동적 링크 빌드에서는 로드가 성공할 것으로 예상되며, 보안 권고에서는 이를 인증되지 않은 원격 코드 실행이라고 부릅니다. 공개된 정적 링크 Docker 이미지에서는 plugin.Open이 "Dynamic loading not supported" 오류로 실패하므로, 동일한 요청은 서버 측 요청 위조로 격하됩니다. 로드 가능한 플러그인은 호스트의 Go 버전, 운영 체제, 아키텍처 및 링크 방식과도 일치해야 하며, 이는 형식적인 요건이 아니라 실제 제약입니다. 수정 버전은 transports/v2.0.0이며 풀 리퀘스트 #5763을 통해 제공되고, 영향을 받는 범위는 그보다 낮은 모든 버전입니다.

함정은 릴리스 순서다. v2.0.0은 플러그인 경로를 수정했지만 MCP 경로는 수정하지 않았다 — The Hacker News가 이를 명시적으로 말하며, JFrog의 MCP 권고문은 v2.0.0이 여전히 인증되지 않은 stdio 등록을 허용한다고 확인한다. 9월 6일 권고문 이후 신속하게 패치한 운영자도, transports/v2.1.0이 9월 8일 출시되기 전까지는 바로 그 점만으로도 여전히 노출되어 있었다. 두 결함은 두 권고문과 벤더 자체의 풀 리퀘스트에서 모두 같은 문장으로 귀결된다: 인증 비활성화가 기본값이다.

출처가 입증하는 것과 입증하지 못하는 것

메커니즘, 버전 범위, 수정 사항, 공로는 권고문, JFrog가 할당한 CVE 기록, 프로젝트 자체의 풀 리퀘스트와 릴리스 노트, 그리고 The Hacker News 전반에서 합의되어 있다. 남은 이견은 심각도에 관한 것이며, 그것은 실재한다.

9.8은 할당 CNA인 JFrog의 점수이며, NVD가 보유한 점수이기도 합니다 — NVD 레코드는 reefs@jfrog.com을 지표 출처로 명시하고 있으며, 2026년 10월 28일 기준으로 해당 항목을 여전히 "Awaiting Analysis" 상태로 표시하고 있는데, 이는 NVD가 자체 분석이 아닌 할당자의 벡터를 게시했음을 의미합니다. 같은 레코드에 첨부된 CISA 코디네이터의 SSVC 평가는 2026년 9월 14일 타임스탬프로, 악용 "none", 자동화 가능 "yes", 기술적 영향 "total"로 기록되어 있습니다. FIRST의 EPSS 모델은 2026년 10월 27일 기준 향후 30일 내 악용 확률을 2.3퍼센트로 산정했으며, 이는 점수가 산정된 모든 CVE 중 83번째 백분위수에 해당합니다. 또한 이 CVE와 CVE-2026-86242는 모두 2026년 10월 27일자 CISA Known Exploited Vulnerabilities 목록에 나타나지 않습니다.

이에 반해 Maxim은 해당 등급에 이의를 제기한다. The Hacker News에 보낸 성명에서 회사의 최고기술책임자(CTO)이자 공동 창업자인 Akshay Deo는 실질적 위험은 치명적 점수가 시사하는 것보다 낮다고 말했다. 악용하려면 관리 인터페이스가 신뢰할 수 없는 네트워크에서 접근 가능해야 하고 운영자가 인증을 설정하지 않은 채 남겨두어야 하기 때문이다. 그에 따르면 기본 및 문서화된 배포 방식은 게이트웨이를 사설 네트워크 내부에 둔다. The Hacker News는 Maxim이 이 취약점을 낮은 심각도로 간주하고 있으며, CVE를 할당한 JFrog와 함께 평가를 수정하는 작업을 진행 중이라고 보도했다. 해당 성명은 그 매체 한 곳에만 실렸다. Maxim의 입장을 인용한 두 번째 보도는 발견되지 않았고, 2026년 10월 28일 기준으로 수정본은 게시되지 않았다. CVE 기록은 9월 14일에, NVD 항목은 9월 18일에 마지막으로 업데이트되었으며 둘 다 여전히 9.8이다.

두 가지 추가 격차는 덮어두기보다 짚고 넘어갈 가치가 있다. 2026년 9월 23일 게시되었고 JFrog 연구원을 신고자로 명시한 프로젝트의 GitHub 보안 권고는 여전히 MCP 결함에 9.8, 플러그인 결함에 8.1을 유지하고 있으며, Maxim이 설명한 수정의 흔적은 보이지 않는다. 또한 해당 권고의 영향 범위는 JFrog 권고가 사용하는 transports 릴리스 태그가 아니라 Go 모듈 버전, 즉 1.5.27 미만 및 1.6.3 미만을 기준으로 작성되어 있다. 따라서 한 문서를 다른 문서와 대조하는 운영자는 빌드가 영향을 받는지 판단하기 전에 두 가지 번호 체계를 조정해야 한다.

무엇이 바뀌었고, 운영자들은 무엇을 하라는 지시를 받았나

연대기는 공개 시점부터 거꾸로 흐르는데, 이는 기록에서 가장 직관적이지 않은 부분이다. 풀 리퀘스트 #6757은 2026년 9월 2일에 병합되었다. 권고문이 수정 사항을 처음 포함한 릴리스로 지목한 transports/v2.1.0은 9월 8일에 게시되었다 — CVE-2026-90898이 9월 14일에 공개되기 엿새 전이었다. 프로젝트의 플러그인 수정도 같은 방식으로 자체 권고문보다 앞섰다: transports/v2.0.0은 8월 26일에 출시되었는데, 9월 6일 CVE보다 11일 앞선 것이었다. 피드보다 릴리스를 추적하는 운영자는 경고를 받기 전에 패치를 이미 갖고 있었다.

업그레이드로 얻는 것은 좁지만 구체적이다. 2.1.0 이상에서는 인증되지 않은 stdio 등록이 403을 반환하고 해당 명령은 시작되지 않는다. 인증된 관리자는 이 기능을 계속 사용할 수 있으며, config.json 프로비저닝도 여전히 작동한다. 업그레이드할 수 없는 이들을 위한 보안 권고의 임시 방편은 governance.auth_config.is_enabled를 true로 설정하고, 강력한 관리자 자격 증명을 사용하며, 관리 리스너를 신뢰할 수 없는 네트워크에 두지 않는 것이다. 인증이 비활성화된 상태로 노출되어 운영된 인스턴스에 대한 JFrog의 지침은 조사하면서 희망을 걸라는 것이 아니다. 해당 인스턴스를 침해된 것으로 간주하고 가상 키와 공급자 자격 증명을 교체하라.

가장 잘못 읽기 쉬운 부분은 버전 계산입니다. v2.0.0은 이 결함을 수정하지 않습니다. 1.6.x 계열은 1.6.11까지도 이 수정을 포함하지 않으며, 이 프로젝트의 가장 최신 1.6 계열 태그는 2026년 8월 14일에 게시된 transports/v1.6.11이고, 2026년 10월 28일 현재 저장소에 1.7 계열은 없습니다. 따라서 해당 계열 안에는 패치된 릴리스가 없고, 1.6.x 운영자는 백포트를 기다리는 대신 2.1.0 이상으로 넘어가야 합니다. 현재 릴리스 계열은 그 지점을 훨씬 지나 있습니다. transports/v2.3.2는 2026년 10월 20일에 게시되었습니다.

공개 이후 방어자가 활용할 수 있는 두 가지 일이 발생했습니다. 프로젝트의 GitHub 보안 권고인 GHSA-86gf-xh3g-rvxq(MCP 결함, 심각도 critical)와 GHSA-2qp8-4xgm-fw6g(플러그인 결함, 심각도 high)가 2026년 9월 23일에 게시되면서 종속성 및 권고 피드가 대조할 두 번째 식별자가 생겼습니다. 그리고 2026년 10월 13일에는 CVE-2026-90898에 대한 탐지 템플릿이 공개 nuclei-templates 저장소에 병합되었습니다. 이는 인증되지 않은 등록 시도에 대한 검사가 이제 각 팀이 직접 작성해야 하는 것이 아니라 스캐닝 파이프라인이 실행할 수 있는 것이 되었음을 의미합니다.

남아 있는 쟁점은 심각도이며, 이는 아직 논의 중인 두 조직에 의해 결정될 수도 있고 그렇지 않을 수도 있다. 보도된 대로 Maxim의 입장은 9.8이 노출된 리스너와 설정되지 않은 기본값이 있어야 문제가 되는 결함을 과대평가한다는 것이다. 이는 원칙적으로 검증 가능하지만 공개적으로는 검증되지 않은 주장인데, 두 조건을 충족한 배포가 얼마나 되는지 아무도 공개하지 않았기 때문이다. JFrog의 입장은 CNA로서 부여한 점수이며, 이는 CVE 레코드와 NVD에 여전히 남아 있다. 둘 중 하나가 개정판을 공개할 때까지 운영상의 해석은 어느 쪽이든 같다. 즉, 이 결함은 실제이며 공개된 컨테이너 이미지에서 엔드투엔드로 검증되었고, 수정 사항은 경고보다 먼저 배포되었으며, 1.6 시리즈에는 수정 사항이 전혀 없고, 접근 가능한 리스너에서 인증이 비활성화된 채 실행된 모든 인스턴스는 패치 일정을 잡을 대상이 아니라 자격 증명 사고로 취급해야 한다.