В HashiCorp Vault нашли уязвимость, из-за которой на сервере с хранилищем секретов можно запустить произвольный код. Ошибка кроется в каталоге плагинов. При восстановлении снимка хранилища Vault не проверяет, откуда берётся исполняемый файл плагина. Затронуты Vault Community Edition и Vault Enterprise до версии 2.1.1 включительно. Воспользоваться уязвимостью способен оператор с широкими правами, поэтому для большинства организаций риск остаётся ограниченным.
Уязвимость CVE-2026-105816
Проблема получила идентификатор CVE-2026-105816. О ней сообщил бюллетень HCSEC-2026-41 от 7 октября 2026 года. Уязвимость нашла внешняя сторона, то есть HashiCorp узнала о ней не от собственных инженеров.
Vault - хранилище секретов. В нём держат пароли, ключи шифрования, токены доступа к облакам и базам данных, сертификаты. Внешние плагины расширяют возможности продукта. Они регистрируются в каталоге и запускаются из папки, заданной параметром plugin_directory. Такая схема придумана ради безопасности. Администратор указывает единственное место, откуда разрешено исполнять сторонний код, а Vault следит за этим при регистрации.
Проверка устроена дотошно. Vault убеждается, что бинарник лежит внутри каталога плагинов. Учитываются и символьные ссылки: если файл ведёт за пределы папки, регистрация не пройдёт. Срабатывает проверка только в момент регистрации. Когда Vault позже берёт сохранённую запись каталога и запускает по ней плагин, повторной сверки уже нет.
Брешь открывается через снимки. Vault с интегрированным хранилищем (Integrated Storage) держит данные на собственном движке, построенном на протоколе Raft (алгоритм согласования состояния между узлами кластера). Этот движок умеет снимать и восстанавливать копии данных, включая каталог плагинов. Запись, попавшая в снимок в обход регистрации, может ссылаться на файл за пределами каталога плагинов. Тогда Vault запустит этот файл от имени служебной учётной записи сервиса. Запуск возможен и при распечатывании хранилища для плагинов, которые уже смонтированы.
Есть условия. Уязвимость работает в кластерах, где ключ распечатывания делят по схеме Шамира: его части хранят несколько человек, и собрать ключ можно только вместе. Второе условие - настроенный внешний каталог плагинов. Кластеры с автоматическим распечатыванием (auto-unseal) проблема не затрагивает. Не затрагивает она и конфигурации, где параметр plugin_directory вообще не задан.
Снимки в таких системах принято считать доверенным артефактом. Их делают для резервного копирования и восстановления после сбоя, а доступ к ним есть у администраторов и у служб резервного копирования. Уязвимость превращает этот доступ в возможность выполнить код на узле Vault. Последствия серьёзны, потому что рядом лежат самые чувствительные данные компании: учётные данные для баз данных, ключи для облачных сервисов, токены внутренних систем. Захват узла открывает к ним путь, а вместе с ними - и к сервисам, которые эти секреты используют.
Требование "привилегированный оператор" звучит строже, чем есть на деле. Восстановление снимка входит в обычные задачи администратора Vault. Круг людей с такими правами невелик, но и не сводится к одному инженеру службы безопасности. Проверить, кто и когда восстанавливал снимки, можно по журналам аудита, однако сам факт наличия прав уже создаёт риск. Известных случаев эксплуатации в реальных атаках нет, и публичных эксплойтов тоже не заявлено.
Исправления вышли в Vault Community Edition 2.1.2 и Vault Enterprise 2.1.2, 1.21.12, 1.20.17 и 1.19.23. Обновлять нужно каждый узел. Речь идёт не только об активных серверах, но и о резервных узлах (standby), а в Enterprise - также о репликах производительности и аварийного восстановления, которые получают копию данных. Пропущенный резервный узел сохранит уязвимую версию и при переключении займёт место основного.
После обновления поведение меняется заметно. Записи каталога, которые указывают за пределы каталога плагинов, в том числе через символьные ссылки, отклоняются, а соответствующие точки монтирования пропускаются при запуске. Это значит, что часть плагинов перестанет работать сразу после апгрейда. Их придётся зарегистрировать заново, разместив исполняемый файл внутри разрешённой папки. Администраторам стоит заранее составить список таких плагинов и проверить, что бинарники лежат там, где положено, иначе обновление обернётся простоем зависящих от них приложений.
Отдельного внимания заслуживает сама модель доверия к резервным копиям. Данные, вернувшиеся из снимка, попадают в конфигурацию системы так же, как введённые вручную, но проверок на этом пути меньше. Разработчики закрыли конкретную брешь, однако вопрос шире: любая точка восстановления становится каналом доставки изменений в обход штатных процедур. Компаниям, которые используют Vault для управления секретами, разумно пересмотреть, кто имеет право восстанавливать снимки и как эти действия фиксируются в журналах. Ограничение числа таких операторов и контроль над ними снижают риск не хуже, чем своевременная установка патча.
Ссылки
