Stellen Sie sich vor, Ihre Entwickler haben ein lokales Sprachmodell auf den eigenen Workstations laufen, weil Sie aus DSGVO-Gruenden keine Code-Schnipsel an US-Cloud-LLMs schicken wollen. Eine sinnvolle, sogar lobenswerte Entscheidung. Was Sie nicht wissen: Genau das Tool, das diese lokale KI ausliefert, hat einen Auto-Updater, der unsignierte Pakete akzeptiert und Pfade aus HTTP-Headern ungeprueft als Dateinamen interpretiert. Eine Stunde im falschen Hotel-WLAN reicht aus, und die Sandbox fuer Ihren KI-Prototyp wird zum Brueckenkopf in Ihre Quellcode-Repositories. Genau dieses Szenario beschreiben die juengst veroeffentlichten Schwachstellen CVE-2026-42248 und CVE-2026-42249 in Ollama — und es ist kein theoretisches Gedankenspiel.

Vom Hype zum Heimcomputer: Wie Ollama in den Mittelstand gelangt ist

Ollama ist eines jener Open-Source-Projekte, deren Erfolg auf Bequemlichkeit basiert: Ein einziger Doppelklick installiert eine Plattform, die Llama-, Qwen-, Phi- oder Mistral-Modelle lokal auf einem Notebook ausfuehrt. Fuer Entwickler, die eine schnelle Testumgebung fuer Retrieval-Augmented-Generation-Prototypen brauchen, ist das ein Geschenk. Fuer Datenschutzbeauftragte, die nervoes werden, wenn Sourcecode in eine US-Cloud fliesst, klingt das nach einer Loesung. Genau diese Mischung aus Komfort und Compliance-Argument hat Ollama in den letzten 18 Monaten in tausende deutsche Mittelstaendler gespuelt — meist ohne dass die zentrale IT je davon gehoert haette.

Was kaum jemand prueft: Hinter dem entspannten ollama run llama3.2 verbirgt sich eine vollwertige Client-Software mit Auto-Updater, lokalem HTTP-Server, Modell-Cache und Persistenz im Benutzerprofil. Anders gesagt: Es ist eine Anwendung, die von aussen Code nachlaedt und ausfuehrt. Jede Anwendung dieser Klasse muss zwei Dinge wasserdicht beherrschen: Verifizieren, was sie nachlaedt, und kontrollieren, wohin sie schreibt. Das Ollama-Update-Modul auf Windows tut nach derzeitigem Stand keines von beiden zuverlaessig.

Die technische Anatomie der Luecke

Am 29. April 2026 hat das polnische CERT (CERT.PL) zwei Schwachstellen in Ollama fuer Windows offengelegt. Die Veroeffentlichung erfolgte ohne verfuegbaren Hersteller-Patch, weil die Maintainer im Rahmen der koordinierten Offenlegung nicht reagiert haben — ein in der Open-Source-Welt unangenehm haeufiges Muster. Beide Luecken zusammen bilden eine vollstaendige Angriffskette, die auf jedem Windows-Rechner mit Ollama-Versionen 0.12.10 bis einschliesslich 0.17.5 funktioniert.

CVE-2026-42248: Wenn die Signaturpruefung "true" zurueckgibt — egal was passiert

Die erste Schwachstelle steckt in der Update-Verifikation. Beim Update-Vorgang laedt Ollama auf Windows das neue Binary herunter und ruft anschliessend eine interne Funktion auf, die pruefen soll, ob das Paket eine gueltige Signatur hat. Diese Funktion ist auf Windows so implementiert, dass sie unabhaengig von der tatsaechlichen Signatur immer erfolgreich zurueckkehrt. Effektiv existiert keine Signaturpruefung. Jedes Binary, das sich als Ollama-Update ausgibt, wird ausgefuehrt — egal ob es vom Hersteller, von einem Forscher oder von einem Angreifer stammt.

Diese Klasse von Bug ist so alt wie Software-Updates selbst. Sie taucht typischerweise auf, wenn Code aus einem prototypischen Zustand in Produktion gerutscht ist, ohne dass der "TODO: implement signature check"-Kommentar je in eine echte Implementierung muendete. Die wahre Brisanz liegt darin, dass die Ollama-Codebasis auf macOS und Linux signaturaehnliche Mechanismen vorsieht — der Windows-Pfad wurde aber separat implementiert und nie nachgezogen. Ein klassischer Cross-Plattform-Suenden-Klassiker.

