Strona główna / Blog / OpenVPN: supported ≠ patched

Blog · analiza

OpenVPN 2.6 jest wspierane do 2028, ale świeży CVE-2026-84732 naprawiono tylko w 2.7.7. Kiedy „supported” nie znaczy „currently fixed”

CVE-2026-84732 dotyczy reliability layer OpenVPN: bezgraniczne zwiększanie retransmission timeout w reliable TLS control channel oraz akceptowanie ACK-ów dla pakietów, które nie mogą być outstanding — skutek to DoS control channel. Affected: 2.6.22 i 2.7.6. Fixed: tylko 2.7.7. Na pierwszy rzut oka: „upgrade do 2.7.7”. Problem zaczyna się przy support policy.

CVE-2026-84732: DoS control channel (unbounded retransmission timeout + błędna akceptacja ACK).
Affected: 2.6.22, 2.7.6. Fixed: 2.7.7 (brak fixa w linii 2.6).
Lifecycle: 2.7 current stable; 2.6 old-stable (zmiana typu wsparcia VIII.2027, EOL VIII.2028) — nie EOL.

Supported nie jest tym samym co patched

W CMDB często jest uproszczone pole support_status = supported traktowane jak sygnał niskiego ryzyka. Tymczasem potrzebne są dwa wymiary:

lifecycle_status = supported security_fix_available_on_current_branch = no/unknown

Organizacja może całkowicie poprawnie stać na wspieranej 2.6 i nie robić major migration bez change window — a jednocześnie świeży advisory mówi „2.6.22 affected; fix w 2.7.7”. Brak EOL nie gwarantuje istnienia patcha bez migracji gałęzi. I nie zgaduj, że 2.6.23 „na pewno” powstanie — to zadanie VE: rozróżnić fakty od oczekiwań.

„fixed version” w feedzie może wprowadzać w błąd

SCA zwróci fixedVersion: 2.7.7, a system ticketowy wygeneruje „upgrade package to 2.7.7”. Technicznie poprawne, operacyjnie to zmiana gałęzi, nie zwykły security patch. Warto mieć osobne pole:

remediation_type: patch_within_branch | minor_upgrade | major_branch_migration | config_mitigation | vendor_wait

2.7.7 naprawia więcej niż jeden problem

Release 2.7.7 zawiera pakiet fixów (m.in. Windows: command-line quoting, binary planting przez netsh.exe, NULL DACL, memory-safety). Migracja może zamknąć kilka findings naraz, ale i zmienić zachowanie produktu — argument za traktowaniem release jako remediation unit, nie zawsze pojedynczego CVE. Po wdrożeniu potwierdź runtime: wersja procesu = 2.7.7, restart usługi, brak starego procesu w pamięci, wczytana konfiguracja, sprawny control channel.

Czy brak patcha w gałęzi uzasadnia wyjątek?

Sam w sobie nie. Dobry risk acceptance zawiera: dlaczego migracja nie jest teraz możliwa, biznesowy impact DoS, czy endpoint jest publiczny, jakie controls ograniczają atak, deadline ponownej oceny i trigger (publikacja 2.6.x fix lub zmiana vendor guidance). To conditional exception, nie trwałe „accepted”.

Wniosek

CVE-2026-84732 pokazuje praktyczną pułapkę: produkt bywa oficjalnie wspierany, a dla świeżej podatności nie ma jeszcze fixed release w używanej gałęzi. supported i remediable without branch migration to dwa różne stany — i właśnie w tej różnicy zaczynają się decyzje operacyjne.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 7 września 2026. CVE-2026-84732 (OpenVPN, DoS control channel): affected 2.6.22/2.7.6, fixed tylko 2.7.7; linia 2.6 wspierana do 2028, ale bez fixa bez migracji gałęzi. Artykuł koncentruje się na rozróżnieniu „supported” od „currently fixed” i typie remediacji.

Zapamiętaj jedno

Produkt może być nadal oficjalnie wspierany, ale dla konkretnej świeżej podatności nie mieć jeszcze opublikowanego fixed release w używanej gałęzi. „supported” i „remediable without branch migration” to dwa różne stany — dojrzały VE je rozdziela, bo właśnie tam zaczynają się prawdziwe decyzje operacyjne.