CVE-2026-13204 w BIND to pozornie prosta historia: ISC oznacza całą gałąź 9.18 jako End-of-Life i wskazuje poprawkę w 9.20.26. Z tego łatwo wyciągnąć wniosek „9.18 jest martwe, trzeba migrować na 9.20”. Tyle że 31 sierpnia 2026 Ubuntu dostarczyło backport do 9.18.39 dla 24.04 LTS i 22.04 LTS (USN-8696-1). Ten sam CVE, dwa różne cykle życia — upstreamu i pakietu dystrybucji.
1:9.18.39-0ubuntu0.24.04.7 (24.04), 1:9.18.39-0ubuntu0.22.04.6 (22.04).Dwa różne pojęcia „końca życia”
„EOL” znaczy co innego dla upstreamu i dla dystrybucji. Dla ISC koniec życia gałęzi 9.18 znaczy „nie wydajemy już 9.18.x; przejdźcie na 9.20”. Dla Ubuntu ta sama gałąź jest nadal wspierana w ramach LTS — dystrybucja utrzymuje własny strumień, backportując poprawki do 9.18.x tak długo, jak długo trwa wsparcie dla danego wydania. Innymi słowy: numer wersji upstream nie mówi całej prawdy o tym, czy pakiet jest utrzymywany.
Dlaczego to pułapka dla VM
Automatyka VM lubi dwa skróty, które tu prowadzą do błędu:
- „Wersja < fix upstream (9.20.26) → podatne, migruj” — pomija fakt, że backport 9.18.39 też zamyka CVE. Administrator, który podniósł do 9.18.39, jest naprawiony, choć nie osiągnął 9.20.26.
- „Gałąź EOL → nie do załatania, akceptuj ryzyko / wymień komponent” — fałszywe, jeśli dystrybucja nadal backportuje. To generuje niepotrzebne migracje i wyjątki.
Oba wynikają z porównywania do upstream lifecycle zamiast do vendor package lifecycle.
Właściwy klucz: „fixed” per strumień
Ten sam CVE ma różne „fixed version” w różnych strumieniach dystrybucyjnych:
VM powinien porównywać zainstalowany pakiet do „fixed version dla właściwej dystrybucji i wydania”, a nie do jednej liczby upstream. To rutyna dla dobrze zrobionych feedów dystrybucyjnych — ale łatwo ją zgubić, gdy ktoś normalizuje wszystko do wersji upstream albo czyta samo advisory ISC.
Kiedy EOL naprawdę jest findingiem?
To nie znaczy, że EOL nie ma znaczenia. Ma — ale trzeba wiedzieć, czyj to EOL. Jeśli EOL jest zarówno u upstreamu, jak i u dystrybucji (albo używasz komponentu spoza repozytoriów dystrybucji), wtedy brak przyszłych poprawek jest realnym ryzykiem i sam bywa findingiem — tak jak przy martwym upstreamie Uptrain. Różnica: BIND 9.18 w Ubuntu nie jest w tym stanie, bo dystrybucja wciąż go utrzymuje.
Co powinien zrobić Vulnerability Engineer?
- Ustal, skąd pochodzi BIND na hoście: pakiet dystrybucji czy build upstream/własny.
- Dla pakietów dystrybucji porównuj do „fixed version” tej dystrybucji (Ubuntu: 9.18.39-…), nie do 9.20.26.
- Nie oznaczaj hosta jako „EOL, nie do załatania” wyłącznie na podstawie EOL upstreamu.
- Śledź lifecycle pakietu vendora — kiedy dystrybucja przestanie backportować, wtedy EOL staje się realnym findingiem i argumentem za migracją do 9.20.
Wniosek
BIND 9.18 pokazuje, że „EOL” bez podmiotu jest mylące. Upstream może porzucić gałąź, którą dystrybucja nadal utrzymuje — i wtedy poprawka przychodzi jako backport (9.18.39), a nie jako migracja do 9.20.26. Dojrzały VM rozróżnia lifecycle upstreamu od lifecycle vendor package, porównuje wersje w obrębie właściwego strumienia i rezerwuje „EOL jako finding” na sytuacje, w których to dystrybucja przestaje wspierać komponent. Pytanie brzmi nie „czy upstream porzucił tę gałąź?”, tylko: czy strumień, z którego bierzemy ten pakiet, nadal dostarcza poprawki?
Powiązane na blogu
- Uptrain: EOL jako finding — kiedy brak utrzymania naprawdę jest ryzykiem
- ABRT: usuń zamiast łatać — gdy najlepszą remediation jest eliminacja komponentu
Źródła
- Ubuntu Security Notice USN-8696-1 — BIND 9 (CVE-2026-13204), 31.08.2026 — ubuntu.com
- ISC — BIND 9 software lifecycle / CVE-2026-13204 — isc.org
Nota redakcyjna: stan informacji 31 sierpnia 2026. Ubuntu (USN-8696-1) dostarczyło backport 9.18.39 dla 24.04/22.04 dla CVE-2026-13204 (błąd walidacji DNSSEC przy współistnieniu NSEC i NSEC3 z RRSIG tylko jednego typu). ISC oznacza gałąź 9.18 jako EOL i wskazuje fix w 9.20.26. Deklarację ISC o EOL i wersji 9.20.26 należy potwierdzić w komunikacji ISC.