Czy Twoja instalacja Metabase 1.58+ właśnie wycieka dane klientów?

09 August 2026 7 min read 1515 words

BLUF

Tak — jeśli używasz Metabase 1.58+ self-hosted i nie wgrałeś patcha z 6/7 sierpnia 2026, instancja może już być skompromitowana. Nieznany zero-day (CVSS 10.0) w niezabezpieczonym endpoincie REST pozwolił niezalogowanemu atakującemu wstrzyknąć dowolne SQL do bazy Metabase i przejąć rolę administratora. Atakujący kradnie konfigurację, poświadczenia do podpiętych baz i wszystkie dostępne dane. Framework i Tally potwierdziły kradzież danych klientów po informacji od Metabase z 6 sierpnia 2026. Atak dotyczy Metabase Cloud i self-hosted — w chmurze provider wykonał aktualizację za klientów, w self-hosted obowiązek leży po Twojej stronie.

Najważniejsze fakty

Trzy GHSAdvisory wydane tego samego dnia (2026-08-06): GHSA-vwf4-m7j8-wcjf (SQLi przez niezabezpieczony endpoint /api/session/reset_password, CVSS 10.0, Critical, aktywna eksploatacja), GHSA-r8h2-qpfx-mx59 (SQLi przez publicznie udostępniony dashboard z field-filter, CVSS 9.6, aktywna eksploatacja), GHSA-8hmm-hrhg-ppqp (zwykły użytkownik czyta aplikacyjną bazę Metabase, w tym bcrypt hashe i — przy braku MB_ENCRYPTION_SECRET_KEY — poświadczenia do podpiętych baz w czystym tekście; CVSS 6.5).
Wersje zagrożone: Metabase 1.58 i nowsze. Minimalne wersje bezpieczne: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5.
Atak nie wymaga uwierzytelnienia w najgroźniejszym wektorze (GHSA-vwf4-m7j8-wcjf) — wystarczy osiągalność endpointu z sieci, w której stoi Metabase.
Znane ofiary z publicznym disclosure: Framework (pełne imiona, e-maile, adresy IP logowania, adresy billing/shipping, telefon, firma, dane B2B jak VAT/EIN) i Tally (środowisko Metabase API, kradzież danych 3 sierpnia 2026 bez podania pełnego zakresu). LexisNexis wysłało ostrzeżenie do klientów o zakłóceniach Diligence, Metabase API i Newsdesk.
Brak CVE na dzień publikacji — Metabase nadał GHSA, CVSS 10.0 i oznaczył „aktywnie eksploatowany". Tymczasowe obejście: blokada /api/session/reset_password do czasu patcha.
Źródło pierwotne: Metabase Security Advisory (CEO Sameer Al-Sakran, blog Metabase + 3x GitHub Security Advisory). Źródła niezależne: BleepingComputer, powiadomienia klientów Framework i Tally.

Tabela decyzyjna

