Ollama is snel lokaal te installeren, maar een gedeelde API is daarmee niet automatisch veilig. Zodra poort 11434 buiten localhost bereikbaar wordt, zijn authenticatie, netwerksegmentatie, logging en patchbeheer nodig. CVE-2026-7482 liet zien dat een ongeauthenticeerde modeldienst gevoelige geheugeninhoud kan blootleggen.
Lokale AI wordt vaak gekocht om gegevens binnen de organisatie te houden. De installatie gaat vervolgens verrassend snel: workstation uitpakken, model downloaden, Ollama starten en een webinterface koppelen. Een pilot kan binnen een middag werken.
Precies die eenvoud vormt het risico. Ollama’s lokale API vereist bij toegang via localhost geen authenticatie. Dat is logisch zolang alleen software op dezelfde computer de dienst gebruikt. Zodra de API bereikbaar wordt gemaakt voor collega’s, containers of andere systemen, is er niet automatisch een wachtwoord- of tokenlaag die toegang beperkt.
Ollama heeft inmiddels wel authenticatie voor zijn clouddiensten en de API op ollama.com. Dat moet niet worden verward met de lokale API op poort 11434. Daar blijft netwerkontwerp de verantwoordelijkheid van de organisatie.
Van localhost naar gedeelde dienst
Standaard is de lokale API beschikbaar op `127.0.0.1`. Daarmee is zij alleen vanaf de eigen machine bereikbaar. In de praktijk willen teams al snel meer: een webinterface op een andere server, een interne applicatie of meerdere medewerkers die hetzelfde model gebruiken. De host wordt dan op het netwerk beschikbaar gemaakt.
Vanaf dat moment is Ollama geen desktopapplicatie meer, maar een interne dienst. Er hoort een toegangslaag voor, plus netwerksegmentatie, logging en eigenaarschap. Zonder die voorzieningen kan iedere gebruiker of toepassing die de poort bereikt modelinformatie opvragen en API-functies aanroepen.
Het probleem is niet dat een ontwikkelaar de documentatie verkeerd leest. Het probleem is dat de overgang van lokale tool naar gedeelde infrastructuur technisch klein lijkt, terwijl de beheerlast sterk verandert.
CVE-2026-7482 maakte de gevolgen concreet
In 2026 werd CVE-2026-7482 gepubliceerd voor Ollama-versies vóór 0.17.1. Volgens de NVD ging het om een out-of-bounds read in de verwerking van GGUF-modelbestanden. Via de niet-geauthenticeerde `/api/create`- en `/api/push`-functies konden geheugeninhouden worden blootgelegd. Daarbij konden onder meer omgevingsvariabelen, API-sleutels, systeemprompts en gegevens van gelijktijdige gesprekken in beeld komen.
De kwetsbaarheid werd in versie 0.17.1 verholpen. De belangrijkste les is breder dan één CVE. Een instantie die alleen op localhost luistert, heeft een veel kleiner aanvalsoppervlak. Een instantie die intern of publiek bereikbaar is zonder aanvullende toegangscontrole, maakt een fout in de modelverwerking direct op afstand bruikbaar.
Controleer daarom op de publicatiedag opnieuw de actuele versie en nieuwe beveiligingsadviezen. Een securityartikel met een verouderde versieverwijzing kan zelf een risico worden.
Versiecontrole op 20 juli 2026: GitHub vermeldde Ollama v0.32.0 van 11 juli 2026 als actuele release. Versie 0.17.1 is uitsluitend de eerste versie waarin CVE-2026-7482 was verholpen en is dus geen actueel patchdoel. De NVD bevestigt dat alle versies vóór 0.17.1 kwetsbaar waren en dat /api/create en /api/push in de upstreamdistributie geen authenticatie hadden.
Bronnen
Datasoevereiniteit is geen fysieke locatie
Data binnen het eigen gebouw houden is niet hetzelfde als controle hebben. Een onbeheerde AI-machine kan gevoelige prompts opslaan, modellen uit onbekende registers ophalen of sleutels in omgevingsvariabelen gebruiken. Als niemand logt wie toegang had, kan een organisatie achteraf weinig reconstrueren.
De Cyberbeveiligingswet legt de nadruk op risicomanagement, kwetsbaarhedenbeheer, toegangsbeheer, veilige verwerving en het toetsen van maatregelen. Voor lokale AI betekent dit dat de organisatie niet alleen de hardware moet registreren, maar ook de dienst, softwareversie, modellen en netwerktoegang.
De meldplicht begint bovendien pas wanneer een incident wordt waargenomen. Een schaduwinstallatie zonder logging of monitoring kan lang lekken zonder dat iemand iets ziet. Dat is geen bewijs dat een clouddienst altijd veiliger is. Het is bewijs dat lokale infrastructuur ook als infrastructuur moet worden beheerd.
De webinterface vormt een tweede keten
Veel organisaties gebruiken Ollama niet rechtstreeks, maar plaatsen er een webinterface, documentzoekfunctie of automatiseringsplatform voor. Dat maakt de oplossing bruikbaarder, maar voegt ook accounts, sessies, uploads, plug-ins en eigen kwetsbaarheden toe. Een afgeschermde modelserver is niet voldoende wanneer de weblaag publiek bereikbaar is met zwakke wachtwoorden of te ruime beheerdersrechten.
Breng daarom per component vast wie onderhoud uitvoert, waar logbestanden en uploads worden bewaard en hoe updates worden getest. Controleer ook of de interface prompts of documenten naar externe diensten stuurt, bijvoorbeeld voor telemetry, embeddings of websearch. ‘Het model draait lokaal’ is geen volledige beschrijving van de gegevensstroom. Datasoevereiniteit ontstaat pas wanneer de hele route van browser tot model en opslag is vastgelegd.
Maak de gegevensroute ook zichtbaar voor gebruikers. Zij moeten weten welke documenten mogen worden geüpload, hoe lang gesprekken worden bewaard en bij wie zij een fout kunnen melden. Zonder duidelijke gebruiksregels verplaatst schaduw-IT zich simpelweg van een publieke chatbot naar een interne dienst die formeel lokaal is, maar praktisch even weinig wordt beheerst.
Een minimale veilige inrichting
Een organisatie hoeft niet direct een complex platform te bouwen. Een kleine interne implementatie kan met een beperkt aantal maatregelen veel veiliger worden:
- Laat Ollama alleen op localhost luisteren wanneer toegang vanaf andere systemen niet nodig is. 2. Is gedeelde toegang wel nodig, plaats dan een authenticerende reverse proxy of VPN voor de dienst en beperk netwerkbereik met firewallregels. 3. Registreer de machine en de dienst, wijs een eigenaar aan en leg de updateprocedure vast. 4. Log verbindingen en beheer wie modellen mag toevoegen of publiceren. 5. Controleer de actuele Ollama-versie, drivers, containerimages en webinterface als één keten. 6. Scan intern op poort 11434 om onbekende installaties te vinden.
Een reverse proxy alleen is niet genoeg wanneer de onderliggende poort nog rechtstreeks bereikbaar blijft. Test dus vanaf een ander netwerksegment of de blokkade werkelijk werkt.
De hardware is het eenvoudigste onderdeel
Voor lokale AI wordt veel tijd besteed aan processor, GPU en geheugen. Dat is begrijpelijk: zonder passende hardware is de toepassing traag. Maar de beveiliging wordt niet bepaald door de duurste component. Zij wordt bepaald door de minst zichtbare verbinding.
Een organisatie die lokaal draait vanwege privacy of intellectueel eigendom moet daarom budget reserveren voor inrichting en beheer. Zonder eigenaar, authenticatie, patchcyclus en logging is de data niet soeverein. Ze staat alleen dichterbij.
De installatie van Ollama duurt minuten. Van die installatie een betrouwbare bedrijfsdienst maken kost meer tijd. Dat verschil hoort vóór de aanschaf in de businesscase, niet na het eerste beveiligingsincident.
Meer lezen