Tydzień po security release warto sprawdzić, czy… nie ma kolejnego security release naprawiającego poprzedni. CVE-2026-59843 w libssh to dokładnie taki przypadek. Projekt oznaczył podatność jako naprawioną w 0.12.1, ale — jak sam napisał w nocie do 0.12.2 — „udało nam się przeoczyć jeden z fixów dla CVE-2026-59843”. Wersja 0.12.2 (oraz 0.11.5 w starszej gałęzi) to fixup release dowożący brakujący commit.
Dlaczego to ważne dla VM, mimo że to „tylko DoS”
Sedno nie leży w severity. Leży w tym, że przez okno między 0.12.1 a 0.12.2 istniała wersja, którą feedy i skanery traktowały jako naprawioną, a która nie zawierała poprawki. Każdy finding CVE-2026-59843 zamknięty w tym oknie na podstawie reguły „zainstalowano ≥ 0.12.1 → Patched” był zamknięty przedwcześnie. To ten sam mechanizm, co przy pominiętym fiksie OpenSSL w Ubuntu — inny vendor, ta sama klasa błędu procesu.
Version-based closure ma wbudowane założenie
Reguła installed_version >= fixed_version → closed zakłada, że „fixed_version” jest prawdą binarną. Ale „fixed_version” pochodzi z advisory, a advisory to oświadczenie, które zależy od jakości release engineeringu vendora: czy właściwy commit wszedł do tagu, czy backport objął wszystkie ścieżki, czy tag odpowiada temu, co faktycznie zbudowano. Gdy któreś z tych ogniw pęka, numer wersji nadal mówi „fixed”, a kod mówi „vulnerable”.
Vendor release quality to zmienna, nie stała
Warto traktować jakość wydania vendora jako sygnał ryzyka. Projekt, który w ciągu tygodnia publikuje fixup do własnego security release, właśnie pokazał, że jego pierwsze „fixed in” bywa niekompletne. To nie oskarżenie — libssh zachował się wzorowo, jawnie komunikując pomyłkę i szybko dowożąc 0.12.2. Ale dla konsumenta advisory wniosek jest praktyczny: dla tej rodziny pakietów krótkie okno weryfikacji przed twardym zamknięciem findingu jest uzasadnione.
Jak walidować remediation, nie tylko wersję
- Sprawdzaj follow-up releases. Zanim zamkniesz na stałe, upewnij się, że nie ma nowszego patch/fixup dla tego samego CVE (0.12.2, 0.11.5).
- Wiąż CVE z commitem, nie tylko z tagiem. Jeśli advisory wskazuje konkretny commit, można sprawdzić jego obecność w zbudowanej wersji.
- Dla realnie eksploatowalnych ścieżek — test zachowania. Tu: czy serwer/klient nadal wywraca się na zero-sized advertised packet.
- Zachowaj proweniencję. „Zamknięto na podstawie 0.12.1” pozwala masowo re-otworzyć, gdy okaże się, że dopiero 0.12.2 realnie naprawia.
Status pośredni: „naprawa deklarowana, niezweryfikowana”
Zamiast binarnego OPEN → PATCHED pomocny bywa stan pośredni:
To dokładnie ten status, który po wyjściu 0.12.2 automatycznie zamienia się w „re-triage”: podnieś wersję do 0.12.2/0.11.5, potem zamknij.
Co powinien zrobić Vulnerability Engineer?
- Zinwentaryzuj, gdzie libssh jest używane (klienci SSH, biblioteki aplikacji, obrazy kontenerów, embedded).
- Docelowo podnieś do
0.12.2(gałąź 0.12) lub0.11.5(gałąź 0.11), nie tylko 0.12.1. - Re-otwórz findingi CVE-2026-59843 zamknięte na podstawie 0.12.1.
- Dodaj regułę: dla tej rodziny pakietów nie zamykaj po pierwszym „fixed in” bez sprawdzenia follow-up.
Wniosek
libssh 0.12.2 to mały incydent z dużą lekcją: „fixed in” to deklaracja, a nie dowód. Remediation walidujemy nie samym numerem wersji, lecz obecnością poprawki i — dla ścieżek, na których to się opłaca — zachowaniem. Gdy vendor tydzień później wydaje fixup, to nie anomalia do zignorowania, tylko sygnał, że version-based closure trzeba czasem cofnąć. Pytanie brzmi: czy zamknęliśmy finding, bo ryzyko zniknęło, czy tylko dlatego, że numer wersji się zgadzał?
Powiązane na blogu
- OpenSSL „załatany”, a fix nie trafił do paczki — ta sama klasa błędu u innego vendora
- JetBrains i remediation failure — „ticket closed” ≠ „risk closed”
Źródła
- libssh — 0.12.2 security release (28.07.2026) — libssh.org
- CVE-2026-59843 — cve.org
Nota redakcyjna: stan informacji 31 sierpnia 2026. libssh w nocie do 0.12.2 wskazuje, że jeden z commitów dla CVE-2026-59843 został przypadkowo pominięty w 0.12.1; poprawkę dowożą 0.12.2 oraz 0.11.5. Artykuł koncentruje się na walidacji remediation, nie na eksploatacji DoS.