CVE-2026-6678

Wersje wolfSSL przed 3.12.2 zawierają słabą orakl Bleichenbachera, gdy negocjowana jest jakakolwiek suite szyfrowania TLS z użyciem wymiany kluczy RSA. Atakujący może odzyskać klucz prywatny z podatnej aplikacji wolfSSL.

Wersje wolfSSL przed 3.11.0 nie zapobiegają akceptacji źle sformatowanego klucza DH przez funkcję wc_DhAgree.

Wersje wolfSSL przed 3.10.2 mają problem z dostępem do pamięci poza przydzielonym zakresem podczas ładowania spreparowanych parametrów DH, co prowadzi do przepełnienia bufora wywołanego przez źle sformatowany tymczasowy plik DH.

Wersje wolfSSL (wcześniej CyaSSL) przed 3.6.8 są podatne na atak typu denial of service, który może być spowodowany przez złośliwie skonstruowane ciasteczko DTLS w wiadomości ClientHello.

Certyfikat bez dNSName SAN, ale z innym typem SAN (np. registeredID lub iPAddress) omija sprawdzanie ograniczeń nazw dla CN jako DNS. Poprawka z CVE-2026-6731 była niekompletna, co wprowadzono w wolfSSL 5.9.2.

Podatność CVE-2023-3724 dotyczy klientów TLS 1.3, które nie otrzymują rozszerzenia PSK ani KSE podczas łączenia się z złośliwym serwerem. W takim przypadku używany jest domyślny, przewidywalny bufor dla wartości IKM, co może prowadzić do kompromitacji klucza sesji.

Specjalnie przygotowany certyfikat x509 może spowodować nadpisanie bajtu poza zakresem w wolfSSL w wersji do 3.10.2, co prowadzi do potencjalnych luk w walidacji certyfikatów, odmowy usługi oraz możliwego zdalnego wykonania kodu.

Podatność w funkcji ConfirmNameConstraints() w pliku wolfcrypt/src/asn.c biblioteki wolfSSL w wersjach 5.9.1 i 5.9.2 pozwala atakującemu wywołać odmowę usługi (DoS) poprzez dostarczenie spreparowanych certyfikatów urzędu certyfikacji. W efekcie klienci TLS oparte na wolfSSL błędnie odrzucają prawidłowe certyfikaty bez rozszerzenia SAN.

Podatność w wolfSSL powoduje pominięcie sprawdzania listy CRL dla certyfikatów bez adresu OCSP, gdy włączone jest jednocześnie sprawdzanie OCSP i CRL. W rezultacie certyfikat odwołany przez CRL może zostać zaakceptowany, a brak odpowiedzi OCSP jest traktowany jako odpowiedź pozytywna. Problem dotyczy wersji do 5.9.2 włącznie i jest osiągalny w TLS 1.0-1.3 oraz DTLS.

Klient (D)TLS 1.2 może zaakceptować wiadomość ChangeCipherSpec przed wysłaniem ClientKeyExchange, co pozwala atakującemu dokończyć handshake zamiast serwera i wysyłać dane akceptowane jako autentyczne. Klienci DTLS 1.2 są narażeni, gdy datagram dostarczy nieuporządkowane rekordy, a klienci TLS 1.2, gdy aplikacja używa wolfSSL_inject() lub włącza read ahead.