Баг в Ollama может привести к утечке памяти с открытых AI-серверов

Критическая уязвимость в Ollama может раскрывать данные из памяти процесса на доступных из сети серверах.

2026-05-15 GIGATAP Team #security
#ollama#llm security#vulnerability

Уязвимость в Ollama может привести к утечке памяти процесса с открытых серверов

Что было раскрыто#

Исследователи безопасности сообщили, что в Ollama есть критическая уязвимость out-of-bounds read в загрузчике моделей GGUF. Проблема отслеживается как CVE и имеет оценку CVSS 9.1.

Согласно отчету, уязвимость может позволить удаленному неаутентифицированному атакующему получить данные из памяти процесса Ollama, если сервис доступен из сети. В исходном материале говорится, что проблема может затрагивать более 300 000 серверов по всему миру.

Ollama — популярный open-source framework для локального запуска large language models. И в этом часть проблемы. Такие системы часто находятся рядом с чувствительными данными, а не далеко от них.

Баг описан как heap out-of-bounds read в цепочке обработки GGUF. В описанном сценарии атаки endpoint /api/create принимает предоставленный атакующим GGUF-файл, в котором заявленные offset и size для tensor превышают фактическую длину файла. Во время quantization сервер читает данные за пределами выделенного heap buffer.

Как работает утечка#

В отчете описана простая цепочка из трех шагов:

  • Загрузить специально подготовленный GGUF-файл с завышенными tensor values на доступный из сети сервер Ollama.
  • Запустить создание модели через /api/create.
  • Использовать /api/push для exfiltration данных из памяти в registry, контролируемый атакующим.

Если атака сработает, утекшая память может включать environment variables, API keys, system prompts и conversation data других пользователей, работающих одновременно. В отчете также отмечается, что инженеры часто подключают Ollama к инструментам вроде Claude Code. В такой конфигурации данные в памяти могут быть еще более чувствительными, потому что outputs инструментов могут проходить через сервер Ollama в рамках обычной работы.

Именно в этом реальный риск. Это не просто crash bug. Это путь к secrets.

Memory leak на уровне LLM serving может раскрыть информацию, которую операторы считают изолированной: keys, prompts, internal instructions и user content. На практике это часто именно те данные, которые атакующий хочет получить в первую очередь.

Почему это важно на практике#

Очевидный вывод здесь не в том, что «LLMs опасны». Он более конкретный. Открытую model-serving infrastructure нужно рассматривать как любой другой internet-facing service, который обрабатывает privileged data.

В отчете говорится, что REST API не предоставляет authentication out of box. Это важно. Если instance доступен из интернета, attack surface не теоретическая. Это сам API.

В источнике цитируется исследователь Cyera Дор Аттиас, который говорит, что атакующий может узнать «что угодно» об организации через AI inference, включая API keys, proprietary code и customer contracts. Формулировка резкая, но суть справедлива. Память inference service может стать точкой концентрации данных.

Операторам не стоит воспринимать это как узкий баг парсинга model-file с четкими границами. Влияние зависит от реальной deployment-схемы:

  • доступна ли Ollama из сети
  • находится ли она за firewall или authentication proxy
  • хранит ли она secrets в environment variables
  • передают ли другие инструменты чувствительные outputs в тот же process

Если ответ хотя бы на один из этих пунктов — да, риск повышается.

Проблема с Windows updater добавляет еще один уровень#

Тот же источник также сообщает о двух неисправленных уязвимостях в механизме обновления Ollama для Windows. Они отделены от memory leak, но важны, потому что показывают второй класс риска: доверие к обновлениям.

Согласно отчету, Windows desktop client автоматически запускается при входе в систему, слушает 127.0.0.1:11434 и в фоне проверяет обновления через /api/update. Исследователи говорят, что одна уязвимость связана с отсутствием signature check для update binary. Другая — с path traversal в том, как updater формирует локальный staging path из HTTP response headers.

Практический результат: если атакующий может повлиять на update responses, возможен arbitrary code execution во время процесса обновления. В отчете говорится, что атака может быть возможна, если атакующий контролирует update server, доступный клиенту жертвы. Также утверждается, что атакующие могут указать OLLAMA_UPDATE_URL на локальный plain-HTTP server. AutoUpdateEnabled описан как настройка по умолчанию.

Источник разделяет два исхода:

  • отсутствие signature verification само по себе может привести к code execution, но не к persistent code execution
  • добавление path traversal может позволить атакующему записать данные за пределами обычного staging path и сохранить malicious code на месте

Это стоит отделять от memory leak. Одно — disclosure bug. Другое — execution chain. Оба сценария серьезны с операционной точки зрения.

Что операторам нужно сделать сейчас#

Источник рекомендует короткий список защитных мер:

  • установить последние fixes
  • ограничить network access к instances Ollama
  • проверить deployments на доступность из интернета
  • разместить открытые instances за firewall
  • добавить authentication proxy или API gateway перед REST API

Этот список разумен, потому что главная проблема — не только сам баг, но и то, где именно запущен сервис и кто может к нему обращаться.