Openbao
Уязвимости
20
Эксплуатируемые
0
Макс. CVSS
9.4
Макс. EPSS
0.00655
Распределение по критичности
Критический
2
Высокий
4
Средний
10
Низкий
4
Также сопоставлено как (исходные строки): openbao
Топ уязвимостей
CVE-2026-33758OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.5.2 установки OpenBao, которые имеют способ аутентификации OIDC/JWT и роль с конфигурацией `callback_mode=direct` уязвимы для XSS через параметр `error_description` на странице для неудачной аутентификации. Это позволяет злоумышленнику получить доступ к токену, используемому в Web UI жертвой. Параметр `error_description` был заменен на статическое сообщение об ошибке в v2.5.2. Уязвимость может быть смягчена путем удаления любых ролей с `cllback_mode` установленным на `direct`.
CVE-2025-54997OpenBao предоставляет программное решение для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. В версиях 2.3.1 и ниже некоторые реализации OpenBao намеренно ограничивают привилегированных операторов API от выполнения системного кода или установления сетевых соединений. Однако эти операторы могут обойти оба ограничения через подсистему аудита, манипулируя префиксами журналов. Это позволяет неавторизованное выполнение кода и доступ к сети, нарушая предполагаемую модель безопасности. Проблема исправлена в версии 2.3.2.
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-xp75-r577-cvhp
- [2] https://github.com/openbao/openbao/pull/1634
- [3] https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vault-operator-may-execute-code-on-the-underlying-host/76033
CVE-2026-33757OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.5.2 OpenBao не подсказывает подтверждение пользователя при входе в систему через JWT/OIDC и роль с `callback_mode` установленной на `direct`. Это позволяет злоумышленнику запустить запрос аутентификации и выполнить «дистанционное фишинг», заставив жертву посетить URL-адрес и автоматически войти в сеанс злоумышленника. Несмотря на то, что он основан на потоке кода авторизации, режим «прямого» возвращает прямо на API и позволяет злоумышленнику проводить опрос для токена OpenBao до тех пор, пока он не будет выпущен. Версия 2.5.2 включает в себя дополнительный экран подтверждения для логинов прямого `` типа, который требует ручного взаимодействия пользователя для завершения аутентификации. Эта проблема может быть решена либо путем удаления любых ролей с `callback_mode=direct` или обеспечения подтверждения для каждой сессии на стороне эмитента токенов для идентификатора клиента, используемого OpenBao.
CVE-2025-64761OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.4.4 привилегированный оператор мог использовать подсистему группы идентификации для добавления корневой политики в группу идентичности, увеличивая разрешения своего или другого пользователя в системе. В частности, это проблема, когда оператор в корневом пространстве имен имеет доступ к конечным точкам идентификации / групп, а оператор не имеет доступа к политике. В противном случае оператор, имеющий доступ к политике, может создать или изменить существующую политику для предоставления разрешений, эквивалентных корней, через возможность sudo. Эта проблема была исправлена в версии 2.4.4.
CVE-2025-59043OpenBao — это система управления секретами, основанная на идентификации. В версиях OpenBao до 2.4.1 после декодирования JSON‑объекты могут потреблять заметно больше памяти, чем их сериализованный размер, позволяя достичь коэффициента использования памяти ≈35 (аналог zip‑bomb). Это позволяет обойти параметр **max_request_size**, предназначенный для защиты от атак отказа в обслуживании. Тело запроса разбирается в map[string]interface{} (http/logical.go строка 50) очень рано в цепочке обработки запросов, до аутентификации, поэтому неавторизованный атакующий может отправить специально сформированный JSON‑объект и вызвать крах процесса из‑за нехватки памяти. Кроме того, при большом числе строк в запросе подсистема аудита может потреблять значительные ресурсы CPU.\n\nДополнительные технические детали из контекста: был введён новый параметр **max_request_json_complexity** (по умолчанию 10000) — ограничение количества токенов в JSON‑теле запроса, которое используется для оценки потенциального расхода памяти при распаковке. При превышении лимита команда git rejects JSON‑тела, потребляющие слишком много RAM. Также в коде была добавлена проверка и удаление конфликтующих файлов/символических ссылок перед записью LFS‑объектов.\n\nИсточники:\n - [1] https://github.com/openbao/openbao/security/advisories/GHSA-g46h-2rq9-gw5m\n - [2] https://github.com/openbao/openbao/pull/1756\n - [3] https://github.com/openbao/openbao/commit/d418f238bc99adc72c73109faf574cc2b672880c\n - [4] https://github.com/openbao/openbao/blob/788536bd3e10818a7b4fb00aac6affc23388e5a9/http/logical.go#L50
CVE-2025-54996OpenBao предоставляет программное решение для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. В версиях 2.3.1 и ниже учетные записи с доступом к высокопривилегированным системам идентификации сущностей в корневых пространствах имен могли напрямую расширить свои полномочия до корневой политики. Хотя система идентификации всегда позволяла добавлять произвольные политики, которые, в свою очередь, могли содержать гранты возможностей на произвольные пути, корневая политика была ограничена ручным созданием с использованием долей ключей восстановления или unseal. Глобальная корневая политика не была доступна из дочерних пространств имен. Проблема исправлена в версии 2.3.2.
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-vf84-mxrq-crqc
- [2] https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032
CVE-2025-52894OpenBao существует для предоставления программного решения для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. OpenBao до v2.3.0 позволил злоумышленнику выполнить неаудированную, неаудированную отмену корневого реки и операций по восстановлению, что приведет к отказу в обслуживании. В OpenBao v2.2.0 и более поздней версии вручную настройка параметра ``dable_unauthed_rekey_endpoints=true` позволяет оператору отказывать в этих редко используемых конечных точках на глобальных слушателях. Патч доступен на фикф75468822a22a82a88318c6079425357a02ae5b77b. В будущем релизе OpenBao, сообщенном на веб-сайте OpenBao, разработчики настроят это на «правду для всех пользователей» и предоставят аутентифицированную альтернативу. В качестве обходного действия, если активный прокси или балансировщик нагрузки находится перед OpenBao, оператор может отклонить запросы на эти конечные точки из несанкционированных диапазонов IP.
CVE-2026-39396OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.5.3 «ExtractPluginFromImage()` в загрузчике плагина OCI OpenBao извлекает плагин из изображения контейнера, транслируя данные о декомпрессии через `io.Copy` без верхней границы по количеству написанных байтов. Злоумышленник, который контролирует или компрометирующий реестр OCI, упомянутый в конфигурации жертвы, может подавать созданное изображение, содержащее декомпрессионную бомбу, которая декомпрессируется в произвольно большой файл. Проверка целостности SHA256 происходит после того, как полный файл записывается на диск, что означает, что хеш-несоответствие обнаруживается только после того, как повреждение (исчерпание диска) уже произошло. Это позволяет злоумышленнику заменить **законный плагин образ** без необходимости изменять свою подпись. Версия 2.5.3 содержит патч.
CVE-2025-55001OpenBao предоставляет программное решение для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. В версиях 2.3.1 и ниже OpenBao допускал назначение политик и атрибуции MFA на основе псевдонимов сущностей, выбранных основным методом аутентификации. При использовании параметра username_as_alias=true в методе аутентификации LDAP предоставленное пользователем имя использовалось дословно без нормализации, что позволяло злоумышленнику обойти требования MFA, специфичные для псевдонима [1]. Эта проблема была исправлена в версии 2.3.2. Чтобы обойти эту проблему, удалите все использования параметра username_as_alias=true и обновите псевдонимы сущностей соответствующим образом.
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-2q8q-8fgw-9p6p
- [2] https://github.com/openbao/openbao/commit/c52795c1ef746c7f2c510f9225aa8ccbbd44f9fc
- [3] https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092
CVE-2025-55000OpenBao существует для предоставления программного решения для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. В версиях от 0.1.0 до 2.3.1 движок секретов TOTP OpenBao мог принимать действительные коды несколько раз, а не строго один раз. Это было вызвано неожиданной нормализацией в базовой библиотеке TOTP. Для обхода рекомендуется убедиться, что все коды сначала нормализуются перед отправкой в конечную точку OpenBao. Проверка кода TOTP является привилегированной операцией; только доверенные системы должны проверять коды [1].
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-f7c3-mhj2-9pvg
- [2] https://github.com/openbao/openbao/commit/183891f8d535d5b6eb3d79fda8200cade6de99e1
- [3] https://discuss.hashicorp.com/t/hcsec-2025-17-vault-totp-secrets-engine-code-reuse/76036
CVE-2025-62705OpenBao — это система управления секретами на основе идентификации с открытым исходным кодом. До версии 2.4.2 журнал аудита OpenBao не корректно удалял конфиденциальные поля, когда подсистемы передавали параметры ответа в виде []byte вместо строк. В частности, при использовании sys/raw с параметром encoding=base64 все данные выводились в журнал без редактирования, а модуль Transit при подписи с производным ключом Ed25519 записывал открытый ключ в журнал. Уязвимость также могла затронуть сторонние плагины. Проблема известна с периода HashiCorp Vault и сохраняется до версии 1.20.4. Патч, исправляющий проблему, включён в OpenBao 2.4.2; при отсутствии использования указанных функций риск отсутствует, а отключить sys/raw можно установив raw_storage_endpoint=false. Подробности см. в источниках [1] и [2].
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-rc54-2g2c-g36g
- [2] https://github.com/openbao/openbao/commit/cc2c476bac66e1d94776c2629793daec3af625f8
CVE-2025-62513В OpenBao (версии 2.2.0‑2.4.1) журнал аудита записывал необработанные тела HTTP‑запросов без корректного HMAC‑подавления (см. [1]). Это позволяло раскрыть короткоживущие коды проверки ACME и ответы OIDC‑токенов в логах, что может быть использовано для получения конфиденциальных данных (см. [2]). Проблема исправлена в версии 2.4.2; при невозможности обновления рекомендуется отключить функции ACME и OIDC, если они не нужны (см. [1]).
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-ghfh-fmx4-26h8
- [2] https://github.com/openbao/openbao/commit/cc2c476bac66e1d94776c2629793daec3af625f8
CVE-2025-55003OpenBao существует для предоставления программного решения для управления, хранением и распространением конфиденциальных данных, включая секреты, сертификаты и ключи. В версии 2.3.1 и ниже система многофакторной аутентификации (MFA) OpenBao позволяет применять MFA с использованием одноразовых паролей на основе времени (TOTP). Из-за нормализации, применяемой базовой библиотекой TOTP, коды принимались с пробелами, что позволяло обойти внутреннее ограничение скорости метода MFA и повторно использовать существующие коды MFA. Эта проблема была исправлена в версии 2.3.2. Для обхода можно использовать квоты ограничения скорости [1].
Источники:
- [1] https://openbao.org/api-docs/system/rate-limit-quotas/
- [2] https://github.com/openbao/openbao/security/advisories/GHSA-rxp7-9q75-vj3p
- [3] https://github.com/openbao/openbao/commit/8340a6918f6c41d8f75b6c3845c376d9dc32ed19
- [4] https://discuss.hashicorp.com/t/hcsec-2025-19-vault-login-mfa-bypass-of-rate-limiting-and-totp-token-reuse/76038
CVE-2025-54998OpenBao существует для управления, хранения и распространения конфиденциальных данных. В версиях от 0.1.0 до 2.3.1 злоумышленники могли обойти механизмы автоматической блокировки пользователей в системах аутентификации OpenBao Userpass или LDAP. Это было вызвано различиями в псевдонимах между предварительной проверкой и полным запросом входа в систему. Проблема исправлена в версии 2.3.2 [1].
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-j3xv-7fxp-gfhx
- [2] https://github.com/openbao/openbao/commit/c52795c1ef746c7f2c510f9225aa8ccbbd44f9fc
- [3] https://discuss.hashicorp.com/t/hcsec-2025-16-vault-userpass-and-ldap-user-lockout-bypass/76035
CVE-2026-39946OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.5.3, когда OpenBao отменял привилегии на роль в движке секретов базы данных PostgreSQL, OpenBao не использовала правильную цитировку базы данных по именам схем, предоставленным PostgreSQL. Это может привести к сбоям в отзыве ролей или, реже, к инъекции SQL в качестве пользователя управления. Эта уязвимость была оригинальной от HashiCorp Vault. Уязвимость рассматривается в v2.5.3. В качестве обходного раунда схемы таблиц аудита и обеспечение того, чтобы пользователи баз данных не могли создавать новые схемы и предоставлять привилегии на них.
CVE-2025-52893OpenBao существует для предоставления программного решения для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. OpenBao перед v2.3.0 может утечка конфиденциальной информации в журналах при обработке неправильно сформированных данных. Это отдельно от более раннего HCSEC-2025-09 / CVE-2025-4166. Эта проблема была исправлена в OpenBao v2.3.0 и позже. Как и в случае с HCSEC-2025-09, нет никакого известного обходного движения, кроме как для обеспечения правильно отформатированных запросов от всех клиентов.
CVE-2025-54999OpenBao предоставляет программное решение для управления, хранения и распространения конфиденциальных данных, включая секреты, сертификаты и ключи. В версиях 0.1.0 через 2.3.1 при использовании метода аутентификации userpass OpenBao была возможна нумерация пользователей из-за разницы во времени между несуществующими пользователями и пользователями с сохраненными учетными данными. Это было независимо от того, были ли предоставленные учетные данные действительными для данного пользователя [1]. Эта проблема была исправлена в версии 2.3.2. Чтобы обойти эту проблему, пользователи могут использовать другой метод аутентификации или применить квоты ограничения скорости, чтобы ограничить количество запросов за период времени [2].
Источники:
- [1] https://github.com/openbao/openbao/security/advisories/GHSA-hh28-h22f-8357
- [2] https://github.com/openbao/openbao/commit/4d9b5d3d6486ab9fbd5b644173fa0097015d6626
- [3] https://discuss.hashicorp.com/t/hcsec-2025-15-timing-side-channel-in-vault-s-userpass-auth-method/76034
- [4] https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enumeration-in-userpass-auth-method/76095
CVE-2026-42186OpenBao - это система управления секретами с открытым исходным кодом. До 2.5.3, когда первоначальное удаление пространства имен OpenBao терпит неудачу, последующие повторы не могут должным образом удалить все данные, прежде чем пометить пространство имен как удаленное. Это может повлиять на любую непогашенную аренду, а также потенциально оставить несвязанные записи для хранения. Эта уязвимость зафиксирована в 2.5.3.
CVE-2026-40264OpenBao - это система управления секретами с открытым исходным кодом. Пространства имен OpenBao обеспечивают разделение с несколькими арендаторами. До версии 2.5.3 арендатор, который сливает аксессуары токенов, может отозвать или обновить свой токен привилегированным администратором в другом арендаторе. Об этом говорится в пункте v2.5.3.
CVE-2026-39388OpenBao - это система управления секретами с открытым исходным кодом. До версии 2.5.3 метод аутентификации сертификата OpenBao, когда запрашивается продление токена и устанавливается `dable_binding=true`, пытается проверить представленный текущий запрос сертификат mTLS соответствует оригиналу. Продление токенов для других методов аутентификации не требует какой-либо предоставленной информации для входа. Из-за неправильного соответствия метод аутентификации сертификата позволил бы продлить токены, для которых злоумышленник имел сертификат брата + ключ, подписанный тем же CA, но который не обязательно соответствовал первоначальной роли или первоначально предоставленному сертификату. Это означает, что злоумышленник все еще может аутентифицироваться на OpenBao в аналогичном объеме, однако продление токена подразумевает, что злоумышленник может продлить срок службы динамической аренды, удерживаемой оригинальным токеном. Эта атака требует знания либо оригинального токена, либо его аксессуара. Эта уязвимость является оригинальной от HashiCorp Vault. Об этом говорится в v2.5.3. В качестве обходного пути убедитесь, что привилегированные роли тесно связаны с едиными сертификатами.