Ollama, одна из самых популярных платформ для локального запуска моделей LLM, столкнулась сразу с двумя классами критических проблем: утечкой памяти процесса без аутентификации (CVE-2026-7482, Bleeding Llama, CVSS 9.1) и связанной цепочкой уязвимостей механизма обновления клиента для Windows (CVE-2026-42248, CVE-2026-42249, CVSS 7.7), дающих устойчивое выполнение кода при входе в систему. Это затрагивает сотни тысяч серверов и рабочие станции, на которых Ollama интегрирована с корпоративными сервисами и инструментами разработки, и требует немедленного обновления версий, изоляции инстансов и отключения автoобновления клиента для 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+ с одновременной сегментацией сети, а затем — централизованное отключение автoобновления клиента Windows и очистка автозагрузки на рабочих станциях.