CVE-2026-42249: Path Traversal aus dem HTTP-Header

Die zweite Schwachstelle ist subtiler und fuer sich allein betrachtet weniger spektakulaer — aber im Verbund mit der ersten Luecke der eigentliche Hebel. Beim Update-Download interpretiert Ollama bestimmte HTTP-Response-Header (insbesondere den Content-Disposition-Header und einen produktspezifischen Update-Filename-Header) und nutzt deren Werte direkt als Dateipfad im lokalen Update-Staging-Verzeichnis. Ein Angreifer, der diese Header kontrollieren kann — etwa durch ein boesartig konfiguriertes Update-Repository oder einen Man-in-the-Middle-Angriff — kann mit klassischen Path-Traversal-Sequenzen wie ..\\..\\..\\Users\\Public\\Startup\\boese.exe den Schreibvorgang aus dem Staging-Ordner herauslenken.

Das interessanteste Ziel auf einem Windows-System ist hierbei der Startup-Ordner des aktuellen Benutzers (%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup). Alles, was dort liegt, startet automatisch beim naechsten Login — ohne weitere Privilegien-Eskalation, ohne UAC-Prompt, ohne sichtbare Spur in den klassischen Persistenz-Erkennungen, die viele EDR-Loesungen auf Registry-Run-Keys konzentrieren.

Die Kettenwirkung

Im Verbund ergeben die beiden Luecken einen besonders eleganten Angriffsweg:

  1. Der Angreifer positioniert sich zwischen Ollama-Client und der Update-Server-Kommunikation. Das gelingt klassisch ueber DNS-Hijacking, manipulierte WLAN-Hotspots, einen kompromittierten ISP-Router, ein boesartiges VPN-Profil oder die Uebernahme einer kompromittierten Update-Mirror-Infrastruktur.
  2. Beim naechsten automatischen Update-Check liefert er statt des legitimen Pakets ein eigenes Binary aus, ergaenzt um manipulierte HTTP-Header.
  3. CVE-2026-42249 lenkt den Schreibvorgang in den Startup-Ordner. Die Datei landet dort als legitim aussehende EXE.
  4. CVE-2026-42248 sorgt dafuer, dass Ollama keinen Alarm schlaegt — die "Signatur" wird ja angeblich erfolgreich verifiziert.
  5. Beim naechsten Login startet das Binary mit den Rechten des angemeldeten Benutzers — typischerweise ein Entwicklerprofil mit Zugriff auf Quellcode-Repositories, lokale Container-Registries, gespeicherte Cloud-Tokens und SSH-Schluessel.

User Story: Wie es einem fiktiven Mittelstaendler wirklich passieren wuerde

Damit die Tragweite konkret wird, hier ein realistisches Szenario aus der Beratungspraxis. Die Namen sind erfunden, die Mechanik ist es nicht.

Die Maier & Sons GmbH, ein Familienunternehmen aus dem schwaebischen Raum mit 240 Mitarbeitenden, baut spezialisierte Industrie-Sensoren. Das vierkoepfige Entwicklungsteam um IT-Leiter Stefan K. arbeitet an einer Firmware-Erkennungs-KI, die Produktionsfehler in Echtzeit klassifizieren soll. Anfang 2026 wird auf einer Branchenkonferenz Ollama als datenschutzfreundliche Lokal-Alternative zu OpenAI vorgestellt. Stefan K. installiert es auf seinem Notebook — und auch auf einem ausgemusterten Workstation-PC, der unter dem Schreibtisch als "kleiner KI-Server" dienen soll. Innerhalb von zwei Wochen ist Ollama auf vier weiteren Entwickler-Notebooks. Eine Erfassung in der zentralen Software-Inventarisierung passiert nicht, weil Ollama als Benutzerinstallation laeuft und keine Admin-Rechte braucht.

Anfang Mai 2026 nimmt Stefan K. an einer dreitaegigen Branchenkonferenz in Frankfurt teil. Im Hotel-WLAN bezieht sein Notebook automatisch ein Ollama-Update — wie es das jedes Mal bei Internet-Zugang tut. Was Stefan nicht weiss: Das Hotel-WLAN ist seit Wochen ueber ein kompromittiertes Edge-Geraet der Vorhalte-Infrastruktur unter Kontrolle einer organisierten Ransomware-Gruppe, die das Netz als initialen Brueckenkopf gegen ausreisende Geschaeftsreisende nutzt. Die Gruppe hat einen DNS-Spoofing-Filter eingebaut, der Update-Anfragen fuer eine Liste populaerer Entwickler-Tools — Ollama steht weit oben — auf einen eigenen Server umleitet. Dort wartet ein praepariertes Binary inklusive boesartig gesetztem Filename-Header.