Obszar	Co wiemy	Co to oznacza dla firmy B2B / produkcji	Zalecane działanie (30 / 90 dni)
Infrastruktura Metabase	Krytyczny zero-day w niezabezpieczonym endpoint REST, publicznie exploitowalny.	Każda instancja Metabase 1.58+ self-hosted, wystawiona na Internet (lub nawet w sieci korporacyjnej za VPN) była narażona od czasu opublikowania wersji 1.58 do 6/7 sierpnia 2026.	Natychmiast: patch do najbliższej bezpiecznej wersji w gałęzi. Do 30 dni: audyt dostępu sieciowego do Metabase, segmentacja, monitoring zapytań do `/api/session/reset_password`. Do 90 dni: przegląd wszystkich publicznie udostępnionych dashboardów i card.
Tożsamość i poświadczenia	Możliwość kradzieży credentials do podpiętych baz (w cleartext, jeśli brak `MB_ENCRYPTION_SECRET_KEY`).	Atakujący mógł użyć wykradzionych poświadczeń do bezpośredniego odpytania baz produkcyjnych (Postgres, Snowflake, BigQuery, Redshift) z pominięciem Metabase.	Natychmiast: rotacja poświadczeń do wszystkich podpiętych baz; ustawienie `MB_ENCRYPTION_SECRET_KEY` (jeśli nie był). Do 30 dni: wymuszenie MFA na kontach admin Metabase. Do 90 dni: secrets manager + rotacja automatyczna.
Dane i ochrona danych (RODO)	Framework i Tally potwierdziły kradzież danych klientów (imię, e-mail, IP, billing, telefon).	Wysokie ryzyko naruszenia ochrony danych osobowych w rozumieniu RODO art. 33 (zgłoszenie do UODO w 72h) — w zależności od danych, które widoczne były w panelach Metabase.	Natychmiast: przegląd logów Metabase (24–72h wstecz) pod kątem nietypowych zapytań, eksportów, zmian kont admin. Do 30 dni: ocena zakresu danych, decyzja o zgłoszeniu do UODO. Do 90 dni: DPO review + aktualizacja rejestru czynności przetwarzania.
NIS2 / KSC — obowiązki dowodowe	Sektor SaaS BI dostawca → jego klienci enterprise ponoszą ryzyko łańcucha dostaw. Incydent ilustruje art. 21 (incident response + zarządzanie ryzykiem dostawców) i art. 23 (terminy zgłoszeń) dyrektywy NIS2.	Podmioty objęte NIS2 muszą wykazać, że ich dostawcy BI zostali zinwentaryzowani i że istnieje procedura reakcji na 0-day u dostawcy.	Do 30 dni: aktualizacja inwentarza dostawców SaaS z krytycznym wpływem na dane. Do 90 dni: wpisanie scenariusza „0-day u dostawcy BI" do planu BCP/DR, przetestowanie tabletop.
Monitorowanie i detekcja	Metabase zaleca rewizję logów, kont admin, API keys, session history.	Brak publicznych IoC, ale każda niestandardowa aktywność admina (zmiana konfiguracji, eksport, nowe konta) z datą 3–8 sierpnia 2026 jest podejrzana.	Do 30 dni: audyt kont administratorów, rewizja API keys, przegląd listy podłączonych baz. Do 90 dni: alerting na masowe eksporty (>X wierszy) i zmiany konfiguracji poza oknem serwisowym.

Perspektywa inż. Marcina Białczyka

W ciągu ostatnich 18 miesięcy widziałem trzy powtarzające się schematy w incydentach wokół narzędzi BI i dashboardingu: (1) publicznie udostępnione linki do dashboardów (UUID w URL, wyłączony wymóg logowania — domyślne ustawienie Metabase), (2) brakujący MB_ENCRYPTION_SECRET_KEY w konfiguracji produkcyjnej, przez co poświadczenia do baz leżą w bazie aplikacyjnej w czystym tekście, (3) niezabezpieczone endpointy REST wystawione „tymczasowo" do debug, które zostają na lata. Każdy z tych trzech wektorów pojawił się w incydentach opisanych w GHSAdvisory z 6 sierpnia 2026.

Nie traktowałbym Metabase Cloud jako „vendor przejmie odpowiedzialność za nas". W logice NIS2 art. 21(2)(d) to podmiot objęty pozostaje odpowiedzialny za łańcuch dostaw SaaS — nie dostawca BI. W praktyce oznacza to, że w 72h od publicznego disclosure powinieneś/aś mieć: (a) listę wszystkich połączonych baz i skategoryzowaną wrażliwość danych, (b) rotację poświadczeń do baz (nie na logikę „nic nie widać w logach" — exploitacja mogła nie generować szumu w warstwie BI), (c) wpis w rejestrze incydentów z hipotezą „potencjalny dostęp 3–6 sierpnia 2026, brak dowodów wycieku / potwierdzony wyciek X". To nie jest temat, w którym „nic nie zrobiliśmy, bo nie ma IoC" jest akceptowalną pozycją w tabeli decyzyjnej.

