llama.cpp vydal za třicet dnů 229 verzí. U kritické díry se dva záznamy liší o 501 buildů
Knihovna llama.cpp, na které stojí většina domácího provozu jazykových modelů, vydala mezi 1. a 30. červencem 2026 dvě stě dvacet devět verzí. Číslo v jejich názvu přitom není pořadí vydání, ale počet commitů. Změřili jsme, jak se v takové řadě pozná záplatovaná verze: ze třinácti bezpečnostních upozornění projektu má jedno kolonku „opraveno v“ prázdnou a u kritické zranitelnosti označuje GitHub za zranitelné verze do b7991, kdežto záznam CVE u organizace MITRE všechno pod b8492.
Kdo si pouští jazykový model na vlastním počítači, používá skoro jistě llama.cpp, i když o tom nemusí vědět. Je to knihovna v C++, která načte model ve formátu GGUF a spočítá odpověď na procesoru i na grafické kartě. Populární nadstavba Ollama ji nemá jen jako jednu z možností: v repozitáři drží soubor, který určuje, ze které verze llama.cpp se sestavuje.
Vydává se tam ale jinak, než je běžné. Žádné 1.2.3, jen řada značek b9852, b9853 a tak dál. Přes veřejné rozhraní GitHubu, které na tohle nechce klíč, jsme 31. července 2026 spočítali, kolik jich za měsíc přibylo a co to číslo vlastně znamená, když si chce člověk ověřit, jestli má zalepenou bezpečnostní díru.
Číslo v názvu je počet commitů, ne pořadí vydání
První červencové vydání neslo značku b9852 a vyšlo 1. července v 5:11 světového času. Poslední, které se do měření vešlo, bylo b10199 z 30. července ve 20:33 téhož času. Mezi těmi dvěma čísly je 348 hodnot, jenže vydání jsme napočítali 229. Sto devatenáct čísel v té řadě tedy žádné vydání nemá.
Vysvětlení je přímo v repozitáři a dá se přečíst. Soubor cmake/build-info.cmake nastavuje hodnotu BUILD_NUMBER příkazem git rev-list --count HEAD, tedy počtem commitů v historii. A předpis pro sestavení spustí vydání jen tehdy, když zápis do hlavní větve sáhne na zdrojové soubory: seznam přípon v něm začíná u CMakeLists.txt a pokračuje přes .h, .c, .cpp, .cu až po .metal. Commit, který mění jen dokumentaci, vydání nevyrobí. Stejně tak ho vynechá commit, jehož popis obsahuje značku [no release].
Prakticky to znamená, že b10199 neznamená deset tisíc vydání. Je to pořadové číslo commitu, u kterého vydání shodou okolností vzniklo.
Osm vydání za den, kdy se vydávalo
Těch 229 vydání se rozložilo do 28 dnů z třiceti. Volno bylo v neděli 19. a v sobotu 25. července. Na den, kdy se vydávalo, tak vychází 8,2 vydání, na kalendářní den 7,6. Nejvíc jich bylo ve středu 8. července: pětadvacet.
Pro srovnání jsme týmž způsobem spočítali Ollamu, která llama.cpp uvnitř sestavuje. Za červenec vydala sedm verzí, od v0.31.2 po v0.32.5, a čísluje je běžným způsobem. Soubor LLAMA_CPP_VERSION v jejím repozitáři měl k 31. červenci hodnotu b10091, což je vydání z 22. července. Kdo tedy jede na Ollamě, nemá špičku llama.cpp, ale build starší o 108 čísel. To není výtka, jen popis toho, co připnutá verze znamená.
Která verze má díru zalepenou
Tady se řada čísel začne prát s bezpečností. Projekt má k dnešku třináct zveřejněných bezpečnostních upozornění. Devět z nich uvádí opravenou verzi číslem buildu, tři hashem commitu a u jednoho je kolonka „opraveno v“ prázdná. Jedno upozornění nemá přidělené číslo CVE vůbec.
Prázdnou kolonku má zrovna to nejzávažnější. CVE-2026-34159 je neověřené spuštění cizího kódu přes takzvaný RPC backend, tedy část, která rozděluje výpočet mezi víc strojů po síti. Hodnocení závažnosti je 9,8 z deseti. Upozornění na GitHubu označuje za zranitelné verze do b7991 včetně a opravenou verzi neuvádí. Záznam téhož CVE vedený organizací MITRE považuje za zasažené všechno pod b8492. Mezi těmi dvěma čísly je 501 buildů; b7991 vyšlo 10. února 2026, b8492 až 23. března, takže je v tom šest týdnů vývoje.
Druhý rozpor leží uvnitř jednoho záznamu. U CVE-2026-33298, což je přetečení haldy při čtení tenzorů z GGUF souboru, uvádí upozornění na GitHubu zranitelné verze „nižší než b7437“ a opravenou verzi b7824. Kdyby oprava přišla až v b7824, musely by být zranitelné i všechny verze mezi tím, a těch je 387. Záznam u MITRE tuhle nesrovnalost nemá a uvádí jen zasažené verze pod b7824.
Sluší se dodat i to, co vychází dobře. U většiny upozornění obě strany sedí. CVE-2026-27940 má na GitHubu zranitelné verze do b8145 a opravu v b8146, MITRE zasažené pod b8146 – je to totéž řečené dvakrát. Porovnat se dá dvanáct upozornění, protože jedno číslo CVE nemá, a rozejít se dokázala tři. Kromě obou popsaných je to ještě CVE-2024-32878 z roku 2024, kde je rozdíl 25 buildů. Nejhůř tedy dopadl záznam s nejvyšším hodnocením.
Soukromé hlášení chyb je vypnuté, dokument si odporuje
Souvislost s tím má bezpečnostní politika projektu. Soubor SECURITY.md otevírá zvýrazněná věta, že program pro soukromé hlášení zranitelností je až do odvolání vypnutý, opravy se mají posílat rovnou jako veřejné návrhy změn a e-maily zůstanou bez odpovědi.
O dva odstavce níž tentýž dokument žádá pravý opak: chybu hlaste soukromě, nezveřejňujte ji jako issue a dejte projektu aspoň devadesát dnů. Obojí jsme si ověřili dvakrát, v surovém souboru i na vykreslené stránce. Text si tedy protiřečí sám a nálezce z něj nepozná, kudy má jít. Dokument k tomu dodává, že projekt udržují dobrovolníci v rámci svých možností – což je poctivé přiznání, ne výmluva. Rozpor obou pasáží tím ale vysvětlený není.
Rozsah, který projekt považuje za svůj, je v témže souboru vymezený přesně: adresáře src, ggml, gguf-py a serverová část, u níž jsou z platných hlášení vyňaté webové rozhraní, experimentální funkce a chyby vedoucí k zahlcení služby. Hlášení psaná výhradně modelem projekt nepřijímá a žádá ke každému funkční ukázku.
Jak si to čtenář ověří u sebe
Nainstalovaná verze se dá zjistit přepínačem --version; program vypíše číslo buildu a hash commitu. To číslo se pak dá porovnat se seznamem upozornění. Když se ale zrovna trefíte do rozmezí, o kterém se oba seznamy neshodnou, spolehlivá odpověď z veřejných záznamů nevyjde a zbývá držet se toho vyššího čísla.
Obě popsané díry mají navíc jasné spouštěče. RPC backend je síťová služba a nemá co dělat na veřejné adrese. Přetečení při čtení GGUF se týká souborů modelů – a ty se stahují od cizích lidí, i když jde jen o zmenšenou verzi známého modelu.
Nejpraktičtější závěr z těch čísel je jiný, než by se čekalo. Rychlost vydávání není problém; problém je, že se řada buildů používá jako verze v bezpečnostních záznamech, přestože pro to nevznikla. Číslo commitu odpovídá na otázku „kolikátý zápis to je“, ne na otázku „mám opravu“. Dokud se na obojí odpovídá jedním číslem, bude se rozdíl 501 buildů opakovat.
Zdroje: repozitář ggml-org/llama.cpp na GitHubu, jeho soubory build-info.cmake, release.yml a SECURITY.md, veřejné rozhraní GitHubu pro vydání a bezpečnostní upozornění, rozhraní organizace MITRE pro záznamy CVE a repozitář ollama/ollama. Počty vydání, rozdíly čísel buildů i průměry na den jsme spočítali sami z odpovědí obou rozhraní 31. července 2026.