llama.cpp: fundament lokalnej infrastruktury AI z pięcioma CVE w pięć miesięcy

Jeśli używasz Ollama, LM Studio, text-generation-webui lub jakiegokolwiek innego narzędzia do lokalnego uruchamiania modeli — sprawdź wersję llama.cpp pod spodem. Większość tych narzędzi to warstwy interfejsu nad tym samym silnikiem. Podatność w llama.cpp to podatność we wszystkich z nich jednocześnie.

Najnowsza: CVE-2026-34159, CVSS 9.8, bez uwierzytelnienia. Atakujący z dostępem TCP do portu serwera RPC dostaje pełny odczyt i zapis pamięci procesu, obejście ASLR i zdalne wykonanie kodu. Łatka: wersja b8492 lub nowsza.

llama.cpp jako warstwa której nikt nie widzi

llama.cpp to otwartoźródłowy silnik wnioskowania dla dużych modeli językowych napisany w C/C++ przez Georgi Gerganova. Projekt ma ponad 80 000 gwiazdek na GitHubie i jest dosłownie fundamentem ekosystemu lokalnej infrastruktury AI: Ollama, LM Studio, text-generation-webui, Jan, GPT4All, koboldcpp, MLC LLM — wszystkie używają llama.cpp pod spodem. Użytkownik który zainstalował Ollama żeby uruchomić lokalny model językowy prawdopodobnie nie wie że uruchamia llama.cpp. Wie że uruchamia "Ollama."

To jest właśnie ten rodzaj niewidocznej zależności której dotyczyły wszystkie incydenty supply chain opisywane przez cyberflux przez cały kwiecień — komponent infrastrukturalny używany przez miliony wdrożeń, bez świadomości końcowych użytkowników co siedzi pod spodem.

Strona bezpieczeństwa projektu na GitHubie zawiera jedno zdanie które opisuje skalę ryzyka lepiej niż jakikolwiek raport: "A team of volunteers on a reasonable-effort basis maintains this project." Projekt który napędza miliony wdrożeń AI na całym świecie jest utrzymywany przez wolontariuszy na zasadzie "w miarę możliwości."

CVE-2026-34159: jeden null pointer, pełna kontrola nad procesem

Bleeding Llama — jak SecurityWeek nazwał tę klasę podatności — dotyczy backendu RPC w llama.cpp. Backend RPC pozwala na rozproszony inference: klient przesyła tensor do serwera przez TCP, serwer go przetwarza i zwraca wyniki. To jest standardowy mechanizm dla wdrożeń multi-GPU lub wdrożeń gdzie model jest za duży na jeden komputer.

Podatność jest precyzyjna. Funkcja deserialize_tensor() przetwarza dane tensorów przesyłane przez sieć. Gdy pole buffertensora jest ustawione na zero — co atakujący może kontrolować przez wysłanie odpowiednio spreparowanej wiadomości — funkcja całkowicie pomija walidację granic bufora. W C/C++ brak walidacji granic przy operacjach na pamięci to bezpośredni dostęp do dowolnego adresu w przestrzeni pamięci procesu.

Łańcuch exploitacji: wyślij spreparowaną wiadomość GRAPH_COMPUTE z tensorem gdzie buffer=0 → deserialize_tensor()pomija bounds check → odczytaj dowolne adresy przez operacje ALLOC_BUFFER/BUFFER_GET_BASE → użyj wyciekniętych wskaźników żeby obejść ASLR → nadpisz krytyczne struktury pamięci → zdalne wykonanie kodu.

Wymagania: dostęp TCP do portu serwera RPC. Żadnego uwierzytelnienia. Żadnej interakcji użytkownika. Żadnego wcześniejszego dostępu do systemu.

Naprawa to jedna linia kodu dodana do deserialize_tensor():

cpp

