Нещодавно розкрита вразливість CVE-2026-85180 дозволяє неавторизованим зловмисникам експлуатувати Ollama model-puller для здійснення атак типу server-side request forgery (SSRF) на внутрішні сервіси, включаючи хмарні кінцеві точки метаданих. Помилка зберігається в поточному релізі версії 0.33.2 і може бути спровокована без наявності дійсного облікового запису Ollama.

Чому ця вразливість є важливою

Багато команд запускають внутрішній сервер Ollama для надання LLM-моделей розробникам та CI-конвейєрам. API, що доставляє моделі, часто залишають відкритим, щоб будь-який користувач у внутрішній мережі міг запитати модель за назвою. Така зручність створює прямий шлях від публічного API до приватної мережі. CVE-2026-85180 перетворює цей шлях на зброю.

Зловмисник, який керує шкідливим реєстром моделей, може створити маніфест, що перенаправляє запит на завантаження на будь-яку адресу, доступну процесу Ollama. Коли pull API отримує маніфест, він автоматично слідує за перенаправленням. Оскільки pull endpoint не потребує автентифікації, зловмиснику не потрібен обліковий запис Ollama. Перенаправлення може вказувати на loopback, link-local або будь-яку приватну підмережу, що дає зловмиснику плацдарм усередині хмарної VPC жертви або в локальній (on-premise) мережі.

Найнебезпечнішою ціллю є сервіс хмарних метаданих (зазвичай 169.254.169.254). Ця кінцева точка видає тимчасові облікові дані екземпляру (instance).

Як помилка пройшла крізь попередні виправлення

На початку цього року Ollama виправила проблему з перенаправленням, ідентифіковану як CVE-2026-5530. Виправлення додало перевірку, яка блокувала перенаправлення на приватні адреси, але воно стосувалося лише основного компонента завантажувача. Tensor model downloader, який обробляє інший клас файлів моделей, використовує окрему бібліотеку HTTP-клієнта. Ця бібліотека обробляє перенаправлення вручну і не має жодної перевірки нової цілі. Як наслідок, стара перевірка ніколи не запускається для таких завантажень, залишаючи вектор SSRF відкритим.

Хто може постраждати

Під найбільшим ризиком перебувають підприємства, які надають доступ до endpoint Ollama широкому колу розробників. Хмарні (cloud-native) робочі навантаження, що покладаються на облікові дані на основі метаданих, є особливо вразливими.

Що можна зробити прямо зараз

Патч ще не випущено, і вразливість залишається у версії 0.33.2. Доки офіційне виправлення не з'явиться, операторам слід посилити мережевий рівень навколо процесу Ollama.

  • Припиніть довільні посилання на моделі. Обмежте API так, щоб лише довірені користувачі або сервіси могли надсилати назви моделей. Відхиляйте невідомі або надані користувачем URL-адреси реєстрів.
  • Обмежте вихідний трафік. На рівні контейнера, хоста або брандмауера заблокуйте з'єднання з loopback, link-local та приватними діапазонами IP-адрес для процесу Ollama. Явно забороніть доступ до адреси хмарних метаданих (169.254.169.254), якщо робоче навантаження дійсно цього не потребує.
  • Використовуйте перевірений реєстр. Розгорніть внутрішній реєстр моделей, який обслуговує лише перевірені маніфести. Застосуйте білий список (allow-list) імен хостів і відхиляйте будь-які перенаправлення, що вказують на інші ресурси.
  • Моніторте підозрілі завантаження. Скануйте логи Ollama на наявність запитів на завантаження (pull requests), які негайно генерують мережевий трафік на внутрішні адреси. Корелюйте ці дані з мережевою телеметрією, щоб виявляти неочікувані вихідні з'єднання.

За чим стежити далі

Слідкуйте за примітками до релізів та повідомленнями про безпеку проєкту, щоб не пропустити майбутній патч. Тим часом ставтеся до model-puller як до сервісу з мережевими можливостями та негайно застосуйте чотири заходи з пом'якшення наслідків.

Підсумок: Неавторизована вразливість SSRF у завантажувачі моделей Ollama може призвести до витоку хмарних облікових даних та внутрішніх API; до появи патча блокуйте вихідний доступ до приватних мереж, обмежуйте посилання на моделі та моніторте активність завантажень.