Ollama CVE-2026-7482: GGUF-fil lekker minne fra 300 000 servere, fiks i v0.17.1
torsdag 7. mai · KI-generert · Kilde: CVE Feed
Oppdater Ollama til 0.17.1 nå hvis serveren din lytter på 0.0.0.0.
CVE-2026-7482 ble publisert 4. mai med CVSS 3.1-score 9.1 og CVSS 4.0 «High». Sårbarheten ligger i GGUF-modellasteren: /api/create aksepterer en angriperlevert GGUF-fil der deklarert tensor-offset og -størrelse går utover filens faktiske lengde. Under kvantisering i fs/ggml/gguf.go og server/quantization.go (WriteTo()) leser serveren forbi heap-bufferen.
Lekkasjen kan inneholde miljøvariabler, API-nøkler, systemprompter og samtaledata fra andre brukere som kjører samtidig. Datafangsten skjer ved at angriperen laster opp den resulterende modellartefakten via /api/push til et eget register. Verken /api/create eller /api/push har autentisering i upstream-distribusjonen.
«Standardoppsettet binder til 127.0.0.1, men dokumentert OLLAMA_HOST=0.0.0.0 er utbredt i praksis, med stor offentlig eksponering observert.» — CVE-beskrivelse, kilde abd028dc-c042
Rundt 300 000 Ollama-instanser er eksponert mot åpent internett ifølge rapporten. For deg som kjører lokal LLM-server hjemme eller på en VPS er hovedrisikoen at du selv har satt OLLAMA_HOST=0.0.0.0 for å nå serveren utenfra. Det betyr at alle som vet IP-adressen kan trigge lasteren.
Hva bør du gjøre?
- Oppdater til v0.17.1 eller nyere umiddelbart:
curl -fsSL https://ollama.com/install.sh | sh - Sjekk at serveren binder til 127.0.0.1, og bruk SSH-tunnel eller WireGuard for fjerntilgang i stedet for å eksponere porten.
- Sett en reverse proxy (Caddy, nginx) foran Ollama med autentisering hvis du må eksponere endepunktene.
- Roter API-nøkler og hemmeligheter som har vært tilgjengelige for prosessen siden installasjonsdato. Du vet ikke om noen har lest dem ennå.
Bakgrunn
Pull request [#14406](https://github.com/ollama/ollama/pull/14406) inneholder fiksen, og v0.17.1 ble merket samme dag CVE-en ble publisert. CWE-125 (out-of-bounds read) er klassen sårbarheten faller under. Ollama-prosjektet har historisk holdt /api/create og /api/push autentiseringsfri fordi standardbindingen er lokal. Den antagelsen brister når brukerne flytter serveren til en VPS uten brannmur.