Innerhalb von 90 Sekunden ist die Datei OllamaUpdate.exe in Stefans Startup-Ordner geschrieben. Der naechste Reboot — am Abend, nachdem Stefan das Hotel verlassen hat — startet sie. Das Binary verbindet sich zu einem unscheinbaren Cloudflare-Workers-Endpoint, der Tarnung als statische Website ausreichend gut beherrscht, dass die Hotel-WLAN-Telemetrie unentdeckt bleibt. Erst zwei Wochen spaeter, zurueck im Maier-Netzwerk, beginnt die zweite Phase: Inventarisierung der Workstation, Auslesen von SSH-Konfigurationen, lateral movement ueber bereits gespeicherte Anmeldeinformationen.

Der Vorfall faellt erst auf, als das Sicherheitsteam — auf Hinweis eines aufmerksamen Praktikanten — feststellt, dass von Stefans Account auf einem GitLab-Repo Code geklont wurde, der zu diesem Zeitpunkt eigentlich auf einem ausgeschalteten Notebook lag. Forensische Analysen rekonstruieren spaeter den Pfad: vom Hotel-WLAN ueber den Startup-Ordner ueber das Entwickler-Notebook bis hin zu fuenf Repositories mit Sensor-Firmware, einem Backup-Token mit Schreibzugriff auf den Cloud-Storage und Zugangsdaten zu einem Vorab-Server der QS-Abteilung. Geschaetzter Schaden: niedrige siebenstellige Summe, plus monatelange Aufraeumarbeiten.

Das Bemerkenswerte an der Geschichte: Maier & Sons hatte ein durchaus solides Sicherheitsniveau. ISO 27001 war in Vorbereitung. EDR lief auf allen Endpoints. Die Ollama-Installation war es, die unter dem Radar fuhr — exakt weil sie als sinnvolle Schatten-IT gestartet hatte und nie eine Sicherheitsbewertung durchlaufen hatte.

Die breitere Einordnung: KI-Tools sind die neue Lieferkette

Die Ollama-Luecken sind ein Symptom eines groesseren Phaenomens, das wir in der Informationssicherheits-Beratung seit etwa 18 Monaten in fast jedem Audit sehen: Open-Source-KI-Tooling hat den Mittelstand erreicht, bevor die Sicherheits- und Compliance-Funktionen ueberhaupt verstanden haben, dass dieses Tooling existiert. Anders als bei klassischen Enterprise-Stacks gibt es bei Tools wie Ollama, LocalAI, Text-Generation-WebUI, ComfyUI oder LM Studio:

  • Keine konsolidierte Sicherheitsorganisation: Maintainer sind haeufig wenige Volunteers, oft mit Tagesjob in einem ganz anderen Bereich. Koordinierte Disclosure-Prozesse existieren mal mehr, mal weniger.
  • Schnelle Release-Zyklen ohne formelle Tests: Eine woechentliche Hauptversion ist die Regel, was die Wahrscheinlichkeit von Regressionen massiv erhoeht.
  • Auto-Updater, die als Convenience-Feature konzipiert sind, nicht als Sicherheitsmechanismus. Code-Signaturen, Reproducible Builds und Manifeste mit Hash-Verifikation sind die Ausnahme.
  • Eine Anwender-Community, die das Tool fuer Bequemlichkeit und Geschwindigkeit nutzt und Sicherheits-Haertung selten als ihre Aufgabe begreift.

Dazu kommt eine Eigenheit von KI-Tools, die sie fuer Angreifer besonders attraktiv macht: Sie laufen typischerweise auf den Maschinen genau jener Mitarbeitenden, die Zugriff auf das Wertvollste haben — Quellcode, Trainingsdaten, Geschaeftsdokumente, Modellgewichte. Ein kompromittiertes Backup-System ist ein Problem. Ein kompromittiertes Entwickler-Notebook mit aktiven Cloud-Tokens, lokalen Repos, Container-Credentials und einer kreuzweisen VPN-Verbindung ist ein Albtraum.

