0.58부터 63.4까지, Metabase 비밀번호 재설정에 열려 있던 SQL 인젝션

이미지 출처: CISA KEV

점수판에서 10.0은 더 내려갈 곳이 없다는 뜻임. CVE-2026-72898에 붙은 CVSS 3.1 점수가 정확히 그 10.0이고, 인증 없음·사용자 상호작용 없음·공격 난이도 낮음이 한 줄에 다 모여 있음. 게다가 패치가 나오기 전부터 실제 공격에 쓰이던 제로데이였고, 8월 11일자로 CISA 악용 목록에도 올라갔음. BI 대시보드 하나 띄워두려고 사내에 올려둔 Metabase가 지금 이 순간 외부에서 관리자 계정으로 접수당할 수 있는 상태라는 얘기임.

핵심 요약

• Metabase의 비밀번호 재설정 처리 경로에서 인증 없이 애플리케이션 DB에 SQL을 주입할 수 있고, 결과는 관리자 권한 탈취임(CWE-89, CVSS 10.0).
• 1.58 계열부터 0.63.4까지 영향을 받으며 v58.24, v59.21, v60.17, v61.11, v62.9, v63.5에서 수정됨.
• 패치가 1순위이고, 그 다음이 재설정 엔드포인트 요청 로그와 신규·권한변경 계정 점검임.

어디가 문제였나

Metabase는 자체 애플리케이션 DB(계정, 대시보드 정의, 커넥션 정보 등이 들어 있는 메타데이터 저장소)를 따로 씀. 이번 결함은 사용자가 "비밀번호를 잊었어요"를 눌렀을 때 들어오는 값이 SQL 문장으로 조립되는 과정에서 제대로 격리되지 않아 생긴 것임. 전형적인 CWE-89, 그러니까 교과서 1장에 나오는 그 SQL 인젝션임.

기술적으로 새로운 기법이 등장한 건 아님. 다만 위치가 지독하게 나쁨. 비밀번호 재설정은 정의상 로그인하지 않은 사람이 두드리는 문이라, 인증 뒤에 숨겨둘 수가 없음. 그래서 인터넷에 노출된 Metabase는 방화벽 뒤든 아니든 그 문 하나만으로 공격 표면이 완성됨.

공격자가 얻는 것도 단순한 정보 열람이 아님. 애플리케이션 DB의 레코드를 바꿀 수 있으니 계정 권한을 관리자로 올리거나 계정을 새로 만들 수 있고, 관리자가 되면 Metabase에 등록된 모든 데이터소스 연결이 따라옴. 즉 Metabase 한 대가 뚫리면 그 뒤에 물려 있는 운영 DB들이 통째로 조회 가능한 상태가 됨. 재현 절차는 여기까지 개념으로만 남기겠음. 실제 페이로드는 이 글의 목적이 아님.

내 버전이 대상인지부터

• 영향 범위는 1.58(OSS 기준 0.58) 계열 이후 0.63.4/1.63.4까지임. 꽤 오래 묵은 결함이라 "우리는 작년에 깔았는데"가 안전의 근거가 되지 않음.
• 수정본은 v58.24, v59.21, v60.17, v61.11, v62.9, v63.5임. 메이저를 올리기 부담스러우면 쓰던 계열의 최신 패치 버전으로만 올려도 됨. 이게 현실적으로 제일 빠른 길임.
• Metabase Cloud를 쓰면 벤더가 처리했지만, 온프레미스·도커·사내 쿠버네티스에 올린 인스턴스는 각자 손을 대야 함. 개인적으로는 사내 자산 목록보다 실제로 열려 있는 포트를 스캔해서 찾는 쪽을 추천함. 담당자가 퇴사한 뒤 남아 있는 Metabase가 생각보다 많음.

탐지: 로그에서 무엇을 볼 것인가

이미 당했는지를 보려면 결국 두 군데를 봐야 함. 요청이 들어온 흔적과, 그 결과로 바뀐 상태임.

• 리버스 프록시·WAF 액세스 로그에서 비밀번호 재설정 관련 경로(/api/session/forgot_password, /auth/forgot_password 계열)로 들어온 POST 요청을 패치 배포 시점보다 넉넉히 앞선 구간까지 뽑아볼 것. 정상 사용자의 재설정은 하루에 몇 건 수준이라, 같은 IP에서 짧은 시간에 반복되거나 본문 길이가 유난히 긴 요청은 그 자체로 눈에 띔.
• 응답 시간의 분포도 힌트가 됨. 블라인드 방식으로 참·거짓을 하나씩 물어보는 공격은 응답 지연이 계단처럼 튀는 패턴을 남기는 경우가 많음.
• 계정 상태가 가장 확실한 증거임. Metabase 관리 화면의 People 목록에서 최근에 생성된 계정, 관리자 그룹에 새로 들어간 계정, 이메일 도메인이 사내와 다른 계정을 확인할 것. 애플리케이션 DB에 직접 접근할 수 있으면 core_user 테이블의 생성·수정 시각을 정렬해 보는 편이 더 빠름.
• 데이터소스 쪽 감사 로그도 같이 봐야 함. Metabase 서비스 계정으로 평소와 다른 테이블에 대량 SELECT가 나갔는지, 익숙하지 않은 시간대에 쿼리가 돌았는지가 실제 유출 여부를 가름함.

패치 이후에 해야 할 일

버전을 올렸다고 상황이 끝나는 게 아님. 취약했던 기간에 이미 관리자 계정이 하나 만들어졌다면, 패치는 그 계정을 지워주지 않음.

• Metabase에 등록된 모든 데이터소스 자격증명을 교체할 것. 관리자 권한이 넘어갔다면 연결 정보도 함께 넘어갔다고 보는 게 맞음.
• 세션을 전부 만료시키고, API 키·임베딩용 시크릿도 새로 발급할 것.
• Metabase를 인터넷에 그대로 노출해 두고 있었다면 이번 기회에 VPN이나 사내망 뒤로 넣거나, 최소한 접근 IP를 제한하는 걸 개인적으로 권함. BI 도구는 그 특성상 조직에서 가장 민감한 데이터에 붙어 있는 물건인데, 노출도는 종종 사내 위키 수준으로 관리되고 있음.
• 서비스 계정 권한도 다시 볼 것. Metabase가 운영 DB에 읽기 전용으로만 붙어 있었다면 이번 사고의 피해 크기가 확연히 달라졌을 것임.

남는 생각

SQL 인젝션이 2026년에도 CVSS 10.0을 받는다는 게 조금 허탈하긴 함. 다만 짚어둘 지점은 기법의 낡음이 아니라 위치임. 인증 앞단에 놓인 기능, 그것도 "잊어버린 사람을 돕는" 선의의 기능은 코드 리뷰에서 자주 뒷순위로 밀림. 로그인 화면 뒤의 API는 꼼꼼히 보면서 재설정 폼은 대충 넘어가는 습관, 우리 팀 코드에도 있는지 한 번쯤 뒤져볼 만함.

오늘은 일단 버전부터 확인해 보아요. 사내에 잊고 지낸 Metabase가 있었다면 댓글로 어떻게 찾아냈는지 공유해 주면 서로 도움이 될 것 같음. 같이 점검해 봅시다.