Ollama, одна з найпопулярніших платформ для локального запуску моделей LLM, зіткнулася одразу з двома класами критичних проблем: витоком пам’яті процесу без автентифікації (CVE-2026-7482, Bleeding Llama, CVSS 9.1) та пов’язаним ланцюжком вразливостей механізму оновлення клієнта для Windows (CVE-2026-42248, CVE-2026-42249, CVSS 7.7), що дають стале виконання коду під час входу в систему. Це зачіпає сотні тисяч серверів і робочих станцій, на яких Ollama інтегрована з корпоративними сервісами та інструментами розробки, і вимагає негайного оновлення версій, ізоляції екземплярів та вимкнення автооновлення клієнта для Windows до виходу виправлень.

Технічні деталі: від витоку пам’яті до стійкого RCE

Bleeding Llama (CVE-2026-7482): витік пам’яті через GGUF-моделі

Вразливість CVE-2026-7482 описана в базі CVE.org як помилка читання за межами купи в завантажувачі формату GGUF в Ollama до версії 0.17.1. Запис доступний в офіційній картці CVE і продубльований у NVD. Уражений код у файлах fs/ggml/gguf.go та server/quantization.go, у функції WriteTo().

Суть проблеми:

• Інтерфейс /api/create приймає файл моделі у форматі GGUF, наданий клієнтом.
• GGUF-файл містить метадані про тензор (зміщення, розмір, форму), подібні до описаних у посібнику з тензорів TensorFlow.
• Ollama довіряє задекларованим розмірам і формі тензора, не звіряючи їх із реальною довжиною файлу.
• Під час квантизації тензора моделі у WriteTo() виконується читання за межами виділеного буфера купи.

Коренева причина — використання пакета unsafe у Go під час роботи з бінарними структурами GGUF. Документація Go прямо вказує, що пакет unsafe обходить гарантії безпеки пам’яті, і в цьому випадку це обернулося можливістю читання зайвих байтів із пам’яті процесу.

Дослідники Cyera показали трикроковий ланцюжок експлуатації:

1. Завантаження спеціально сформованого GGUF-файлу із завищеною формою тензора на мережевий сервер Ollama через HTTP POST.
2. Запуск створення моделі через /api/create, що ініціює читання за межами буфера та поміщає фрагменти пам’яті в отриманий артефакт моделі.
3. Експорт отриманої моделі до зовнішнього реєстру зловмисника через /api/push.

Критичні особливості для захисту:

• Експлуатація не потребує автентифікації — REST-інтерфейс Ollama за замовчуванням не має вбудованої перевірки справжності.
• Зловмисник контролює вміст GGUF, але дані, що витягуються, — довільні байти пам’яті процесу Ollama, не обмежені межами файлу.
• Початковий код проєкту відкритий і доступний на GitHub, що спрощує підготовку експлойта.

На практиці це перетворює будь-який екземпляр Ollama, відкритий у зовнішню мережу, на джерело витоків:

• змінні середовища (включно з ключами хмарних провайдерів, токенами CI/CD тощо);
• системні підказки LLM та конфіденційні інструкції;
• код і дані, що обробляються інструментами, інтегрованими з Ollama (наприклад, засобами розробки);
• фрагменти діалогів інших користувачів, яких обслуговує той самий процес.

CVE-2026-42248 і CVE-2026-42249: автооновлення Ollama для Windows як вектор персистентного RCE

Друга група вразливостей пов’язана з механізмом оновлення клієнта Ollama для Windows. Дослідження опубліковане командою Striga на їхньому сайті Striga Research, а координацією розкриття займалася CERT Polska.

Клієнт для Windows:

• автоматично стартує під час входу користувача через папку автозапуску Windows;
• працює локально на 127.0.0.1:11434 і періодично звертається до /api/update для перевірки оновлень;
• у разі виявлення оновлення завантажує та встановлює бінарний файл під час наступного запуску.

Виявлено два дефекти:

• CVE-2026-42248 (CVSS 7.7) — відсутність перевірки підпису оновлення: на відміну від версії для macOS, клієнт Windows не перевіряє криптографічний підпис бінарника перед установленням.
• CVE-2026-42249 (CVSS 7.7) — обходження шляху: шлях до локального каталогу для розміщення інсталятора формується напряму з HTTP-заголовків відповіді сервера оновлень без нормалізації та перевірки.

Якщо зловмисник може контролювати сервер оновлень, доступний клієнту Ollama (через переналаштування OLLAMA_UPDATE_URL на локальний HTTP-сервер, компрометацію реального сервера або мережеву підміну трафіку), ланцюжок експлуатації виглядає так:

1. Клієнт запитує оновлення за /api/update.
2. Зловмисник повертає «оновлення» — довільний виконуваний файл — і заголовки, що вказують шлях поза межами очікуваного каталогу (наприклад, у папку автозапуску Windows).
3. Клієнт зберігає файл за вказаним шляхом без перевірки підпису і без подальшого очищення непідписаних файлів.
4. Під час наступного входу в систему Windows автоматично запускає записаний виконуваний файл із привілеями користувача.

За даними CERT Polska, уразливі версії Ollama для Windows з 0.12.10 по 0.22.0 включно, причому вразливість залишається невиправленою на момент публікації рекомендацій. Тимчасові заходи включають відключення автоматичних оновлень і видалення ярлика Ollama з папки автозапуску.

