OpenSSL 25 sierpnia 2026: dziewięć luk w QUIC, CMS, CMP, DTLS i AEAD
Trzy luki Moderate i sześć Low obejmują podwójne zwolnienie, heap overflow, DoS i pominięcie tagu AEAD. Analiza ekspozycji oraz wersji 4.0.2–3.0.22.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 25 sierpnia 2026
- CZAS CZYTANIA
- 20 min czytania
- TEMAT
- Podatności i CVE
OpenSSL opublikował 25 sierpnia zbiorczy komunikat obejmujący dziewięć podatności. Trzy otrzymały wagę Moderate, a sześć Low według skali projektu. Problemy znajdują się w różnych warstwach: serwerze QUIC, odszyfrowywaniu CMS, obsłudze CMP, Raw Public Keys, buforowaniu DTLS oraz jednorazowym API AEAD. Nie istnieje więc jeden test „czy TLS działa”, który odpowie, czy aplikacja jest bezpieczna.
Poprawione wersje wspieranych gałęzi to OpenSSL 4.0.2, 3.6.4, 3.5.8, 3.4.7 i 3.0.22. Klienci premium utrzymujący starsze linie otrzymali 1.1.1zi i 1.0.2zr dla problemów, które ich dotyczą. OpenSSL 3.1, 3.2 i 3.3 są poza wsparciem i nie zostały przeanalizowane; brak ich na liście nie oznacza odporności.
Trzy podatności Moderate
CVE-2026-18798 dotyczy serwera QUIC w liniach 4.0, 3.6 i 3.5. Podczas obsługi pakietu INITIAL kod tworzy obiekt QRX do walidacji. Jeśli tworzenie kanału nie powiedzie się po przekazaniu własności obiektu, jedna ścieżka zwalnia QRX, a późniejsza obsługa błędu robi to ponownie. Zdalny peer może wywołać warunek niezgodnym pakietem INITIAL z DCID krótszym niż osiem bajtów. Podwójne zwolnienie uszkadza stertę i zwykle kończy proces; projekt uważa RCE za wysoce nieprawdopodobne i nie ma na nie dowodów.
CVE-2026-63072 obejmuje CMS_decrypt() w liniach 4.0, 3.6, 3.5, 3.4, 3.0 i 1.1.1. Atakujący może zmienić OID algorytmu key-wrap tak, aby wybrać wariant AES-WRAP-PAD. Kod pytał o rozmiar rozpakowanego klucza i na tej podstawie alokował bufor, lecz prymityw padded unwrap podczas błędu integralności mógł zapisać i wyczyścić o osiem bajtów więcej. Skutek to deterministyczny, ośmiobajtowy zapis zer tuż za stertą i zwykle DoS. Oficjalny opis nie przypisuje mu RCE.
CVE-2026-63076 dotyczy CMP z ochroną hasłową w liniach 4.0–3.0. Weryfikacja protectionAlg sprawdzała, czy wskaźnik parametru nie jest pusty, ale nie weryfikowała jego typu ASN.1 przed potraktowaniem go jako PBMParameter. Spreparowana wiadomość może spowodować dereferencję niepoprawnego wskaźnika przed obliczeniem MAC. Serwer CMP akceptujący PBM może zostać zdalnie wyłączony bez znajomości sekretu; klient może zostać zaatakowany przez złośliwy lub przechwycony endpoint. Wiarygodnym skutkiem jest crash, bez ujawnienia pamięci i bez ścieżki do wykonania kodu.
Sześć problemów Low, które nadal wymagają kontekstu
CVE-2026-14457 wywołuje NULL dereference w konfiguracji RFC 7250 Raw Public Keys, gdy lokalnie ustawiono tylko klucz prywatny bez odpowiadającego certyfikatu, a peer żąda RPK i wysyła zwykle pomijane rozszerzenie signature_algorithms_cert. Dotyczy 4.0–3.4 i kończy się DoS. Konfiguracja z pasującym certyfikatem nie wchodzi w tę ścieżkę.
CVE-2026-54874 wykorzystuje buforowanie rekordów DTLS z przyszłej epoki podczas handshake’u. Mały rekord zatrzymywał cały bufor odczytu o rozmiarze około 16 KB, a do stu rekordów mogło pozostać na połączenie. OpenSSL szacuje około 1,7 MB retencji oraz współczynnik amplifikacji pamięci około 1200 względem ruchu atakującego. Limit jest per połączenie, lecz wiele asocjacji może wyczerpać pamięć. Problem obejmuje linie od 4.0 aż do 1.0.2.
CVE-2026-63073 jest format stringiem w kliencie CMP. Nazwa wyróżniona nadawcy z odpowiedzi trafiała do ERR_raise_data() jako format, a znaki % pozostawały aktywne. Złośliwy lub przechwycony serwer może wyłączyć klienta, który sprawdza oczekiwanego nadawcę albo ma przypięty certyfikat. Projekt wyraźnie wyklucza wiarygodny kontrolowany zapis i RCE. Podatne są 4.0–3.4.
CVE-2026-63074 dotyczy długowiecznego OSSL_CMP_CTX. Dodatkowe certyfikaty extraCerts z odrzuconej wiadomości pozostawały w niezaufanym stosie kontekstu. Powtarzane żądania z unikalnymi certyfikatami mogły powodować nieograniczony wzrost pamięci serwera. Poprawka usuwa obiekty dodane przez odrzuconą wiadomość. Zakres obejmuje 4.0–3.0.
CVE-2026-63075 dotyczy historii pakietów QUIC. Peer, który ukończy handshake, może wymuszać odpowiedzi ACK-only, wysyłając pakiety wywołujące ACK i nie potwierdzając później danych. Metadane pakietów ACK-only pozostawały do końca połączenia, choć protokół nie wymaga potwierdzania takich pakietów. Długie lub liczne sesje prowadzą do wzrostu pamięci. Podatne są 4.0–3.4.
CVE-2026-75803 różni się od pozostałych, bo dotyczy integralności. Przy odszyfrowywaniu pustego ciphertextu ChaCha20-Poly1305 lub AES-OCB przez jednorazowe EVP_Cipher() funkcja mogła zwrócić sukces bez sprawdzenia tagu AEAD. Aplikacja ufająca kodowi zwrotnemu mogła zaakceptować sfałszowaną pustą wiadomość. Problem obejmuje 4.0–3.0; nie dotyczy modułów FIPS, ponieważ te algorytmy nie są w nich zaimplementowane.
„FIPS impact: no” nie oznacza, że aplikacja może pominąć update
Każda sekcja advisory wskazuje brak wpływu na moduł FIPS, ale z różnych powodów. QUIC, TLS, DTLS, CMS i CMP znajdują się poza granicą modułu kryptograficznego; ChaCha20-Poly1305 oraz AES-OCB nie są algorytmami FIPS w opisanych modułach. Aplikacja korzystająca z providera FIPS nadal może wywoływać podatny kod protokołu w bibliotece OpenSSL.
Zgodność modułu mówi, co znajduje się w zweryfikowanej granicy kryptograficznej, a nie że cały proces jest odporny na błędy pamięci. Zespół powinien sprawdzić, czy używa CMP, CMS, QUIC lub DTLS, niezależnie od obecności konfiguracji FIPS. Wyjątkiem jest konkretna ścieżka AEAD, której algorytmy nie są dostępne w samym module FIPS.
Jak ustalić rzeczywistą ekspozycję
Zacznij od wersji ładowanej w runtime. Polecenie narzędzia systemowego może pokazać inną bibliotekę niż ta dołączona statycznie do serwera, agenta lub urządzenia. Kontenery mogą zawierać kilka kopii przez system pakietów, Python, Node, Java JNI albo vendor bundle. Zmapuj każdy proces do konkretnego pliku biblioteki i sprawdź, czy dostawca dystrybucji zastosował backport.
Numer wersji dystrybucyjnej nie zawsze rośnie do upstreamowego 3.0.22. Debian, Ubuntu, Red Hat i producenci appliance’ów często przenoszą poprawkę do starszego pakietu, zachowując bazowy numer z sufiksem. Decyzję opieraj na advisory dostawcy i identyfikatorze paczki, nie na prostym porównaniu stringów.
Następnie oceń funkcje. Publiczny serwer HTTP/3 może wejść w ścieżki QUIC, brama IoT korzystać z DTLS, system PKI z CMP, a aplikacja szyfrująca dokumenty z CMS. Proces, który używa tylko klasycznego TLS 1.3, nie jest automatycznie osiągalny przez każdą z dziewięciu luk, choć nadal powinien otrzymać wspieraną wersję biblioteki.
Kolejność aktualizacji i testy
Priorytetem są publiczne serwery QUIC, endpointy DTLS z dużą liczbą asocjacji, usługi odszyfrowujące nieufne CMS oraz serwery CMP dostępne bez zaufanej warstwy sieciowej. Dalej aktualizuj klienty CMP, aplikacje RPK i systemy używające jednorazowego EVP_Cipher() dla AEAD. Skala wdrożenia OpenSSL sprawia, że nawet luka Low może mieć wysoki koszt operacyjny w konkretnym komponencie.
Po aktualizacji przetestuj handshake’y, renegocjację konfiguracji aplikacji, HTTP/3, odtwarzanie sesji DTLS, operacje CMS i enrollment CMP. Sprawdź również restart procesów: wymiana pakietu na dysku nie aktualizuje biblioteki już zmapowanej do pamięci. W przypadku static linking trzeba przebudować i wdrożyć aplikację.
Nie szukaj jednego uniwersalnego IOC. Większość problemów prowadzi do crashu lub zużycia pamięci, więc koreluj restarty, OOM, błędy protokołu i wzrost liczby połączeń. CVE-2026-75803 może nie powodować awarii; wymaga przeglądu aplikacji pod kątem pustych wiadomości AEAD oraz tego, czy sukces EVP_Cipher() jest traktowany jako jedyny dowód autentyczności.
Wnioski dla twórców bibliotek i protokołów
Trzy problemy dotyczą własności lub rozmiaru pamięci: podwójne zwolnienie QRX, zbyt mały bufor unwrap oraz retencja całego bufora DTLS. Dwa kolejne pokazują, że metadane protokołu wymagają limitu życia: ACK-only i extraCerts. CMP przypomina również, że typ ASN.1 oraz format string są elementami granicy danych, nie szczegółami diagnostyki.
Testy powinny obejmować ścieżki błędów po częściowym przekazaniu własności, zapytanie o rozmiar różniące się od finalnej operacji, puste payloady i zasoby, których peer nie ma obowiązku potwierdzić. Fuzzing pakietu wejściowego jest potrzebny, lecz równie ważne są asercje stanu po odrzuceniu wiadomości i długotrwałe testy pamięci.
Fakty źródłowe i wnioski Breachroad
Liczba luk, wagi, mechanizmy, zakres wersji, poprawione wydania i oceny skutku pochodzą z oficjalnego OpenSSL Security Advisory z 25 sierpnia. Projekt nie zgłasza w nim aktywnej eksploatacji ani potwierdzonego RCE dla błędów pamięci. Nie należy podnosić Moderate lub Low do „krytycznych zero-dayów” bez dodatkowych dowodów.
Priorytety wdrożeniowe, inwentaryzacja runtime, testy protokołów i rekomendacje obserwowalności są wnioskami Breachroad. Szkolenia secure coding i bezpieczeństwa infrastruktury pomagają zespołom analizować granice protokołów, a testy aplikacji i usług mogą sprawdzić odporność wdrożenia oraz bezpieczne użycie biblioteki.


