Hullet i Metabase ga administratortilgang uten pålogging

Metabase kunngjorde 6. august at Metabase Cloud var angrepet gjennom en sårbarhet ingen kjente til på forhånd, og at feilen nå er rettet. Sårbarheten har fått nummeret CVE-2026-72898, og leverandørens sikkerhetsvarsel setter alvorlighetsgraden til 10 av 10 etter CVSS 3.1. Metabase bekrefter at sårbarheten utnyttes aktivt. Den rammer versjon 58 og nyere, til og med gren 63. Metabase Cloud er allerede oppgradert, mens installasjoner virksomhetene drifter selv må oppgraderes av dem som drifter dem.

Hva som skjer teknisk

Metabase er et verktøy for spørringer og visualisering, og det står gjerne med tilgang til databasene virksomheten allerede har. Verktøyet har i tillegg sin egen applikasjonsdatabase, der brukere, økter, API-nøkler og pålogginger til de tilkoblede databasene ligger lagret. Sårbarheten ligger i endepunktet /api/session/reset_password, som er tilgjengelig uten pålogging fordi den som har glemt passordet sitt per definisjon ikke er logget inn. Ifølge sikkerhetsvarselet kan en uautentisert angriper sende egne SQL-setninger inn i applikasjonsdatabasen gjennom dette endepunktet. CVSS-vektoren leverandøren oppgir sier at angrepet skjer over nettet, at det ikke krever rettigheter, og at det ikke krever at noen gjør noe.

Konsekvensen følger av hva applikasjonsdatabasen inneholder. Metabase skriver at angriperen derfra kan skaffe seg administratortilgang, endre oppsettet, hente ut lagrede pålogginger til de tilkoblede databasene, lese alt disse påloggingene når, og eksportere data. Angrepsmønsteret er beskrevet konkret i varselet: et POST-kall mot /api/session/reset_password som svarer med statuskode 400, etterfulgt av et GET-kall mot /api/user/current som svarer med 200. Finnes det mønsteret i applikasjonsloggen eller i loggen foran tjeneren, regner Metabase installasjonen som sannsynlig kompromittert. Leverandøren oppgir ikke hvor mange installasjoner som er rammet.

Hva det betyr for deg som drifter Metabase selv

Det viktigste her er etter vår mening ikke Metabase i seg selv, men hva et analyseverktøy har tilgang til. Verktøyet ditt står gjerne koblet til datalageret, kunderegisteret og økonomidatabasen, og det oppbevarer påloggingene til alle sammen. En angriper med administratortilgang i Metabase har dermed ikke bare tatt ett system. Angriperen har fått nøklene til de databasene Metabase spør mot, og et ferdig grensesnitt for å hente ut innholdet.

Det andre poenget er hvor en slik oppgradering pleier å havne i køen din. Metabase blir ofte satt opp av et analysemiljø og ikke av driftsavdelingen, og faller derfor utenfor den vanlige listen over systemer noen har et navngitt ansvar for å oppdatere. Nettopp den typen system er det som blir stående på en gammel versjon. Siden sårbarheten utnyttes aktivt, er tidsvinduet ditt kort. Er endepunktet for passordgjenoppretting nåbart fra Internett hos deg, hører oppgraderingen hjemme nå, og ikke i neste vedlikeholdsvindu.

Berigo anbefaler

• Oppgrader til den rettede utgaven i den grenen installasjonen står på, altså 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 eller 0.63.5.
• Kan oppgraderingen ikke skje med én gang, steng endepunktet /api/session/reset_password i mellomtiden.
• Er endepunktet nåbart utenfra, let i applikasjonsloggen og inngangsloggen etter et POST-kall mot endepunktet med statuskode 400, fulgt av et GET-kall mot /api/user/current med statuskode 200.
• Trekk tilbake alle aktive økter etter oppgraderingen, gå gjennom API-nøkler og administratorkontoer, og fjern det ingen kjenner igjen.
• Bytt påloggingene til hver database Metabase er koblet til, og gå gjennom loggene i datalageret for spor av uautorisert bruk.