Відсутність перевірки цілісності вже дає можливість одноразового запуску коду в контексті оновлення; додавання обходу шляху перетворює це на стале виконання коду під час кожного входу користувача, доки шкідливий файл присутній у папці автозапуску.

Оцінка впливу та пріоритет ризиків

Bleeding Llama (CVE-2026-7482) — основна загроза для організацій, у яких:

• сервери Ollama доступні з інтернету або з широких внутрішніх мереж без суворої сегментації;
• через Ollama проходять чутливі дані: вихідний код, договори, внутрішні документи, дані клієнтів;
• Ollama інтегрована з додатковими інструментами (наприклад, засобами аналізу коду), результати яких передаються моделі та зберігаються в пам’яті.

За відсутності дій наслідки можуть включати:

• масову компрометацію ключів і токенів із подальшим вторгненням до інших систем;
• витік конфіденційних підказок і бізнес-логіки, на якій побудовані внутрішні LLM-сервіси;
• розголошення даних користувачів і клієнтів, що проходять через діалоги з моделлю.

CVE-2026-42248/CVE-2026-42249 становлять підвищений ризик для робочих станцій розробників та аналітиків, де Ollama для Windows використовується як локальний інтерфейс до моделей і має доступ до:

• SSH-ключів і токенів репозиторіїв;
• облікових даних браузера та корпоративних VPN;
• робочих каталогів проєктів.

Ланцюжок дає зловмиснику стале виконання шкідливого коду з правами поточного користувача — цього достатньо для встановлення шпигунського ПЗ, викрадення секретів і подальшого просування інфраструктурою. При цьому єдина «точка вимкнення» — видалення файлу з папки автозапуску; самі логічні дефекти в компоненті оновлення залишаються.

Важливо, що два вектори доповнюють один одного: серверна вразливість розкриває секрети та контекст, тоді як клієнтська — забезпечує надійну точку опори на користувацьких системах. Концептуально можливі сценарії, коли дані, що витекли через Bleeding Llama (наприклад, конфігурації проксі чи параметри оновлень), спрощують подальшу експлуатацію клієнта для Windows.

Практичні рекомендації та перевірка вразливості

Сервери та контейнери: захист від Bleeding Llama

1. Негайно оновити Ollama до версії 0.17.1 і вище.
   Перевірити використовувану версію можна через офіційний репозиторій GitHub Ollama і реліз 0.17.1. Усі екземпляри нижче цієї версії слід вважати вразливими.
2. Обмежити мережевий доступ до API Ollama.
   • Закрити прямий доступ з інтернету до всіх інтерфейсів Ollama.
   • Дозволити доступ лише через VPN, шлюз API або зворотний проксі з автентифікацією.
   • Жорстко сегментувати внутрішні мережі: розробницькі та тестові екземпляри не повинні бути доступні з користувацьких сегментів.
3. Розгорнути автентифікуючий проксі або шлюз API.
   Оскільки REST API Ollama не має вбудованої автентифікації, перед усіма екземплярами слід розмістити компонент, що перевіряє облікові дані, токени або клієнтські сертифікати.
4. Аналіз журналів і можливої компрометації.
   • Шукати в логах HTTP-запити до /api/create з великими тілами й нетиповими джерелами, особливо в поєднанні з подальшими викликами /api/push до зовнішніх реєстрів.
   • Якщо екземпляр був доступний ззовні й працював на вразливій версії, припускати витік усіх секретів у пам’яті процесу Ollama та проводити ротацію ключів, токенів і паролів.
5. Переглянути політику завантаження моделей.
   Не дозволяти анонімним або неперевіреним користувачам завантажувати власні GGUF-моделі на сервери, що обробляють чутливі дані.

Робочі станції під Windows: тимчасові заходи проти RCE через оновлення

До появи офіційного виправлення для клієнта Ollama на Windows рекомендується:

1. Вимкнути автоматичне оновлення.
   Дотримуватися вказівок CERT Polska: вимкнути опцію AutoUpdateEnabled і не використовувати змінну OLLAMA_UPDATE_URL для перенаправлення на нестандартні або незахищені (HTTP) сервери.
2. Прибрати неконтрольований автозапуск.
   Видалити ярлик Ollama з папки автозапуску:
   %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. Це не усуває вразливостей, але позбавляє зловмисника зручної точки сталого запуску.
3. Перевірити наявність підозрілих файлів в автозапуску.
   Провести інвентаризацію виконуваних файлів у папці автозапуску та зіставити їх із очікуваним набором програм; невідомі або нещодавно з’явлені файли потребують окремого аналізу.
4. Посилити контроль мережевого периметра навколо оновлень.
   • Гарантувати, що трафік до сервера оновлень Ollama проходить через контрольований проксі й не може бути підмінений.
   • Заборонити використання нешифрованого HTTP для завантаження оновлень на рівні проксі або міжмережевого екрана.
5. Моніторинг активності процесів.
   Налаштувати засоби захисту кінцевих точок на відстеження запусків невідомих виконуваних файлів із папки автозапуску та виконуваних файлів, породжених процесом Ollama.

Для інфраструктур, де Ollama використовується і на серверах, і на робочих станціях Windows, пріоритетом має стати: оновлення серверних екземплярів до версії 0.17.1+ із одночасною сегментацією мережі, а потім — централізоване вимкнення автооновлення клієнта Windows і очищення автозапуску на робочих станціях.