Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2026-7482 — Воспроизводит чтение за пределами выделенной памяти (heap out-of-bounds read) CVE-2026-7482 при загрузке и квантовании GGUF в Ollama, с дифференциальным анализом квантованных артефактов для демонстрации влияния выхода за границы. | Kitploit
Инструменты/GitHubGitHub/szybnev/cve-2026-7482
Анализ уязвимостейЭксплуатацияФаззингАнализ Бинарных ФайловСтатьи и Исследования
GitHubszybnev/cve-2026-7482

CVE-2026-7482

Воспроизводит чтение за пределами выделенной памяти (heap out-of-bounds read) CVE-2026-7482 при загрузке и квантовании GGUF в Ollama, с дифференциальным анализом квантованных артефактов для демонстрации влияния выхода за границы.

Репозиторий
1134 месяцев назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

CVE-2026-7482: Воспроизведение Heap OOB Read в GGUF Ollama

Этот репозиторий содержит мой локальный скрипт воспроизведения для CVE-2026-7482 — чтения за пределами выделенной памяти (heap out-of-bounds read) в уязвимых путях загрузки и квантизации GGUF в Ollama.

Важный результат этой работы узок: мне удалось стабильно вызывать условие Heap OOB и получать артефакты GGUF, подверженные влиянию OOB при квантизации. Мне не удалось продемонстрировать явное воздействие «чёрного ящика», такое как надёжное восстановление секретов из открытого текста или прямое извлечение строк-канареек из полученного артефакта.

Что делает этот PoC

exp.py создаёт два файла GGUF:

  • вредоносный усечённый GGUF с тензором, который объявляет больше байт, чем фактически содержится в файле;
  • полный контрольный GGUF, заполненный нулями, с той же объявленной формой тензора.

Он загружает оба файла в уязвимый экземпляр Ollama через локальный API Ollama, запускает квантизацию с помощью /api/create, копирует сгенерированные блобы GGUF из локального Docker-контейнера и сравнивает вредоносный вывод с нулевым контрольным выводом.

Дифференциальное сравнение полезно, поскольку показывает, что уязвимый путь квантизации использовал байты, отсутствовавшие в исходном вредоносном файле GGUF. В моих тестах это поведение было стабильным на Ollama 0.17.0 и отклонялось исправленным путём 0.17.1.

Требования

  • Python 3 с requests
  • Доступ к Docker для уязвимого контейнера Ollama
  • Ollama 0.17.0, доступная на локальном порту API
  • Имя уязвимого тестового контейнера, например ollama-old-test

Пример лабораторной цели:

root@kitploit:~
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0

Использование

Установите единственную зависимость Python:

root@kitploit:~
python3 -m pip install requests

Запустите тест по умолчанию против http://localhost:11435 и контейнера ollama-old-test:

root@kitploit:~
python3 exp.py

Явные аргументы:

root@kitploit:~
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.gguf
  • control_model.gguf
  • quantized_model.gguf
  • control_quantized_model.gguf
  • q8_dequantized_f32.bin
  • q8_pseudo_f16.bin
  • q8_pseudo_f16.txt

Результаты

В моих локальных тестах уязвимая версия Ollama создавала квантизованные выходные данные, где полезная нагрузка вредоносного тензора отличалась от нулевого контрольного тензора, несмотря на то, что вредоносный файл GGUF не содержал этих байт.

Этого достаточно, чтобы показать артефакт, подверженный влиянию OOB. Этого недостаточно, чтобы заявлять о практическом раскрытии данных «чёрного ящика».

Я также тестировал данные в стиле канареек в одновременных промптах моделей и искал в сгенерированных артефактах, деквантизованных байтах float32 Q8_0 и выходных данных псевдо-F16 реконструкции. Мне не удалось восстановить точные канарейки или значимые фрагменты открытого текста.

Вероятная причина в том, что байты не копируются как сырая память кучи. Они проходят через конвейер преобразования и квантизации модели:

root@kitploit:~
heap bytes -> интерпретируются как значения тензора F16/F32 -> преобразуются/квантизуются -> выходной тензор GGUF

Этот путь является потерянным, особенно с квантизованными форматами, такими как Q4_K_M. Q8_0 сохраняет больше числовой информации, чем Q4_K_M, но всё равно не обеспечил надёжного восстановления открытого текста в моих тестах в стиле «чёрного ящика».

Область применения и ограничения

Это локальное лабораторное воспроизведение и помощник по анализу артефактов.

Он не предоставляет надёжный примитив удалённой эксфильтрации секретов. Он также требует локального доступа к Docker для копирования сгенерированного блоба Ollama из тестового контейнера, поэтому этап анализа не является чисто удалённым рабочим процессом «чёрного ящика».

Практический вывод из моих тестов:

  • Поведение Heap OOB воспроизводимо.
  • Квантизованные артефакты, подверженные влиянию OOB, наблюдаемы.
  • Явное воздействие на открытый текст «чёрного ящика» не продемонстрировано.

Ссылки

  • Запись NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-7482
  • Коммит исправления Ollama: https://github.com/ollama/ollama/commit/88d57d0483cca907e0b23a968c83627a20b21047

Связанные работы

Существует также отдельный репозиторий PoC от 0x0OZ:

https://github.com/0x0OZ/CVE-2026-7482-PoC

Эта реализация демонстрирует более сильный рабочий процесс в стиле «белого ящика», отправляя сгенерированный артефакт модели в контролируемый реестр. С исправлением потока загрузки в реестр из моего PR он завершается чисто в моей локальной лаборатории:

https://github.com/0x0OZ/CVE-2026-7482-PoC/pull/1

Даже с этим лучшим сквозным путём сбора артефактов остаётся важной та же оговорка о качестве данных: выходные данные являются квантизованными/преобразованными моделью данными, а не прямым сырым дампом кучи.

Отказ от ответственности

Этот репозиторий предназначен только для авторизованных исследований уязвимостей и защитного воспроизведения. Тестируйте только системы, которыми вы владеете или на оценку которых имеете явное разрешение.

Скачать инструмент