Konsekwencja na najbliższe kwartały: organizacje z dojrzałym Continuous Readiness (TLP/NIS2) mają listę 20–30 krytycznych dostawców SaaS, którym przypisano właściciela po stronie biznesu, termin przeglądu SLA incydentu i plan reakcji na 0-day. Tam, gdzie tej listy nie ma, zacząłbym od tego — bo następny „Metabase Cloud" zdarzy się w innej kategorii (CI/CD, observability, support tooling) i te same pytania trzeba będzie zadać w 72h.

Najczęściej zadawane pytania

Czy Metabase Cloud został już naprawiony?

Tak. Według komunikatu Metabase z 6 sierpnia 2026, klienci Cloud zostali automatycznie zaktualizowani i załatani. Mimo to klienci Cloud powinni zweryfikować, czy w okresie 1–6 sierpnia 2026 nie doszło do nieautoryzowanego dostępu do ich instancji i czy poświadczenia do podpiętych baz nie zostały odczytane.

Co zrobić, jeśli nie mogę zrobić patcha w ciągu godzin?

Dla wektora GHSA-vwf4-m7j8-wcjf (CVSS 10.0) — tymczasowa blokada endpointu /api/session/reset_password na reverse proxy / WAF. Dla GHSA-r8h2-qpfx-mx59 — wyłączenie public sharing dla wszystkich dashboardów zawierających field-filter (dimension) parameters. Po patchu: rewizja kont admin, rotacja poświadczeń do podpiętych baz, przegląd logów.

Czy moje hashe haseł użytkowników Metabase wyciekły?

Wektor GHSA-8hmm-hrhg-ppqp umożliwia odczyt przez niskouprawnionego użytkownika aplikacyjnej bazy Metabase, w tym bcrypt hashy haseł sesji. Jeśli nie ustawiono MB_ENCRYPTION_SECRET_KEY (a tak jest domyślnie), ten sam wektor zwraca poświadczenia do podpiętych baz w czystym tekście. Traktuj to jako realny wyciek — bcrypt hashe są z kolei podatne na offline cracking przy słabych hasłach.

Czy mam obowiązek zgłaszać ten incydent do UODO?

To zależy od zakresu danych, które były widoczne w Twoich panelach Metabase, oraz od wyników przeglądu logów z okresu 1–6 sierpnia 2026. RODO art. 33 wymaga zgłoszenia w 72h, jeśli istnieje ryzyko naruszenia praw osób, których dane dotyczą. Interpretacja prawna wymaga konsultacji z kancelarią — CHORS samodzielnie nie wydaje opinii prawnej.

Czy to incydent łańcucha dostaw, który wlicza się do obowiązków NIS2?

Tak. Dla podmiotów objętych NIS2 art. 21(2)(d) zarządzanie ryzykiem łańcucha dostaw obejmuje krytycznych dostawców SaaS przetwarzających dane operacyjne. Ten incydent jest ilustracją i powinien trafić do Twojego rejestru incydentów jako case study wewnętrzne.

Jak CHORS.NET pomaga

Jeśli wdrażasz poprawki dla Metabase i chcesz sprawdzić, czy Twoja instalacja (oraz cała infrastruktura BI) nie była narażona, CHORS.NET pomoże Ci w audycie ekspozycji internetowej, uporządkowaniu dostępu sieciowego i przygotowaniu organizacji na scenariusze zero-day u dostawców SaaS — również w kontekście NIS2/KSC.

Granice i założenia

Nie jesteśmy SOC 24/7 i nie gwarantujemy wykrycia każdego incydentu u dostawcy SaaS; ten materiał ma charakter informacyjny, nie zastępuje ciągłego monitoringu.
Nie certyfikujemy zgodności z NIS2/KSC i nie wydajemy samodzielnej opinii prawnej. W zakresie interpretacji prawa CHORS współpracuje z kancelariami.
Wyniki dotyczą stanu wiedzy na 7 sierpnia 2026. Metabase może wydać dodatkowe advisory lub CVE w kolejnych dniach — zalecamy ponowny przegląd przed podjęciem decyzji końcowych.
Materiał ma charakter informacyjny i techniczny; nie stanowi porady prawnej.

Precyzyjna wiedza
o ciemnych systemach.