Die Parallele zu klassischen Lieferketten-Angriffen wie SolarWinds (2020) oder dem 3CX-Vorfall (2023) ist kein Zufall. KI-Tooling ist die naechste Generation der Software-Lieferkette — mit einem entscheidenden Unterschied: Waehrend Enterprise-Hersteller nach den Vorfaellen begonnen haben, in SBOMs (Software Bills of Materials), signierten Builds und reproduzierbaren Pipelines zu investieren, haengt die Open-Source-KI-Welt an dieser Stelle zwei bis drei Jahre hinterher.

Handlungsempfehlungen fuer IT-Leiter und Sicherheitsverantwortliche

Wer im deutschen Mittelstand verhindern will, dass die Ollama-Geschichte zur eigenen wird, sollte sechs Hebel jetzt aktivieren — und zwar unabhaengig davon, ob Ollama konkret im Einsatz ist. Die Logik uebertraegt sich auf jede vergleichbare KI-Anwendung:

1. Inventarisierung — auch der "kleinen" Tools

Eine ehrliche Bestandsaufnahme aller lokal installierten KI-Tools ist ueberfaellig. Das umfasst CLI-Werkzeuge wie Ollama, GUIs wie LM Studio, Browser-Erweiterungen mit lokaler LLM-Anbindung, VS-Code-Plugins, n8n-Workflows mit lokalen Modellen und JupyterLab-Setups. Inventarisieren ueber Endpoint-Management-Loesungen wie Microsoft Intune, ManageEngine oder eine massgeschneiderte SCCM-Abfrage. Wer eine strukturierte KI-Strategie aufsetzt, verankert das Inventar als laufenden Prozess, nicht als einmalige Aktion.

2. Allow-Listing statt Block-Listing

Die Versuchung ist gross, einfach "Ollama verbieten" zu rufen. Das loest das Grundproblem nicht, weil morgen das naechste Tool auftaucht. Der robustere Ansatz: Eine kuratierte Liste freigegebener KI-Tools, mit klaren Kriterien fuer die Aufnahme (Reife, Maintainer-Track-Record, Disclosure-Reaktionsfaehigkeit, Verfuegbarkeit signierter Builds). Tools ausserhalb dieser Liste werden via Application Control (AppLocker, Windows Defender Application Control, Jamf) blockiert.

3. Auto-Updater unter Kontrolle

Auto-Updater sind die Achillesferse vieler Anwendungen. Best Practice: Update-Server-Kommunikation ueber HTTPS-Pinning erzwingen, soweit das Tool das unterstuetzt. Wenn nicht, Update-Endpoints ueber Egress-Proxies leiten und protokollieren. Im Idealfall: Updates aus internem Repository spiegeln und Endpoints daraus bedienen — das ist der Goldstandard, den grosse Unternehmen seit Jahren mit JFrog Artifactory, Sonatype Nexus oder JetBrains Hub leben.

4. Netzwerksegmentierung fuer Entwickler-Workstations

Entwickler-Maschinen sollten nicht in dasselbe Netzwerksegment wie Office-Clients gehoeren. Eine Segmentierung mit explizit zugelassenen Routen (zum Quellcode-Server, zur CI/CD, zur internen Container-Registry) reduziert die laterale Reichweite eines kompromittierten Endgeraets dramatisch. In der Praxis ist das eine der wirkungsvollsten Massnahmen mit dem besten Aufwand-Nutzen-Verhaeltnis.

5. Persistenz-Pfade aktiv ueberwachen

EDR-Loesungen unterscheiden sich enorm darin, wie gut sie Persistenz-Mechanismen abdecken. Der Windows-Startup-Ordner, geplante Aufgaben, WMI-Subskriptionen und neuerdings auch die App-Execution-Aliases der Universal Windows Platform sollten alle als Hochrisiko-Pfade konfiguriert sein. Wer Microsoft Defender for Endpoint einsetzt, sollte die "Suspicious Persistence"-Regelsaetze auf "Block" und nicht nur "Audit" gestellt haben.

6. Reise-Profile und WLAN-Hygiene

Die Ollama-Geschichte haengt am Hotel-WLAN. Eine Reise-Policy, die in fremden Netzen einen Always-On-VPN-Tunnel zur Unternehmens-Infrastruktur erzwingt, neutralisiert einen grossen Teil dieser Angriffsvektoren. Moderne SASE-Loesungen (Zscaler, Cloudflare One, Netskope) bringen das mit; auch ein klassisches OpenVPN/Wireguard-Setup leistet das, wenn es als Default-Route konfiguriert ist.

Was bedeutet das im NIS2- und EU-AI-Act-Kontext?

