
Воспроизводит чтение за пределами выделенной памяти (heap out-of-bounds read) CVE-2026-7482 при загрузке и квантовании GGUF в Ollama, с дифференциальным анализом квантованных артефактов для демонстрации влияния выхода за границы.
Этот репозиторий содержит мой локальный скрипт воспроизведения для CVE-2026-7482 — чтения за пределами выделенной памяти (heap out-of-bounds read) в уязвимых путях загрузки и квантизации GGUF в Ollama.
Важный результат этой работы узок: мне удалось стабильно вызывать условие Heap OOB и получать артефакты GGUF, подверженные влиянию OOB при квантизации. Мне не удалось продемонстрировать явное воздействие «чёрного ящика», такое как надёжное восстановление секретов из открытого текста или прямое извлечение строк-канареек из полученного артефакта.
exp.py создаёт два файла GGUF:
Он загружает оба файла в уязвимый экземпляр Ollama через локальный API Ollama, запускает квантизацию с помощью /api/create, копирует сгенерированные блобы GGUF из локального Docker-контейнера и сравнивает вредоносный вывод с нулевым контрольным выводом.
Дифференциальное сравнение полезно, поскольку показывает, что уязвимый путь квантизации использовал байты, отсутствовавшие в исходном вредоносном файле GGUF. В моих тестах это поведение было стабильным на Ollama 0.17.0 и отклонялось исправленным путём 0.17.1.
requests0.17.0, доступная на локальном порту APIollama-old-testПример лабораторной цели:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
Установите единственную зависимость Python:
python3 -m pip install requests
Запустите тест по умолчанию против http://localhost:11435 и контейнера ollama-old-test:
python3 exp.py
Явные аргументы:
python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32
Скрипт записывает локальные артефакты, такие как:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtВ моих локальных тестах уязвимая версия Ollama создавала квантизованные выходные данные, где полезная нагрузка вредоносного тензора отличалась от нулевого контрольного тензора, несмотря на то, что вредоносный файл GGUF не содержал этих байт.
Этого достаточно, чтобы показать артефакт, подверженный влиянию OOB. Этого недостаточно, чтобы заявлять о практическом раскрытии данных «чёрного ящика».
Я также тестировал данные в стиле канареек в одновременных промптах моделей и искал в сгенерированных артефактах, деквантизованных байтах float32 Q8_0 и выходных данных псевдо-F16 реконструкции. Мне не удалось восстановить точные канарейки или значимые фрагменты открытого текста.
Вероятная причина в том, что байты не копируются как сырая память кучи. Они проходят через конвейер преобразования и квантизации модели:
heap bytes -> интерпретируются как значения тензора F16/F32 -> преобразуются/квантизуются -> выходной тензор GGUF
Этот путь является потерянным, особенно с квантизованными форматами, такими как Q4_K_M. Q8_0 сохраняет больше числовой информации, чем Q4_K_M, но всё равно не обеспечил надёжного восстановления открытого текста в моих тестах в стиле «чёрного ящика».
Это локальное лабораторное воспроизведение и помощник по анализу артефактов.
Он не предоставляет надёжный примитив удалённой эксфильтрации секретов. Он также требует локального доступа к Docker для копирования сгенерированного блоба Ollama из тестового контейнера, поэтому этап анализа не является чисто удалённым рабочим процессом «чёрного ящика».
Практический вывод из моих тестов:
Существует также отдельный репозиторий PoC от 0x0OZ:
Эта реализация демонстрирует более сильный рабочий процесс в стиле «белого ящика», отправляя сгенерированный артефакт модели в контролируемый реестр. С исправлением потока загрузки в реестр из моего PR он завершается чисто в моей локальной лаборатории:
Даже с этим лучшим сквозным путём сбора артефактов остаётся важной та же оговорка о качестве данных: выходные данные являются квантизованными/преобразованными моделью данными, а не прямым сырым дампом кучи.
Этот репозиторий предназначен только для авторизованных исследований уязвимостей и защитного воспроизведения. Тестируйте только системы, которыми вы владеете или на оценку которых имеете явное разрешение.