메타베이스 취약점 CVSS 10.0, SQL 인젝션 제로데이 전체 정리

Bykolio

사내 대시보드로 쓰던 Metabase가 인터넷에 노출되어 있다면, 로그인 없이 SQL 인젝션이 가능한 취약점은 곧바로 데이터베이스 연결 정보와 관리자 권한 탈취로 이어질 수 있습니다. 이런 취약점에서 병목은 패치 자체가 아니라 내 인스턴스의 버전과 노출 여부를 빠르게 파악하는 일입니다.

이 글은 메타베이스 취약점의 위험 구조와 영향 범위, 침해 여부를 점검하는 방법을 정리하고, 버전 확인과 SQL 인젝션 방어 코드를 소개합니다. 영향 버전과 패치 버전은 Metabase 공식 보안 공지를 반드시 확인하세요.

메타베이스 취약점, CVE-2026-72898의 정체

메타베이스 취약점 CVSS 10.0, SQL 인젝션으로 관리자 권한 탈취

메타베이스는 데이터를 시각화하고 대시보드로 공유하는 오픈소스 비즈니스 인텔리전스(BI) 도구로, 스타트업과 기업에서 널리 쓰입니다.

이번에 공개된 취약점은 CVE-2026-72898로 등록되었으며, CVSS 점수가 만점인 10.0을 기록했습니다.

공격자는 로그인하지 않은 상태에서도 SQL 인젝션 공격을 통해 메타베이스 관리자 권한을 확보할 수 있습니다.

이 취약점이 위험한 이유: 인증 없이 도달하는 SQL 인젝션

취약점을 악용하면 관리자 권한 확보에 그치지 않고, 연결된 데이터베이스의 인증정보를 탈취해 데이터 자체를 외부로 반출하는 것까지 가능합니다.

# 취약한 방식: 입력을 문자열로 이어 붙임
cur.execute("SELECT * FROM users WHERE name = '" + name + "'")
# name = "x' OR '1'='1" 이면 조건이 항상 참이 된다

# 안전한 방식: 매개변수 바인딩
cur.execute("SELECT * FROM users WHERE name = %s", (name,))

문자열 연결 방식에서는 입력값이 SQL 구문의 일부로 해석되어 작은따옴표 하나로 쿼리 구조가 바뀝니다. 매개변수 바인딩은 쿼리 구조를 먼저 데이터베이스에 보내고 값은 데이터로만 전달하므로, 입력에 따옴표가 있어도 구문으로 해석되지 않습니다. 인증 이전 단계에 이런 결함이 있으면 공격자가 로그인 없이 접근할 수 있다는 점이 위험도를 가장 크게 높입니다.

즉 대시보드 화면만 노출되는 수준이 아니라, 메타베이스가 연결하고 있는 백엔드 데이터베이스 전체가 공격 대상이 되는 구조입니다.

영향 범위, 어떤 버전이 위험할까

이번 이슈의 영향을 받는 버전은 58부터 63 계열까지입니다.

“SQL 인젝션 방어의 1순위는 준비된 구문(매개변수화된 쿼리)을 사용하는 것이다.”
— OWASP, SQL Injection Prevention Cheat Sheet (요약 인용)

해당 버전대의 메타베이스를 자체 호스팅으로 운영 중이라면 공격에 노출되어 있을 가능성이 높습니다.

메타베이스 취약점으로 실제 발생한 피해 사례

메타베이스 취약점 실제 피해 사례 Framework Tally n8n

이 문제는 이미 여러 기업에서 실제 피해로 이어졌습니다.

Framework에서는 이름, 이메일, IP 주소, 전화번호 등 고객정보가 유출됐습니다.

Tally에서는 이메일과 비밀번호 해시값이 노출됐고, n8n에서도 이름, 이메일, 비밀번호 해시 데이터가 조회된 사실이 확인됐습니다.

메타베이스 취약점 침해 여부, 우리 회사도 확인이 필요할까

메타베이스를 운영 중이라면 실제 침해 흔적이 있었는지 먼저 확인하는 것이 순서입니다.

POST 방식으로 /api/session/reset_password 요청을 보낸 뒤 GET /api/user/current 요청이 성공한 기록이 로그에 남아 있는지 확인하면 공격 시도 여부를 가늠할 수 있습니다.

이런 패턴의 요청 기록이 남아 있다면 이미 공격을 받았을 가능성이 높으므로 즉시 대응 절차에 들어가야 합니다.

메타베이스 취약점 대응 방법, 지금 당장 해야 할 조치

메타베이스 취약점 대응 4단계 패치 세션종료 계정점검 비밀번호변경

대응은 속도가 생명입니다.

# 내 Metabase 인스턴스의 버전 확인 (외부 노출 여부도 함께 점검)
curl -s https://metabase.example.com/api/session/properties | jq -r '.version.tag'

# 컨테이너 환경에서 패치된 이미지로 교체 (태그는 공식 공지의 패치 버전으로)
docker pull metabase/metabase:v0.xx.x
docker stop metabase && docker rm metabase
docker run -d --name metabase -p 3000:3000 metabase/metabase:v0.xx.x

세션 속성 API는 인증 없이 버전 정보를 반환하므로 현재 버전을 즉시 확인할 수 있고, 이 정보가 외부에서 보인다는 사실 자체가 노출 점검의 단서가 됩니다. 이미지 교체 전에는 애플리케이션 데이터베이스를 반드시 백업하고, 패치 이후에는 관리자 계정과 데이터베이스 연결 비밀번호를 교체해야 침해가 있었을 경우를 대비할 수 있습니다.

가장 먼저 최신 버전으로 즉시 패치를 적용해야 합니다.

패치 후에는 모든 사용자 세션을 강제로 종료하고, 관리자 계정과 API 키가 그대로인지 점검해야 합니다.

메타베이스가 연결하고 있는 데이터베이스의 비밀번호도 이 기회에 함께 변경하는 것이 안전합니다.

메타베이스 취약점 관련 심화 질문

Q. 사내망에서만 쓰면 위험하지 않나요?

외부에 노출되지 않았더라도 내부 침입자나 이미 침투한 호스트가 악용할 수 있습니다. 패치와 접근 통제를 함께 적용해야 합니다.

Q. 패치 전까지 임시로 막을 방법이 있나요?

방화벽이나 리버스 프록시에서 접근 IP를 제한하거나 인스턴스를 일시 중지하는 방법이 있습니다. 공식 공지의 완화 조치가 있다면 우선 적용하세요.

Q. 침해 여부는 어떻게 확인하나요?

접근 로그에서 비정상 요청, 새로 생긴 관리자 계정, 변경된 데이터베이스 연결 설정을 점검합니다. 의심되면 연결 계정의 비밀번호를 교체하세요.

Q. 업그레이드 중 대시보드가 깨지지 않나요?

큰 버전 점프는 호환성 이슈가 있을 수 있어 백업과 스테이징 환경에서의 사전 검증이 필요합니다.

함께 보면 좋은 글

참고자료 및 공식 정보 안내

📌 안내
이 글은 정보 제공을 목적으로 작성되었으며, 실제 기기·환경·정책에 따라 결과가 다를 수 있습니다. 보다 정확하고 최신인 정보는 아래 공신력 있는 기관의 자료를 함께 참고하시기 바랍니다.

Similar Posts