if (result == nullptr || result->buffer == nullptr) {

Sprawdzenie null pointera które powinno tam być od początku. Pull Request #20908, wersja b8492.

Pięć CVE w pięć miesięcy

CVE-2026-34159 nie jest pierwszą krytyczną podatnością w llama.cpp w tym roku. Jest piątą.

Styczeń 2026 — CVE-2026-21869 (CVSS 8.8): parametr n_discard w endpointach serwera HTTP akceptuje ujemne wartości bez walidacji. Gdy kontekst LLM jest pełny, ujemna wartość powoduje out-of-bounds write w pętli ewaluacji tokenów. Deterministic memory corruption — crash lub RCE. Wymagania: dostęp sieciowy do serwera. Zero uwierzytelnienia.

Luty 2026 — CVE-2026-2069: przepełnienie bufora stosu w obsłudze gramatyki GBNF. Lokalny dostęp wymagany — niższy priorytet.

Marzec 2026 — CVE-2026-33298: integer overflow w ggml_nbytes przy przetwarzaniu pliku modelu GGUF. Wynik arytmetyczny przepełnia typ całkowity, alokacja jest za mała, następny zapis przepełnia bufor. RCE przez złośliwy plik modelu.

Marzec 2026 — CVE-2026-27940: heap buffer overflow przez integer overflow w parsowaniu GGUF — opisany wprost jako "obejście poprawki CVE-2025-53630." Naprawiono błąd, nie naprawiono wzorca.

Kwiecień 2026 — CVE-2026-34159: Bleeding Llama, opisana powyżej.

Pięć podatności, dwie klasy wektorów: serwer HTTP/RPC dostępny sieciowo bez uwierzytelnienia, i złośliwy plik modelu GGUF. Ta druga klasa łączy się bezpośrednio z tym co cyberflux opisywał przy SGLang CVE-2026-5760 — plik modelu jako złośliwe oprogramowanie. Ta sama klasa błędów. Różne projekty. Infekcja przez format GGUF który krąży między deweloperami jako standardowy format wymiany modeli.

1 652 wystawione API Ollama — i co to oznacza po Bleeding Llama

Intruder w badaniu z marca 2026 znalazł 1 652 instancje Ollama wystawione na internet bez żadnego uwierzytelnienia spośród ponad 5 200 wystawionych w ogóle.

Ollama używa llama.cpp. CVE-2026-21869 (ujemna wartość n_discard → OOB write) dotyczy serwera HTTP llama.cpp — tego samego przez który Ollama serwuje swoje API. Każda z tych 1 652 wystawionych instancji bez uwierzytelnienia była podatna na CVE-2026-21869 od momentu gdy ją zainstalowali.

CVE-2026-34159 dotyczy backendu RPC — który w typowej konfiguracji Ollama nie jest domyślnie wystawiony na internet. Ale w środowiskach rozproszonych, multi-GPU, klastrach AI — gdzie RPC jest aktywowane celowo — wymaganie "dostęp TCP do portu RPC" jest spełnione przez każdego w tej samej sieci.

Wolontariacki projekt, produkcyjna infrastruktura

Jest tu napięcie które warto wyartykułować wprost.

llama.cpp jest utrzymywany przez wolontariuszy. Strona bezpieczeństwa prosi o 90 dni na naprawę podatności przed publicznym ujawnieniem. Projekt aktywnie nie przyjmuje zgłoszeń napisanych wyłącznie przez AI — co jest politycznym sygnałem o jakości wymaganych zgłoszeń.

To jest właściwe podejście dla projektu open source. Problem polega na tym że miliony wdrożeń produkcyjnych — w organizacjach enterprise, w środowiskach badawczych, przez komercyjne narzędzia — opiera się na wolontariackim projekcie bez dedykowanego zespołu bezpieczeństwa, bez programu bug bounty, bez SLA na czas naprawy.

To jest ta sama obserwacja którą Mandiant poczynił w M-Trends 2026 — 28.3% CVE eksploitowanych w ciągu 24 godzin od ujawnienia — ale w kontekście projektu bez dedykowanego procesu bezpieczeństwa. Gdy podatność jest ujawniona, ile organizacji używających Ollamy wie że muszą zaktualizować llama.cpp?

Prawdopodobna odpowiedź: te które wiedzą że używają Ollamy i regularnie ją aktualizują. Nie te które zainstalowały ją rok temu i traktują jak narzędzie które "po prostu działa."

Co zrobić

Dla użytkowników Ollamy: ollama --version i weryfikacja czy jest zaktualizowana do najnowszej wersji. Ollama automatycznie aktualizuje llama.cpp przy aktualizacji samej aplikacji. Wersja Ollamy z llama.cpp b8492 lub nowszym jest bezpieczna dla CVE-2026-34159.

Dla wdrożeń z włączonym RPC: port RPC (domyślnie 50052) nie powinien być dostępny z zewnątrz sieci wewnętrznej. Jeśli jest wystawiony publicznie — pilna aktualizacja do b8492 i zamknięcie portu na poziomie firewall.

Dla użytkowników pobierających modele GGUF z publicznych źródeł: CVE-2026-33298 i CVE-2026-27940 są exploitowalne przez złośliwy plik modelu. Pobieranie modeli wyłącznie z zaufanych, weryfikowanych repozytoriów — i weryfikacja skrótów plików przed załadowaniem — jest minimalnym zabezpieczeniem.

Podsumowanie

llama.cpp jest fundamentem pod większością lokalnej infrastruktury AI. Pięć CVE w pięć miesięcy — dwie klasy: serwer dostępny sieciowo bez uwierzytelnienia i złośliwy plik modelu GGUF. Bleeding Llama jest najpoważniejsza: CVSS 9.8, zero uwierzytelnienia, pełna kontrola nad procesem przez jedno połączenie TCP.

Projekt jest utrzymywany przez wolontariuszy. Narzędzia zbudowane na nim — Ollama, LM Studio, dziesiątki innych — są wdrożone produkcyjnie przez miliony użytkowników którzy nie wiedzą co mają pod spodem.

To jest właśnie ten rodzaj niewidocznej zależności o której NSA i CISA pisały tydzień temu przy okazji wytycznych dla agentów AI: organizacje wdrażają infrastrukturę AI szybciej niż budują mechanizmy zarządzania jej bezpieczeństwem. llama.cpp jest kolejnym dowodem że ta obserwacja jest trafna.

Źródła

SecurityWeek — pierwotne omówienie Bleeding Llama: https://www.securityweek.com/critical-llama-cpp-flaw-dubbed-bleeding-llama-can-be-exploited-remotely/

SentinelOne Vulnerability Database — CVE-2026-34159 szczegóły techniczne: https://www.sentinelone.com/vulnerability-database/cve-2026-34159/

GitHub Security Advisory — CVE-2026-21869 (n_discard OOB write): https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-8947-pfff-2f3c

SentinelOne — CVE-2026-27940 (bypass poprawki CVE-2025-53630): https://www.sentinelone.com/vulnerability-database/cve-2026-27940/

SentinelOne — CVE-2026-33298 (integer overflow GGUF): https://www.sentinelone.com/vulnerability-database/cve-2026-33298/

TheHackerWire — CVE-2026-34159 szczegóły łańcucha exploitacji: https://www.thehackerwire.com/llama-cpp-critical-rce-via-rpc-deserialization-bypass/