CVE-2026-94418
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
Podatność w wolfSSL przy włączonym WOLFSSL_SMALL_CERT_VERIFY pozwala atakującemu na obejście weryfikacji podpisu certyfikatu. Z powodu błędnego scalania wyników, błędy parsowania ukrywają nieprawidłowy podpis, a sprawdzenie daty ważności i ograniczeń jest wykonywane przed weryfikacją podpisu. Atakujący może użyć samodzielnie wygenerowanego certyfikatu z dowolnymi bajtami w miejscu podpisu, aby przejść weryfikację, jeśli aplikacja używa callbacku zezwalającego na błędy daty.
Ocena ryzyka
Ryzyko polega na tym, że atakujący bez kluczy prywatnych z prawdziwego PKI może podszyć się pod zaufany certyfikat, co może prowadzić do nieautoryzowanego dostępu lub ataku typu man-in-the-middle. Podatność dotyczy tylko konfiguracji z WOLFSSL_SMALL_CERT_VERIFY i odpowiednim callbackiem, ale w takiej konfiguracji może być wykorzystana zdalnie.
Rekomendacja
Zaleca się wyłączenie WOLFSSL_SMALL_CERT_VERIFY lub aktualizację wolfSSL do wersji z poprawką. Jeśli nie można zaktualizować, należy unikać używania callbacków weryfikacji, które zwracają 1 dla błędów daty, oraz rozważyć restart kontekstu lub procesu po wykryciu podejrzanych certyfikatów.
Inne podatności w wolfSSL
Zobacz wszystkie- CVE-2017-13099Wysokie
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.
- CVE-2017-8855Wysokie
Wersje wolfSSL przed 3.11.0 nie zapobiegają akceptacji źle sformatowanego klucza DH przez funkcję wc_DhAgree.
- CVE-2017-8854Wysokie
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.
- CVE-2015-6925Wysokie
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.
- CVE-2026-89134Krytyczne
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.
- CVE-2023-3724Krytyczne
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.
- CVE-2017-2800Krytyczne
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.
- CVE-2026-95208Wysokie
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.
- CVE-2026-94417Średnie
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.
- CVE-2026-93304Niskie
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.
Oryginalny opis (angielski, źródło NVD)
Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes "override date errors" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA's subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker's own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback's consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS