Metabase: gaură cu scor 10.0 exploatată activ, fără CVE

Versiunile afectate

Sunt șase ramuri de versiuni în paralel, fiecare cu propria versiune reparată. În notația de mai sus, x este 0 pentru ediția OSS și 1 pentru Enterprise. Nu e suficient să știi că ai „Metabase recent" — trebuie să compari exact numărul tău cu ramura corespunzătoare.

Exploatarea a fost confirmată pe instanțe Metabase Cloud începând cu 1.58.

• ▸ramura x.58: de la x.58.0 până la x.58.23 — reparat în x.58.24
• ▸ramura x.59: de la x.59.0 până la x.59.20 — reparat în x.59.21
• ▸ramura x.60: de la x.60.0 până la x.60.16 — reparat în x.60.17
• ▸ramura x.61: de la x.61.0 până la x.61.10 — reparat în x.61.11
• ▸ramura x.62: de la x.62.0 până la x.62.8 — reparat în x.62.9
• ▸ramura x.63: de la x.63.0 până la x.63.4 — reparat în x.63.5

• ▸GitHub Security Advisory — GHSA-vwf4-m7j8-wcjf

Ce obține atacatorul

Injecția SQL nu vizează datele tale de business, ci baza de date a aplicației Metabase în sine. Diferența e importantă: de acolo se obține direct acces de administrator în platformă.

Cu acel nivel de acces, atacatorul poate modifica configurația aplicației, poate extrage credențialele bazelor de date conectate, poate citi datele accesibile și le poate exporta.

Ultimul punct e cel care transformă incidentul dintr-o problemă de aplicație într-una de organizație. Metabase e o unealtă de business intelligence: prin definiție e conectată la sursele de date care contează. Credențialele pe care le păstrează sunt cheile către altceva.

Cazul Framework

Producătorul de laptopuri Framework a fost compromis prin această vulnerabilitate. Au fost accesate nume de clienți, adrese IP de conectare, adrese poștale, numere de telefon și adrese de e-mail.

E util să vezi ce listă rezultă: nu parole, nu date de card. Exact tipul de set de date pe care îl produce o platformă de raportare atunci când cineva îi cere să exporte ce vede.

Pentru o organizație aflată sub NIS2 sau GDPR, un astfel de export declanșează evaluarea formală a obligațiilor de raportare și, în funcție de impact și risc, poate necesita notificare. Nu este doar o remediere tehnică; merită decis din timp cine face evaluarea și pe ce criterii.

Cum verifici dacă ai fost lovit

Există un indicator de compromitere concret, ușor de căutat în jurnalele serverului web sau ale proxy-ului din față.

Tiparul e o cerere POST către /api/session/reset_password care întoarce cod 400, urmată de o cerere GET către /api/user/current care întoarce 200.

Citit în clar: o încercare de resetare a parolei care eșuează, urmată imediat de o cerere autentificată care reușește. Dacă vezi această succesiune, tratează instanța ca fiind compromisă și treci pe procedura de incident, nu doar pe patch.

• ▸Metabase — actualizarea oficială de securitate și indicatorul de atac

Ce faci practic, în ordine

• ▸Actualizează la versiunea reparată de pe ramura ta — verifică numărul exact, nu presupune
• ▸Dacă nu poți actualiza imediat, blochează endpointul /api/session/reset_password la nivel de proxy sau firewall de aplicație, ca măsură temporară
• ▸Caută în jurnale tiparul POST reset_password cu 400 urmat de GET user/current cu 200
• ▸Rotește credențialele bazelor de date conectate la Metabase — dacă instanța a fost compromisă, ele au fost accesibile
• ▸Verifică dacă instanța e expusă public; o unealtă internă de raportare rareori are motiv să fie
• ▸Revizuiește conturile de administrator din Metabase pentru intrări create sau modificate recent

Problema din spate: fără CVE, nu apare în multe fluxuri

O vulnerabilitate cu scor maxim, exploatată activ, într-un produs folosit pe scară largă, care nu are număr CVE. Nu e o anomalie birocratică — e o consecință previzibilă a felului în care funcționează sistemul.

GitHub e o autoritate de numerotare, iar avizele pentru proiecte găzduite acolo pot exista ca GHSA fără să primească neapărat un CVE, sau înainte să îl primească. Multe unelte de monitorizare, tablouri de bord de conformitate și procese interne pornesc însă de la premisa că orice contează are un CVE.

Concluzia practică nu e că sistemul CVE e stricat, ci că o singură sursă nu e suficientă. Dacă lista ta de priorități se construiește exclusiv din NVD, ai un punct orb pe care nimeni nu îl semnalează, pentru că absența nu declanșează nicio alertă.

• ▸CISA — catalogul vulnerabilităților exploatate cunoscute

Ce nu știm încă

Nu s-a publicat o estimare a numărului de instanțe compromise, nici o atribuire a atacatorilor. Nu știm de când a început exploatarea înainte de dezvăluire.

Framework se numără printre organizațiile care și-au notificat public clienții. Nu există însă o listă completă a victimelor și nu trebuie extrapolat un total din cazurile care au comunicat.

Dacă vulnerabilitatea primește ulterior un CVE și intră în catalogul CISA KEV, termenul asociat devine obligatoriu pentru agențiile federale americane aflate sub BOD 22-01. Merită urmărit, dar nu e un motiv de a aștepta: patch-ul există deja.