Nikt nie ukradł kluczy. Sejf je udostępnił.

Członek Państwa zespołu o niskich uprawnieniach mógłby wynieść klucze sejfu całej organizacji. Nie jedno współdzielone hasło. Same klucze.

To CVE-2026-60104, ujawnione w tym tygodniu w samodzielnie hostowanym Bitwarden Server [1]. Publicznie dostępny jest działający dowód koncepcji, a zespoły reagowania we Włoszech i w Belgii wydały ostrzeżenia [2][3]. Poprawka ukazała się szybko, w wersji 2026.6.0, a klienci chmurowi @Bitwarden nie byli nigdy narażeni. Jeśli prowadzą Państwo własny serwer — łatają Państwo dzisiaj.

Poprawka to łatwa część. Historia dotyczy leżącego pod nią projektu.

Luka znajduje się w funkcji o nazwie Trusted Device Enrollment. TDE istnieje z naprawdę dobrego powodu: pozwala zalogować się na nowym laptopie bez ponownego wpisywania hasła głównego. Urządzenie, które już Państwo darzą zaufaniem, albo administrator zatwierdza nowe, a klucz szyfrujący konta jest do niego dostarczany. Wygodne. Nawet humanitarne w zespole, który co tydzień wdraża nowe osoby.

Proszę to przeczytać jeszcze raz. Klucz szyfrujący konta jest dostarczany. Cała funkcja opiera się na jednym założeniu: klucz sejfu można przekazać z jednej strony drugiej, gdy zatwierdzi to właściwa strona. CVE-2026-60104 to skutek sytuacji, w której członek o niskich uprawnieniach podchodzi do tej ścieżki zatwierdzania i prosi o klucze, które nigdy nie były jego. Kryptografia nie zawiodła. System zrobił dokładnie to, do czego został zbudowany. Udostępnił.

@Bitwarden nie zaniedbał tu niczego. Poprawka wyszła w jeden dzień, a ich użytkownicy zarządzani niczego nie odczuli. Lekcja jest trudniejsza niż błąd: w chwili gdy klucz może być z założenia deponowany, istnieje ścieżka, by nakłonić depozyt do działania. Każdy przepływ zatwierdzania jest powierzchnią ataku, bo każdy przepływ zatwierdzania jest z definicji sposobem na przeniesienie klucza do nowej osoby.

Zbudowaliśmy więc odwrotne założenie.

W Clavitor klucz sejfu nie jest sekretem, który serwer przechowuje i wydaje. Jest wynikiem działania Państwa klucza sprzętowego, powstaje tylko wtedy, gdy fizycznie go Państwo dotkną. Operator nigdy nie przechowuje formy tego klucza, która mogłaby cokolwiek odszyfrować, więc na serwerze nie ma nic do wydania. Nie ma przepływu zatwierdzania przez administratora, który dostarcza klucz sejfu, bo nie ma klucza po stronie serwera do dostarczenia. Jeden członek nie może poprosić o sejf drugiego, bo żadna ścieżka żądania nie kończy się kluczem. Każde odblokowanie jest związane z urządzeniem, które je wykonało, i zapisane w śladzie audytowym z nazwą aktora.

Uczciwie: nadal można dodać drugie urządzenie. Gdy to Państwo zrobią, klucz jest ponownie opakowywany dla nowego klucza sprzętowego. Wymaga to jednak dotknięcia klucza, który już Państwo mają, a nie zatwierdzenia, które obca osoba może wyłudzić przez formularz. Klucz nigdy nie leży w miejscu, z którego przepływ mógłby go oddać.

To cała różnica. Sejf, który potrafi dostarczyć klucz, można nakłonić, by dostarczył go niewłaściwej osobie. Sejf, który otwiera się tylko na sprzęt w Państwa dłoni, nie ma nic do dostarczenia.

Zapisaliśmy krótką listę rzeczy, których narzędzie do poświadczeń nigdy nie powinno robić. Przechowywanie klucza, o którego wydanie można poprosić, jest blisko jej szczytu. [4]

Clavitor (@clavitorai) to sejf na poświadczenia zbudowany dla agentów AI — i przeciwko nim. clavitor.ai

---

Źródła

CVE-2026-60104, wpis w National Vulnerability Database. Ominięcie uwierzytelniania w samodzielnie hostowanym Bitwarden Server, naprawione w 2026.6.0. [1]

CSIRT Italia (@csirt_it), komunikat: publiczny PoC dla CVE-2026-60104, sklasyfikowany jako Security Restrictions Bypass i Information Leakage. [2]

Centre for Cybersecurity Belgium (@CCBalert), ostrzeżenie: ominięcie uwierzytelniania pozwala członkowi organizacji o niskich uprawnieniach kraść sejfy innych użytkowników, CVSS 9.3, aktualizacja do v2026.6.0+. [3]

Dziesięć zasad zarządzania poświadczeniami (@clavitorai). [4]