CVE-2026-59847 w libssh to podatność na integralność szyfrowania SSH: przez błędną weryfikację wartości zwracanej przez EVP_DecryptFinal() AES-GCM degraduje się do AES-CTR — bez dodatkowych kontroli integralności. Atakujący zdolny do modyfikacji ruchu może zmieniać dane w locie (flipping bitów w oparciu o spodziewany format pakietów), co dotyczy zarówno klienta, jak i serwera. Ale jest jeden warunek, który zmienia wszystko dla VM: błąd dotyczy wyłącznie buildów używających backendu kryptograficznego OpenSSL.
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L).Nazwa i wersja to nie cała tożsamość pakietu
Klasyczne SCA identyfikuje komponent po nazwie i wersji: „libssh 0.11.x → podatne na CVE-2026-59847”. Ale libssh można zbudować z różnymi backendami kryptograficznymi. Build z OpenSSL jest podatny; build z innym backendem — nie, bo błąd tkwi w obsłudze konkretnego API OpenSSL (EVP_DecryptFinal()). Ta sama nazwa, ta sama wersja, różna tożsamość bezpieczeństwa — zależnie od flag kompilacji.
Compile-time feature jako warunek exploitability
To ta sama klasa co „podatne tylko z DoQ” w Unbound: sama wersja nie rozstrzyga, bo o osiągalności decyduje, jak i z czym pakiet skompilowano. Dla libssh pytanie brzmi: który crypto backend? Odpowiedź nie jest w numerze wersji — jest w metadanych builda, konfiguracji pakietu dystrybucji albo w tym, z czym zlinkowano aplikację.
Ryzyko: false urgency i (rzadziej) false comfort
SCA po samej nazwie i wersji wygeneruje Critical/High dla każdego wystąpienia libssh w podatnym zakresie — także tam, gdzie build nie używa OpenSSL i realnie nie jest podatny. To false urgency: zawyżony priorytet, zmarnowana praca, szum. Odwrotny błąd też jest możliwy: jeśli ktoś założy „u nas libssh jest z innym backendem” bez sprawdzenia, a część buildów jednak używa OpenSSL — powstaje false comfort. Jak zawsze przy reachability: dowód działa w obie strony.
Jak ustalić backend?
- Pakiety dystrybucji: zwykle budowane z konkretnym backendem — sprawdź, jak dana dystrybucja kompiluje libssh (w praktyce często OpenSSL).
- Aplikacje statycznie linkujące libssh: zależy od ich builda — trzeba spojrzeć na zależności i flagi.
- Obrazy kontenerów: to, z czym zbudowano bazowy obraz; SBOM z informacją o backendzie jest tu bezcenny.
Wniosek praktyczny: SBOM powinien nieść nie tylko „libssh 0.11.4”, ale i wariant builda, jeśli to on decyduje o podatności.
Co powinien zrobić Vulnerability Engineer?
- Zinwentaryzuj wystąpienia libssh (pakiety, aplikacje linkujące, obrazy) i wersje.
- Dla każdego ustal crypto backend — priorytet mają buildy z OpenSSL.
- Podnieś do 0.12.1 / 0.11.5 (właściwa gałąź) tam, gdzie backend to OpenSSL.
- Dla buildów z innym backendem oznacz
NOT_AFFECTED: build_variant_not_vulnerablez dowodem, nie z założenia. - Zadbaj, by SBOM/inwentarz zapisywał wariant builda dla komponentów, w których to on decyduje o exploitability.
Wniosek
CVE-2026-59847 to przypomnienie, że „nazwa + wersja” bywa niepełną tożsamością komponentu. Dla libssh o podatności decyduje crypto backend, z jakim bibliotekę zbudowano — build z OpenSSL jest podatny, inne nie. SCA, które tego nie widzi, produkuje false urgency i szum. Dojrzały proces traktuje wariant builda jako część kontekstu osiągalności i zapisuje go w SBOM. Pytanie brzmi nie „jaką wersję libssh mamy?”, tylko: z jakim backendem ją zbudowano — bo dopiero to rozstrzyga, czy ten CVE nas dotyczy?
Powiązane na blogu
- Unbound: podatny tylko z DoQ i quic-port — compile-time feature i runtime config jako warunek
- containerd w SBOM, ale nieuruchomiony — obecność ≠ osiągalność
Źródła
- libssh — advisory CVE-2026-59847 — libssh.org
- CVE-2026-59847 — cve.org
Nota redakcyjna: stan informacji 31 sierpnia 2026. CVE-2026-59847 (CVSS 6.5) dotyczy libssh ≥ 0.9.0 przed 0.12.1/0.11.5; błąd weryfikacji EVP_DecryptFinal() degraduje AES-GCM do AES-CTR bez integralności, dla klienta i serwera, wyłącznie w buildach z backendem OpenSSL. Poprawki: 0.12.1 i 0.11.5.