Ніхто не вкрав ключі. Сховище поділилося ними.
Уразливість CVE у самостійно розгорнутому Bitwarden дозволила учаснику з низькими правами винести ключі сховища всієї організації. Криптографія не дала збою. Сховище, здатне передати ключ новому учаснику, можна змусити це зробити.
Учасник вашої команди з низькими правами міг би винести ключі сховища всієї організації. Не один спільний обліковий запис. Самі ключі.
Це CVE-2026-60104, розкритий цього тижня в самостійно розгорнутому Bitwarden Server [1]. Робочий proof-of-concept оприлюднено, а національні команди реагування Італії та Бельгії обидві видали сповіщення [2][3]. Виправлення вийшло швидко, у версії 2026.6.0, а клієнти хмарної служби @Bitwarden не були вразливими. Якщо ви ведете власний сервер — оновлюйте сьогодні.
З латкою все просто. Історія — у проєктуванні під нею.
Вразливість міститься у функції Trusted Device Enrollment (реєстрація надійного пристрою, TDE). TDE існує з поважної причини: вона дозволяє ввійти на новому ноутбуці, не вводячи вдруге головний пароль. Пристрій, якому ви вже довіряєте, або адміністратор підтверджує новий, і ключ шифрування облікового запису передається йому. Зручно. Навіть гуманно для команди, що щотижня підключає нових людей.
Перечитайте ще раз. Ключ шифрування облікового запису передається. Уся функція тримається на одному припущенні: ключ сховища можна передати від однієї сторони іншій, коли належна сторона це схвалює. CVE-2026-60104 — це те, що стається, коли учасник із низькими правами підходить до цього ланцюжка погодження і просить ключі, які йому ніколи не належали. Криптографія не дала збою. Система зробила саме те, для чого її створено. Вона поділилася.
@Bitwarden тут не знехтували безпекою. Виправлення вийшло за день, і користувачі їхньої керованої служби цього не відчули. Урок складніший за ваду: щойно ключ за проєктуванням може зберігатися в посередника, з'являється шлях обдурити цього посередника. Кожен ланцюжок погодження — це поверхня атаки, бо кожен ланцюжок погодження за визначенням є способом передати ключ новій людині.
Тому ми заклали протилежне припущення.
В Clavitor ключ сховища — не секрет, який сервер тримає й роздає. Це вихід вашого апаратного ключа, що утворюється лише тоді, коли ви фізично торкаєтеся його. Оператор ніколи не зберігає форми цього ключа, здатної щось розшифрувати, тож на сервері немає чого видавати. Немає ланцюжка адміністраторського погодження, який передавав би ключ сховища, бо немає ключа на боці сервера для передавання. Один учасник не може запросити сховище іншого, бо жоден шлях запиту не завершується ключем. Кожне розблокування прив'язане до пристрою, який його виконав, і записане в журналі аудиту з зазначенням виконавця.
Чесне застереження: другий пристрій додати все одно можна. Коли ви це робите, ключ перепаковується для нового апаратного ключа. Але для цього потрібне торкання ключа, який ви вже тримаєте, а не погодження, яке стороння людина може випросити в заявці. Ключ ніколи не лежить там, звідки робочий процес міг би його віддати.
У цьому вся різниця. Сховище, здатне передати ключ, можна переконати передати його не тій людині. Сховище, що відкривається лише апаратному ключу у вашій руці, не має чого передавати.
Ми склали короткий перелік того, чого інструмент для облікових даних ніколи не повинен робити. Тримати ключ, який у нього можуть попросити віддати, — десь біля верхівки списку. [4]
Clavitor (@clavitorai) — сховище облікових даних, створене для ШІ-агентів, і проти них. clavitor.ai
---
Джерела
CVE-2026-60104, запис у National Vulnerability Database. Обхід автентифікації в самостійно розгорнутому Bitwarden Server, виправлено у 2026.6.0. [1]
CSIRT Italia (@csirt_it), консультація: відкритий PoC для CVE-2026-60104, класифіковано як Security Restrictions Bypass та Information Leakage. [2]
Centre for Cybersecurity Belgium (@CCBalert), сповіщення: обхід автентифікації дозволяє учаснику організації з низькими правами викрасти сховища інших користувачів, CVSS 9.3, оновлення до v2026.6.0+. [3]
Десять правил керування обліковими даними (@clavitorai). [4]