Beide Regulierungen — die deutsche NIS2-Umsetzung seit Dezember 2025 und der EU AI Act mit den naechsten Meilensteinen im August 2026 — greifen genau die Themen auf, die der Ollama-Vorfall illustriert. NIS2 verpflichtet betroffene Unternehmen explizit zu Lieferketten-Sicherheit (Artikel 21 Abs. 2 Buchstabe d) — und Software-Komponenten Dritter, einschliesslich Open-Source-Bibliotheken, fallen darunter. Der EU AI Act fordert fuer Hochrisiko-KI-Systeme dokumentierte Lieferketten und Risiko-Management-Prozesse, die auch eingesetzte Modelle und Tooling umfassen.

Wer also die Ollama-Luecken ignoriert, riskiert nicht nur einen Vorfall, sondern auch einen handfesten Compliance-Befund. BSI-Auditoren werden ab dem zweiten Halbjahr 2026 mit den ersten sektoralen Leitlinien konkrete Erwartungen an die Sichtbarkeit von KI-Werkzeug-Inventaren formulieren — das ist erkennbar in der bisherigen Kommunikation des Amts.

Ausblick: Was als Naechstes kommt

Die aktuelle Welle ist nicht auf Ollama beschraenkt. Wir erwarten in den naechsten zwoelf Monaten weitere Disclosure-Wellen fuer vergleichbare KI-Tools, weil:

  • Sicherheitsforscher gerade erst beginnen, sich auf das KI-Werkzeug-Oekosystem zu fokussieren — die Aufmerksamkeit der Forschungs-Community hat etwa zwei Jahre Verzoegerung gegenueber dem Adoption-Hype.
  • Viele dieser Tools eine aehnliche architektonische DNA teilen (lokaler HTTP-Server, Auto-Updater, lokaler Modell-Cache mit Schreibrechten), was die Wahrscheinlichkeit aehnlicher Klassen von Bugs erhoeht.
  • Bedrohungsakteure die wirtschaftliche Attraktivitaet dieser Tools verstanden haben: Ein erfolgreicher Angriff liefert nicht nur Endgeraete, sondern Trainingsdaten, Prompts, Modellgewichte — Werte, die im Untergrund handelbar werden.

Mittelfristig wird der Markt sich segmentieren. Erste kommerzielle Anbieter — etwa Llama Stack von Meta, NVIDIA NIM oder Anthropic for Enterprise — bringen Enterprise-Haertung in den lokalen LLM-Bereich. Wer im deutschen Mittelstand auf KI-Souveraenitaet setzt, sollte diese Optionen ernsthaft pruefen, bevor er auf die naechste Open-Source-Wundertuete aufspringt.

Wie pleXtec unterstuetzt

Wir begleiten unsere Kunden bei genau dieser Schnittstelle aus KI-Adoption und Sicherheitsarchitektur. Konkret bieten wir:

  • KI-Tool-Inventar und Risikobewertung — eine 5-Tage-Erhebung, die Schatten-KI sichtbar macht und kategorisiert.
  • Sichere KI-Sandbox-Architekturen — Konzepte fuer getrennte, gehaertete Umgebungen, in denen Entwickler experimentieren koennen, ohne Produktivnetzwerke zu gefaehrden.
  • Lieferketten-Haertung — Etablierung interner Repositories, signierter Build-Pipelines und reproduzierbarer Update-Mechanismen.
  • NIS2-konforme KI-Governance — Anschlussfaehigkeit der KI-Strategie an die regulatorischen Anforderungen, ohne Innovation zu ersticken.

Die Ollama-Geschichte ist eine Warnung, kein Schicksalsschlag. Wer in den kommenden Wochen sein KI-Tooling auditiert und die sechs oben genannten Hebel aktiviert, schliesst nicht nur das aktuelle Risiko, sondern baut die Resilienz, die ihn beim naechsten vergleichbaren Vorfall — und der kommt — entspannt schlafen laesst. Lassen Sie uns gemeinsam darueber sprechen, wie das in Ihrer konkreten Umgebung aussieht: Kontaktieren Sie uns ueber das Kontaktformular oder vereinbaren Sie ein erstes, unverbindliches Gespraech.

Fazit in einem Satz

Wenn Sie nicht wissen, welche KI-Werkzeuge gerade auf den Notebooks Ihrer Entwickler aktualisieren, weiss es jemand anderes — und das ist die schlechtere Variante.