CVE-2026-72898은 자격증명 없이 Metabase 관리자 권한을 얻을 수 있었던 취약점입니다. 그 권한으로 Metabase가 연결한 데이터와 자격증명에도 닿을 수 있었습니다.
Metabase 비밀번호 재설정 엔드포인트에 인증 없이 요청 하나만 보내면 애플리케이션 데이터베이스에 임의의 SQL을 주입할 수 있었습니다. 그 결과 공격자는 관리자 권한을 얻었습니다. 자격증명도 사용자 상호작용도 필요 없었습니다. CVE 기록은 v3.1과 v4.0 모두에서 최고점인 CVSS 10.0을 받았습니다. CISA는 2026년 8월 11일 실제 악용을 확인하고 이 취약점을 알려진 악용 취약점(KEV) 카탈로그에 추가했습니다. CISA가 정한 연방기관 조치 기한인 2026년 8월 14일은 이미 지났습니다.
API가 걸러내지 못한 user-id 필드
CVE-2026-72898은 POST /api/session/reset_password에 있었습니다. Wiz의 기술 분석에 따르면 공격자가 넣은 user-id 필드는 인증 실패 경로에서 Metabase의 요청 병합 로직을 통과했습니다. HoneySQL의 :raw 키워드는 이 값을 바인딩 파라미터로 묶지 않고 SQL 문자열 그대로 처리했습니다. 원래는 걸러졌어야 할 필드가 그대로 들어가면서 인증되지 않은 SQL 인젝션이 가능해졌습니다. 진짜 문제는 한 계층 위, 어떤 필드를 안전하다고 볼지 판단하는 프레임워크 로직에 있었습니다.
이 버그는 0.58부터 0.63까지 여섯 버전 계열 전체에 있었고, 오픈소스와 Enterprise/Cloud 모두에 영향을 줬습니다. Metabase는 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5(그리고 병행된 1.x Enterprise 계열)에서 이를 패치했습니다. 2026년 8월 6일 권고문을 내면서 Metabase Cloud도 같은 결함을 노린 제로데이 공격을 이미 받았다고 밝혔습니다. 공개 PoC 코드는 권고문이 나오고 나흘 뒤인 8월 10일 UTC 정오에 이미 돌고 있었습니다. 권고문이 나온 뒤 누구나 실행할 수 있는 익스플로잇이 등장하기까지 걸린 시간은 몇 주가 아니라 며칠이었습니다.
Metabase의 권고문은 악용 여부를 확인할 로그 패턴도 공개했습니다. POST /api/session/reset_password가 HTTP 400을 반환한 뒤 GET /api/user/current가 HTTP 200을 반환하는 두 요청입니다. 인스턴스가 마지막으로 패치 전 버전을 실행한 시점까지 거슬러 올라가 서버 로그에서 이 패턴을 확인해야 합니다. Metabase는 이 패턴이 보이면 인스턴스가 이미 침해됐을 가능성이 높다고 설명합니다. 정리 절차는 core_session 테이블의 모든 행을 지우고 데이터베이스 자격증명을 교체하는 일부터 시작합니다.
관리자 권한으로 접근할 수 있었던 범위
SQL 인젝션에 성공한 공격자는 일반 Metabase 관리자와 같은 권한을 얻습니다. Metabase 권고문은 그 범위를 직접 밝힙니다. "애플리케이션 설정 변경, 연결된 데이터베이스에 저장된 자격증명 탈취, 그 연결을 통해 접근 가능한 모든 데이터 조회, 데이터 내보내기."
Metabase는 회사의 웨어하우스, 프로덕션 레플리카, 분석 데이터 소스를 연결해 쓰는 비즈니스 인텔리전스(BI) 도구입니다. 이 취약점의 위험은 비밀번호 재설정 기능 하나에만 있지 않았습니다. 공격자가 얻은 관리자 권한이 원래 접근할 수 있는 범위가 넓었기 때문에 침해도 전면적으로 이어졌습니다.
n8n은 자체 공개에서 패치 사흘 전인 8월 3일 무단 접근이 있었고, 136건의 레코드가 접근됐으며 그중 5건에는 bcrypt 해시 비밀번호가 있었다고 밝혔습니다. Framework와 Tally도 각각 침해 사실을 공개했습니다. Framework는 고객 이름, IP 주소, 청구·배송 주소, 전화번호가 유출됐다고 했고, Tally는 이메일 주소와 비밀번호 해시 유출을 확인했습니다. Kilo Code의 공개에 따르면 일부 사용자의 Slack 액세스 토큰도 노출됐다가 나중에 무효화됐습니다.
네 회사에서 나온 데이터는 서로 달랐습니다. 이름과 IP 주소, 물리적 주소, 전화번호, 이메일 주소, 비밀번호 해시, 다른 SaaS 제품의 액세스 토큰까지 포함됐습니다. 모두 같은 관리자 세션에서 시작된 피해였습니다.
BI 관리자 계정이 가진 위험
BI 도구의 관리자 역할은 쿼리를 실행하는 권한이면서 자격증명을 보관하는 위치이기도 합니다. 분석가가 Metabase에 설정한 웨어하우스 연결은 SQL 인젝션으로 접근한 애플리케이션 데이터베이스에 연결 문자열로 저장돼 있었습니다. 별도의 시크릿 관리자를 거치거나 두 번째 자격증명을 훔칠 필요가 없었습니다. 보통은 탈취한 계정으로 자격증명 저장소에 들어간 뒤 다른 자원에 접근합니다. 이 경우에는 애플리케이션에 접근하는 것 자체가 자격증명 저장소에 접근하는 일이었습니다.
로그인 폼이 뚫리면 피해는 그 화면에서 끝나지 않습니다. 계정에 허용된 작업과 연결된 데이터가 함께 노출될 수 있습니다. 이번 사건에서는 Metabase 뒤에 연결된 웨어하우스도 영향을 받을 수 있었습니다. 접근 권한 검토에서는 "누가 BI 도구의 관리자 권한을 가졌는가"만으로 충분하지 않습니다. 누군가 관리자 계정에 들어왔을 때 어떤 자격증명과 데이터에 닿는지도 확인해야 합니다. 웨어하우스 자격증명은 탈취된 비밀번호와 달리 티가 나지 않습니다.
아직 패치하지 않았다면 지금 해야 합니다. 연방기관 기한은 이미 지났고 공개 PoC도 몇 주째 돌고 있습니다. 패치했더라도 서버 로그에서 탐지 패턴을 grep으로 확인해야 합니다. 많은 팀이 점검을 시작하기도 전에 패치되지 않은 구간이 있었기 때문입니다. 관리자 권한이 연결된 모든 웨어하우스에 접근할 수 있어야 할 이유도 없습니다.
이는 Metabase만의 교훈이 아니고, IdP(신원 제공자)가 대신 막아 줄 수 있는 문제도 아닙니다. Okta 같은 SSO도 누가 BI 도구에 들어갈 수 있는지만 확인할 뿐, 탈취한 웨어하우스 자격증명을 인프라에 직접 겨눴을 때 무엇에 닿는지는 말해 주지 않습니다. 그건 별도의 층위입니다. 그 자격증명이 놓인 서버에서 실제로 무엇을 실행할 수 있는지를 다루는 층위입니다.
