Десериализация в NLTK позволяет удалённо выполнить произвольный код

В библиотеке NLTK (Natural Language Toolkit) нашли уязвимость механизма десериализации. Производитель подтвердил проблему. Оценка по CVSS 3.1 составляет 9,8 балла из 10, а по CVSS 4.0 - 9,3. Готовый эксплойт уже опубликован в открытом доступе. Банк данных угроз безопасности информации присвоил записи идентификатор BDU:2026-12702, а единый реестр уязвимостей - номер CVE-2026-79657.

Детали уязвимости

Под угрозой версии NLTK до 3.10.2 включительно. Проблема затрагивает механизм, который восстанавливает объекты языка Python из файлов. Такой процесс называют десериализацией. Он превращает поток байтов обратно в готовые объекты программы. NLTK применяет его при загрузке заранее подготовленных данных, в том числе языковых моделей, корпусов и словарей. Если подсунуть библиотеке поддельный файл, она восстановит из него не безобидную структуру, а команды. Атакующий получает возможность исполнить собственный код на машине жертвы. Права будут такими же, как у процесса, который открыл файл. В типовом случае это учётная запись разработчика или сервиса обработки данных. Дата выявления уязвимости - 11 августа 2026 года.

Уязвимость относят к классу ошибок восстановления в памяти недостоверных данных. По классификации CWE ей присвоен номер CWE-502. Это уязвимость архитектуры, поскольку библиотека доверяет содержимому файла по умолчанию. Проверок целостности и происхождения данных в проблемном механизме нет. Злоумышленник действует удалённо, аутентификация ему не нужна. Единственное условие - жертва должна загрузить подготовленный файл. Вектором атаки служит манипулирование структурами данных. Следовательно, обмана пользователя через письмо или сайт не требуется. Достаточно, чтобы вредоносный файл оказался там, откуда его возьмут.

Кому это важно. NLTK широко используют в научных исследованиях, в учебных курсах и в прототипах систем обработки текста. Кроме того, библиотека встречается в производственных конвейерах, где готовит данные для моделей машинного обучения. Поэтому риск касается не только отдельных специалистов. Затронуты команды, которые привлекают чужие наборы данных, чужие модели и чужие словари. Также под удар попадают сборочные конвейеры, если они скачивают зависимости и ресурсы из внешних источников. Атака на цепочку поставок в такой схеме выглядит реалистично. Злоумышленнику достаточно один раз подменить файл в публичном репозитории. Дальше команда сама принесёт его в свою инфраструктуру.

Практика атак на подобные механизмы известна давно. Десериализация остаётся одной из частых причин выполнения стороннего кода в проектах на Python. Однако масштаб проблемы в стеке машинного обучения выше. Модели и наборы данных передают друг другу десятками и сотнями, часто без проверки контрольных сумм. Сведений о том, что эту конкретную уязвимость уже применили в реальных атаках, пока нет. Тем не менее публичный эксплойт снижает порог входа. Атакующему не нужно писать сложный инструмент самому. Он может взять готовый и подстроить его под конкретную цель.

Ещё одно последствие касается доверия к данным. Если вредоносный файл загружен, атакующий получает те же возможности, что и сам разработчик. Значит, он может читать исходный код, ключи доступа и учётные данные, а также изменять результаты работы моделей. В корпоративной среде это открывает путь к боковому перемещению (передвижению по сети в поисках новых целей) и к закреплению в системе. Для исследовательских групп ущерб может ограничиться потерей экспериментальных данных. Для компаний речь идёт о простое конвейеров и о компрометации выпускаемых моделей.

Исправление уже вышло. Производитель рекомендует обновиться до версии 3.10.3. Одной установки новой версии мало, поскольку старые копии библиотеки остаются в образах контейнеров, в кешах пакетных менеджеров и в локальных окружениях. Поэтому стоит проверить файлы фиксации версий зависимостей. Кроме обновления, разумно ограничить круг источников, откуда команда берёт модели и наборы данных. Простых мер вроде проверки одного лишь расширения файла недостаточно. Проблема сидит в формате хранения данных, а не в имени файла. Ещё одна мера - запускать обработку недоверенных данных в изолированной среде. Тогда даже успешный запуск кода не даст доступа ко всей системе.

Детали уязвимости

Ссылки