Stand: 20. Mai 2026. Quellen: GitHub Releases, NVD, CERT Polska, Help Net Security, Mondoo, Hugging Face, offizielle Changelogs.
🚀 Releases
Ollama v0.23.4 & v0.24.0 — 13./14. Mai 2026
v0.23.4 (13. Mai): Kleines Pflaster-Release –
ollama launch opencode unterstützt jetzt Eingaben mit Bildern (Vision-Modelle),
außerdem wurde die Formatierung von Claude-Tool-Ergebnissen bei lokalen Bildpfaden korrigiert.
v0.24.0 (14. Mai): Codex-App-Integration –
OpenAIs Codex-Desktop-App lässt sich jetzt mit beliebigen Ollama-Modellen verwenden.
Codex kann lokale Server und Sites in seinem eingebauten Browser öffnen; Seiten lassen sich direkt annotieren,
Änderungen werden innerhalb der App reviewt. Zusätzlich wurde der MLX-Sampler für Apple Silicon
grundlegend überarbeitet, was die Generierungsqualität auf M-Chips verbessern soll.
⚠️ Ollama v0.30.0-rc20 — Pre-Release (Mai 2026)
Im Hintergrund rollt ein Breaking-Architecture-Change heran:
Die v0.30-Reihe (aktuell rc20) koppelt Ollama direkt an llama.cpp und entfernt
die bisherige eigene GGML-Schicht vollständig. Modelle müssen im GGUF-Format vorliegen;
ältere Formate werden nicht mehr unterstützt. MLX bleibt für Apple-Silicon-Beschleunigung erhalten.
Das Team bittet Nutzer um Feedback zu Performance-Veränderungen und Abstürzen,
bevor das Release als stabil markiert wird.
llama.cpp b9240 — 20. Mai 2026
Das heutige Build b9240 enthält hauptsächlich einen Bugfix:
--help für --verbosity wurde korrigiert.
llama.cpp erscheint mehrmals täglich in neuen Builds; als aktuelle stabile Binaries
für Windows stehen Varianten mit CUDA 12.4-, CUDA 13.1-, Vulkan-, HIP- und SYCL-Support bereit –
kein Kompilieren aus dem Quellcode mehr nötig.
Gestern (b9239) wurde ein Verbosity-Fix für den --fit-Parameter nachgeliefert.
Open WebUI v0.9.5 — 10. Mai 2026
Das bisher neueste Stable-Release bringt mehrere relevante Neuerungen:
- Responses API via Ollama-Proxy: Clients können
/v1/responsesjetzt direkt mit Ollama-gehosteten Modellen nutzen. - Calendar Workspace: Vollständiger Kalender mit wiederkehrenden Ereignissen, Erinnerungen per Toast/Browser-Notification und Webhook-Unterstützung.
- Azure OpenAI Responses: Der neuere
/openai/v1-Endpunkt wird jetzt korrekt unterstützt. - Datei-Wiederverwendung: Bereits hochgeladene Dateien können direkt aus dem Chat-Input-Menü erneut angehängt werden.
- psycopg v3: Der async DB-Driver wurde von asyncpg auf psycopg3 migriert – transparente Änderung für die meisten Deployments, custom Connection-Strings könnten Anpassungen benötigen.
- Brotli-Update: Behebt CVE-2025-6176.
Das Open-WebUI-Desktop-Paket ist mit v0.0.20 (6. Mai) ebenfalls aktualisiert:
Ein Blank-Screen-Bug auf Linux wurde durch SwiftShader-Software-Rendering behoben.
ARM64-Binaries (Linux .deb, AppImage; Windows NSIS) sind seit v0.0.18 verfügbar –
damit läuft Open WebUI nativ auf Raspberry Pi, NVIDIA DGX Spark und Snapdragon-Laptops.
🆕 Open-Weight-Modelle
Kimi K2.6 (Moonshot AI) — 20. April 2026
Kimi K2.6 ist ein 1-Billion-Parameter-MoE-Modell mit 32 Mrd. aktiven Parametern pro Inferenz-Pass,
einem Kontextfenster von 256.000 Tokens und nativem Support für Text-, Bild- und Video-Input.
Die Architektur ist identisch mit K2.5 (61 Layer, 384 Experten, 8 geroutet + 1 geteilt, MLA-Attention),
der Unterschied liegt im Post-Training: mehr Training-Compute für Long-Horizon-Stabilität,
Instruction-Following und Agent-Swarm-Koordination (bis zu 300 parallele Sub-Agenten, 4.000 koordinierte Schritte).
Die Halluzinationsrate sank laut Artificial Analysis von 65 % (K2.5) auf 39 % (K2.6).
Auf dem AA Intelligence Index belegt K2.6 Platz 4 unter allen 346 Modellen und Platz 1 unter Open-Weight-Releases.
Auf SWE-Bench Pro übertrifft K2.6 GPT-5.4 um 0,9 Punkte.
Lokal ausführbar? Die INT4-Weights (QAT-trainiert, nicht nachträglich quantisiert)
liegen bei ca. 594 GB auf Hugging Face. Für Home-Lab-Hardware zu groß;
empfohlen wird vLLM oder SGLang mit Tensor Parallelism auf Server-Hardware.
Ollama, OpenRouter, Cloudflare Workers AI, Vercel und andere Provider haben K2.6
am Release-Tag live geschaltet.
Lizenz: Modified MIT – commercial use erlaubt; Branding-Pflicht („Kimi K2“ im UI) erst ab 100 Mio. MAU oder 20 Mio. USD Monatsumsatz.
Qwen 3.6 (Alibaba)
Zwei Varianten:
- Qwen3.6-27B (dense): 77,2 % SWE-Bench, der bisher stärkste dichte Coding-Modell in dieser Größenklasse. Benötigt ca. 22 GB VRAM. Verfügbar auf Ollama:
ollama pull qwen3.6:27b. - Qwen3.6-35B-A3B (MoE, 3B aktiv): Deutlich VRAM-schonender. Von llama.cpp und vLLM/SGLang unterstützt. Apache 2.0 Lizenz.
Hinweis: Im upstream llama.cpp wurde ein Tensor-Parallelism-Bug bei Qwen3.6-35B-A3B mit drei oder mehr GPUs gemeldet – der Output entartet zu einem Slash-Stream. Mit zwei GPUs tritt das Problem nicht auf.
GLM-5 / GLM-5.1 (Zhipu AI / Tsinghua)
GLM-5.1 zählt laut Community-Benchmarks zu den stärksten Open-Weight-Modellen
für strukturierte Code-Generierung auf SWE-Bench Pro.
Das Modell ist im Ollama-Katalog verfügbar.
ik_llama.cpp (populärer Performance-Fork) unterstützt GLM-5 bereits nativ.
🔴 Sicherheit
CVE-2026-7482 „Bleeding Llama“ — Alle Plattformen, behoben in Ollama ≥ 0.17.1
CVSS 9.1 (kritisch) · Alle Plattformen · Behoben in Ollama 0.17.1 (24. Februar 2026)
Ein Heap-Out-of-Bounds-Read im GGUF-Modell-Loader (WriteTo() in fs/ggml/gguf.go)
erlaubt es einem nicht authentifizierten Angreifer, den gesamten Prozess-Heap des Ollama-Servers
auszulesen und zu exfiltrieren – mit nur drei API-Calls über /api/create und /api/push.
Im Heap können API-Keys, System-Prompts, Nutzer-Gesprächsdaten und Umgebungsvariablen enthalten sein.
Entdeckt von Dor Attias (Cyera Research), CVE-Zuweisung am 28. April 2026 – rund zwei Monate nach dem Patch.
Ca. 300.000 Ollama-Server sind laut Netzwerk-Scans auf 0.0.0.0:11434 ohne Authentifizierung erreichbar.
Maßnahme: Upgrade auf Ollama ≥ 0.17.1. Ollama nie auf 0.0.0.0 binden ohne Reverse-Proxy mit Authentifizierung.
CVE-2026-42248 & CVE-2026-42249 — Windows only, Ollama 0.12.10–0.23.2 (Stand heute ungepacht)
CVSS je 7.7 (hoch) · Nur Windows · Betroffen: Ollama für Windows 0.12.10–0.23.2 (bestätigt)
Zwei verkettbare Schwachstellen im Windows-Auto-Updater, entdeckt von Striga / Bartłomiej Dmitruk,
koordiniert durch CERT Polska, veröffentlicht am 29. April 2026:
-
CVE-2026-42248 (CWE-494, Missing Signature Verification):
DieverifyDownload()-Funktion im Windows-Build gibt bedingungslos Erfolg zurück –
jeder heruntergeladene Installer wird ohne Signaturprüfung ausgeführt.
Auf macOS wird diese Prüfung korrekt durchgeführt. -
CVE-2026-42249 (CWE-22, Path Traversal):
Der Updater baut den lokalen Staging-Pfad direkt aus HTTP-Response-Headern (ETag)
ohne Bereinigung zusammen. Ein Angreifer kann mit../-Sequenzen
beliebige Executables in den Windows-Startup-Ordner schreiben.
Kombiniert mit CVE-2026-– ohne jede Benutzerinteraktion.
Status: Der Fix wurde am 11. Mai 2026 in den main-Branch gemergt, ist aber
in keinem getaggten Release enthalten. Das zuletzt erschienene v0.23.4 (14. Mai) enthält den Patch nicht.
Windows-Nutzer ab v0.12.10 sind bis zum nächsten Release weiterhin exponiert.
Sofortmaßnahmen:
- Auto-Download-Updates in den Ollama-Einstellungen deaktivieren (kürzt den angreifbaren Codepfad ab).
- Vorhandene Ollama-Verknüpfung aus
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startupentfernen. - Sobald ein Tagged Release erscheint, das explizit CVE-2026-42248/-: sofort updaten.
- Linux und macOS sind von diesen beiden CVEs nicht betroffen.
🔀 Ökosystem
llama.cpp: Windows-Prebuilt-Binaries deutlich nutzerfreundlicher
Seit Build b9196 (Mitte Mai) stehen auf der GitHub-Releases-Seite vollständig fertige Windows-Pakete bereit:
CUDA 12.4, CUDA 13.1, Vulkan, HIP (ROCm) und SYCL – kein Eigenkompilat mehr nötig.
NVIDIA-Nutzer greifen zum CUDA-Build; AMD-Nutzer probieren zuerst Vulkan, dann HIP.
Für Intel-Arc-GPUs ist SYCL oder Vulkan die erste Wahl.
llama.cpp: DeepSeek V4 – WIP, noch nicht im Upstream
Ein umfangreicher Pull Request für DeepSeek V4 in llama.cpp (natives FP4/FP8, GGUF-Conversion, CUDA-Optimierungen)
ist in Entwicklung, aber noch nicht in den Upstream-Branch gemergt.
Community-Forks von Antirez und anderen ermöglichen erste Tests; für Produktiveinsatz noch zu früh.
Alternativ bietet sich Qwen3.6-27B als gut unterstützte lokale Alternative an.
llama.cpp: Neue Modellunterstützung (KW 19)
In der Woche vom 4.–11. Mai wurden laut Weekly-GitHub-Report unter anderem folgende Modelle integriert:
IBM Granite 4.0 1B Speech (Conformer-Encoder + QFormer-Projektor) und Sarashina2.2 Vision 3B
(neue Projektor-Typen). Qwen3.6 (Text & Vision) wird ebenfalls explizit unterstützt.
lemonade-sdk/llamacpp-rocm: b1271 (18. Mai)
Frische ROCm-7.14-Builds für Windows und Ubuntu mit GPU-Targets gfx1151, gfx1150, gfx120X, gfx110X, gfx103X
– nützlich für Nutzer neuerer AMD-GPUs ohne vollständiges ROCm-Setup.
🆚 Ollama vs. llama.cpp – Architektur-Konvergenz im Blick
Ein bemerkenswerter Trend zeichnet sich ab: Mit v0.30 schiebt Ollama seine eigene GGML-Schicht
heraus und vertraut ab dann direkt auf llama.cpp für die Inferenz.
Das bedeutet, dass Ollama und llama.cpp langfristig denselben Backend-Code nutzen werden –
Ollama bleibt das nutzerfreundliche Frontend (Modelfile-System, REST-API, automatische Downloads),
während llama.cpp weiterhin den rohen Inference-Kern und mehr Konfigurationskontrolle bietet.
Für Nutzer, die tiefes Layer-Offloading, Quantisierungsexperimente oder DeepSeek-V4-WIP-Branches
brauchen, bleibt llama.cpp direkt die bessere Wahl; für alles andere holt Ollama weiter auf.
Aktueller Unterschied bei DeepSeek V4: Weder Ollama noch upstream llama.cpp
unterstützen DeepSeek V4 offiziell. llama.cpp hat einen aktiven WIP-PR; Ollama wartet auf den llama.cpp-Merge.
Alle Angaben ohne Gewähr. CVE-Details aus NVD, GitHub Security Advisories, CERT Polska und Mondoo Vulnerability Intelligence. Update-Status der ungepatchten Windows-CVEs geprüft gegen Ollama GitHub Releases (Stand: 20. Mai 2026, ca. 09:00 UTC).