Metabase heeft urgente patches uitgebracht voor een kritieke Metabase SQL-injectie die al in het wild is misbruikt als zero-day. Het gaat om een kwetsbaarheid met een hoge impact: aanvallers kunnen via remote, en zonder authenticatie, willekeurige SQL-queries injecteren en vervolgens administratieve toegang krijgen tot de Metabase-omgeving.
Omdat de fout doorlopend werd misbruikt, is het voor organisaties met Metabase (zeker zelfhosting) belangrijk om snel te handelen: patchen waar mogelijk, en anders direct de voorgestelde tijdelijke mitigatie toepassen.
Wat is er mis met de Metabase SQL-injectie?
De kwetsbaarheid maakt het mogelijk dat een aanvaller zonder inloggegevens SQL-instructies kan laten uitvoeren in de database van Metabase. Daarmee kan de aanvaller verdergaan dan alleen lezen: de aanvaller kan volgens de advisering ook configuraties aanpassen, opgeslagen database-credentials stelen en gegevens exporteren die via aangesloten databaseverbindingen toegankelijk zijn.
Metabase meldt ook dat er nog geen CVE-nummer aan de bug was gekoppeld. Wel is duidelijk dat de ontdekking plaatsvond nadat een dreigingsacteur deze fout als zero-day inzette in een aanval die gericht was op Metabase Cloud.
Welke actie moet u nu nemen?
Metabase Cloud-instanties zijn volgens de fabrikant al bijgewerkt en gepatcht. Gebruikers die Metabase zelf hosten, wordt aangeraden om de patch zo snel mogelijk toe te passen om blootstelling te voorkomen.
Kan of lukt patching niet direct? Dan beschrijft Metabase een tijdelijke noodmaatregel die de aanvalsvector beperkt.
Snelle noodmaatregel: blokkeer /api/session/reset_password
Als u (nog) niet kunt patchen, adviseert Metabase om het endpoint /api/session/reset_password te blokkeren. Dit werkt als tijdelijke workaround, vooral wanneer dat endpoint vanuit het internet bereikbaar is.
Is dat endpoint publiek bereikbaar? Volg dan de volgorde: eerst patchen, daarna een reeks opschonings- en controleacties uitvoeren (zie verderop).
Welke Metabase versies zijn gepatcht?
Volgens Metabase bevatten de volgende versies de benodigde fixes:
- 63.5
- 62.9
- 61.11
- 60.17
- 59.21
- 58.24
Controleer dus uw huidige Metabase-versie en upgrade tijdig. Zeker bij omgevingen waar Metabase data verbindt met meerdere databases is een snelle update cruciaal.
Wat te doen als u meteen gepatcht heeft
Als u patcht (of wanneer u ziet dat het endpoint al geblokkeerd is), raadt Metabase aan om meteen ook sessies en toegang te herzien. Dat helpt om schade te beperken, zeker wanneer er al misbruik heeft plaatsgevonden.
De checklist van Metabase omvat:
- Revoke alle actieve gebruikerssessies.
- Bekijk API keys en verwijder sleutels die niet herkend worden.
- Controleer administratieve accounts op ongebruikelijke of nieuw aangemaakte gebruikers.
- Roteer (vervang) credentials voor alle databaseverbindingen die gekoppeld zijn aan Metabase.
- Bekijk logs en Metabase-activiteiten voor aanwijzingen van verdachte toegang.
Hoe herkent u mogelijke compromittering?
Om in te schatten of uw Metabase-instance is geraakt, geeft Metabase een patroon dat u kunt terugzien in uw logs. Het gaat om een combinatie van twee requests:
- Een “POST /api/session/reset_password” call met statuscode ‘400’.
- Daarna een “GET /api/user/current” call met statuscode ‘200’.
Als u dit patroon terugziet in uw applicatielogs of in Metabase-server ingress logs, is het volgens Metabase waarschijnlijk dat de instantie gecompromitteerd is. Onderzoek in dat geval ook de tijdlijn: welke IP-adressen, gebruikersagents en gekoppelde sessies speelden wanneer een rol?
Waarom dit type aanval extra risicovol is
Veel kwetsbaarheden stoppen bij een lees- of schrijfbewerking. Bij deze Metabase SQL-injectie ligt de impact breder: aanvallers kunnen database-queries laten uitvoeren, vervolgens credentials gebruiken en daarna toegang tot data en exportmogelijkheden organiseren. Dat maakt het niet alleen een “applicatieprobleem”, maar ook een data- en toegangsrisico.
Daarnaast is Metabase vaak een centrale schakel in organisaties voor rapportage en analyse. Als een aanvaller daar administratieve controle krijgt, kan dat ook doorwerken naar downstream processen en data-inzichten.
Praktische context: hou security bij patchen en opvolgen
Security updates zijn effectiever als u ze combineert met controleren en opschonen. Zo is het niet alleen belangrijk dat u patched draait, maar ook dat u detectie en response inricht op tekenen van misbruik. Denk daarbij ook aan eerder gemelde kwesties rond kwetsbaarheden die als zero-day worden uitgebuit of die snel patchen vereisen, zoals bij andere toegangsgerelateerde problemen.
Als u wilt zien hoe snel handelen bij misbruikde kwetsbaarheden eruit kan zien, is dit artikel relevant: CVE-2026-8037: patch direct voor LoadMaster.
En als u vooral kijkt naar aanvallen die via een endpoint of serviceketen toegang proberen te forceren, kan dit ook helpen in uw bredere triage: Metabase zero-day: admintoegang zonder authenticatie.
Conclusie
De Metabase SQL-injectie die als zero-day is misbruikt, is door Metabase gepatcht in meerdere versies. Voor zelfhosting is het devies: patch zo snel mogelijk, of blokkeer tijdelijk /api/session/reset_password als u niet direct kunt updaten.
Daarna volgt de belangrijke stap: sessies intrekken, API keys opschonen, administratieve accounts controleren, databasecredentials roteren en logs nalopen op het specifieke requestpatroon. Zo verkleint u de kans dat een incident doorwerkt, ook nadat de patch is toegepast.
Bron: https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
