- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 60
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
12 assets you may test, 5 excluded.
Web 1
- https://www.wolfssl.com
Products and areas 11
- DTLS and its retransmission, replay and cookie handling, which is a distinct state machine used heavily on the embedded side
- The build system and the configuration surface, since a define that silently disables a check is a defect in a library designed to be compiled down
- The certificate stack: ASN.1 and X.509 parsing, chain building, path validation, name checking, CRL and OCSP handling
- The companion products maintained in the same tree and by the same team where they are covered by this policy, including the SSH, MQTT and TPM libraries built on wolfCrypt
- The FIPS module, its boundary, its self-tests and the digest and key size checks it enforces
- The hardware acceleration and cryptographic offload backends, along with the secure element and TPM integrations
- The OpenSSL compatibility layer, where an application ported from OpenSSL relies on a shim to preserve a check
- The published SECURITY-POLICY.md sets out severity criteria, a mandatory report template and a coordinated disclosure process, without carving the library into in-scope and out-of-scope components. Treat the whole wolfSSL tree as the target
- The random number generator, its entropy sources on constrained targets, and its behaviour where no operating system entropy exists
- The TLS implementation across every version wolfSSL supports, client and server, covering handshake state, the record layer, session resumption and renegotiation
- wolfCrypt in full, covering the symmetric ciphers, AEAD tag verification, the hash and MAC families, RSA, the elliptic curve implementations and the post-quantum algorithms
Out of scope (5)
- A downstream vendor's firmware integration rather than the library, unless the library's documented usage leads there
- Attacks requiring physical possession of a device and invasive access to it, such as decapping or fault injection on the die
- Configurations the project documents as insecure and gates behind an explicit opt-in define
- Reports submitted to the unclaimed HackerOne directory page, which nobody at the project is triaging
- Weaknesses in a standardised algorithm rather than in wolfSSL's implementation of it
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Use the wolfSSL Vulnerability Report Template. The policy makes it mandatory, so a free-form report is a slower report
-
Send it to the address on the policy page , or to the address on the policy page ; both are documented and PGP is available for either
-
hackerone.com/wolfssl is an unclaimed directory page rather than a programme, so do not submit there expecting triage or payment
-
Name the build configuration. wolfSSL is compiled down to fit a target, and half the library can be absent, so the enabled defines decide whether a defect exists in a given firmware image
-
State whether the finding is in the FIPS build. The FIPS module is a separate certified artefact and a defect in it carries a certification consequence alongside the security one
-
Give the hardware and the crypto backend. wolfSSL offloads to hardware accelerators on many targets, and a software-path finding may not reproduce on a device that never runs that code
Not accepted
-
Weaknesses in a standardised algorithm rather than in wolfSSL's implementation of it
-
A downstream vendor's firmware integration rather than the library, unless the library's documented usage leads there
-
Configurations the project documents as insecure and gates behind an explicit opt-in define
-
Attacks requiring physical possession of a device and invasive access to it, such as decapping or fault injection on the die
-
Reports submitted to the unclaimed HackerOne directory page, which nobody at the project is triaging
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-93304 | A (D)TLS 1.2 client can accept a ChangeCipherSpec message before it has sent its ClientKeyExchange. No master secret has been derived at that point, so the client installs read keys derived from a known (deterministic) key and checks the server's Finished against that same key. An out-of-order ChangeCipherSpec can therefore be used by an attacker to complete the handshake in place of the server an | Medium 6.3 | 27 Sep 2026 |
| CVE-2026-94417 | When an application enables both OCSP and CRL revocation checking on one WOLFSSL_CTX or certificate manager, wolfSSL skips the CRL check for any peer certificate that carries no Authority Information Access OCSP URL, and accepts a certificate the loaded CRL lists as revoked. The soft-fail policy for a missing responder collapses the OCSP result onto success before the code decides whether the CRL | Low 2.3 | 27 Sep 2026 |
| CVE-2026-89102 | In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a | High 8.3 | 27 Sep 2026 |
| CVE-2026-89133 | wolfSSL versions 5.9.2 and earlier contain a flaw in the X.509 certificate validation logic where it fails to properly enforce NameConstraints extensions when there is an unconstrained CA tier between a name-constrained intermediate CA and the leaf certificate. wolfSSL incorrectly accepted certificates for hostnames they shouldn't be allowed to cover, due to a chain-walking state-machine bug that | Medium 6.3 | 27 Sep 2026 |
| CVE-2026-89134 | A certificate with no dNSName SAN but another SAN type present (e.g. registeredID or iPAddress) bypassed the Subject CN dNSName name-constraint check. The CN-as-DNS fallback was gated on cert->subjectCN != NULL && cert->altNames == NULL && !cert->isCA instead of "no dNSName SAN", so an out-of-scope CN was accepted. This incomplete fix from CVE-2026-6731, leading to the name-constraint check issue, | Medium 6.3 | 27 Sep 2026 |
| CVE-2026-89135 | A failed X509_verify_cert call permanently plants an unverified attacker CA in the shared CertManager, bypassing certificate validation in every type-blind sibling consumer (native TLS, OCSP, CRL, direct CM verify). This affects version 5.8.4 through 5.9.2 of wolfSSL with the macros (OPENSSL_EXTRA && !NO_CERTS && !WOLFCRYPT_ONLY) defined or built with --enable-opensslextra and the application is s | Medium 6.3 | 27 Sep 2026 |
| CVE-2026-93302 | MatchTrustedPeer ignores the public key used, leading to forged CA clones passing verification. Affected builds are any that enable the macro WOLFSSL_TRUST_PEER_CERT and load CA certificates with wolfSSL_CTX_trust_peer_cert() or wolfSSL_trust_peer_cert(). The peer must know the certificates being loaded to either of those APIs to take advantage of the issue. When OPENSSL_COMPATIBLE_DEFAULTS is als | High 8.3 | 27 Sep 2026 |
| CVE-2026-15442 | In all builds that make use of (D)TLS, including default builds, there is a series of conditional states during the TLS shutdown which could lead to a heap-use-after free. If an application ended up getting a partial wolfSSL_read() which is sometimes caused by a small user buffer passed in, then called wolfSSL_shutdown for a bidirectional close and attempted to wolfSSL_read() again while the peer | Low 2.3 | 27 Sep 2026 |
| CVE-2026-94418 | 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 | Low 2.3 | 27 Sep 2026 |
| CVE-2026-94419 | Without NO_SESSION_CACHE_REF, wolfSSL_get_session() does not return a session object but a ClientSession reference of the form {row, index, hash(sessionID)} into the process-global SessionCache, and ClientSessionToSession() validates it against that hash alone. Because the TLS 1.2 session ID is chosen by the server and sent in clear, AddSessionToCache() matches any other server's session on the sa | Low 2.3 | 27 Sep 2026 |
| CVE-2026-81019 | wolfProvider before 1.2.2 generates the 8-byte explicit AES-GCM nonce once when the TLS write key is set and never increments it per record. As a result every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is encrypted under an identical key and nonce pair. Reusing a GCM key and nonce discloses the keystream (the XOR of two ciphertexts equals the XOR of their plaintexts, so one known reco | High 7.4 | 28 Aug 2026 |
| CVE-2026-81020 | wolfEngine before 1.4.1 generates the 8-byte explicit AES-GCM nonce once when the TLS write key is set and never increments it per record. As a result every TLS 1.2 and DTLS 1.2 AES-GCM record within a connection is encrypted under an identical key and nonce pair. Reusing a GCM key and nonce discloses the keystream (the XOR of two ciphertexts equals the XOR of their plaintexts, so one known record | High 7.4 | 28 Aug 2026 |
| CVE-2026-81341 | wolfEngine before 1.4.1 sources the explicit AES-CCM nonce for TLS 1.2 and DTLS 1.2 records from the record input buffer instead of the TLS sequence number carried in the additional authenticated data. Because the record layer leaves the explicit-nonce field for the cipher to populate, the value read is constant across records, so every AES-CCM record within a connection is encrypted under an iden | Medium 6.5 | 28 Aug 2026 |
| CVE-2026-6092 | When HAVE_ENCRYPT_THEN_MAC is configured, the implementation could fall back to MAC-then-Encrypt rather than enforcing Encrypt-then-MAC. | Low 2.1 | 25 Jun 2026 |
| CVE-2026-6325 | Out-of-bounds write in SetSuitesHashSigAlgo when processing an oversized signature algorithms list, allowing a write past the bounds of the destination buffer. | Low 2.0 | 25 Jun 2026 |
| CVE-2026-6329 | PKCS#12 MAC verification uses an attacker-controlled comparison length, weakening the integrity check on the MAC and allowing a mismatched MAC to be accepted. The PKCS#12 verify path compared the locally computed HMAC against the MAC parsed from the PKCS#12 structure using a length taken directly from the attacker-supplied input, without first verifying that it equals the length of the digest actu | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-6330 | The ML-KEM ARM64 NEON ciphertext comparison only compares half of the input, breaking the Fujisaki-Okamoto transform's implicit rejection and weakening IND-CCA2 security on that code path. The constant-time comparison effectively ignored part of the re-encrypted ciphertext, so a decapsulating party could fail to detect a manipulated ciphertext and proceed without the standard's required implicit r | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-6331 | HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length | Low 2.1 | 25 Jun 2026 |
| CVE-2026-7511 | PKCS7_verify signer confusion allows forged signatures, where the signer associated with a signature is not correctly bound, permitting a forged signature to be accepted. | Medium 5.9 | 25 Jun 2026 |
| CVE-2026-7532 | iPAddress name constraints bypass when WOLFSSL_IP_ALT_NAME is not defined. IP address name constraints are not enforced in that configuration, allowing a certificate to bypass an issuing CA's IP address constraints. | Medium 5.7 | 25 Jun 2026 |
| CVE-2026-8720 | wc_Blake2bHmacFinal and wc_Blake2sHmacFinal discard the message when the key length exceeds the block size, producing a MAC that is independent of the input. When the supplied key is longer than the BLAKE2 block size the key-hashing branch reinitialized the running hash state, discarding the accumulated message data, so the resulting MAC depended only on the key and not on the message being authen | Medium 5.9 | 25 Jun 2026 |
| CVE-2026-55962 | TLS 1.3 post-handshake authentication (PHA) issue where a server could accept a client's Finished message without the client having sent a Certificate and CertificateVerify. The post-handshake-auth exemption that allows an empty/absent peer certificate was only intended for the initial handshake, but it was also being applied while a post-handshake CertificateRequest was still outstanding. The che | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-10098 | OCSP CertID serial-number length-confusion in wolfSSL_OCSP_resp_find_status allows a same-issuer SingleResponse whose serial is a prefix of the target serial to be reported as the revocation status of a different certificate. The lookup compared serial-number bytes without first requiring the two serial numbers to be of equal length, so a SingleResponse for one certificate (same issuer) whose seri | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-11703 | Missing SNI/ALPN binding on stateful (session-ID) resumption, which previously skipped the binding check performed for ticket-based resumption. A cached session could be resumed under a different SNI/ALPN than originally negotiated and, where client-authentication policy differs across virtual hosts, carry the cached peer-authentication state into a context it was not established for. Resumption n | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-6412 | Certificate policy and RFC 8446 compliance concerns regarding the continued acceptance of SHA-1/MD5 in certificate processing. | Low 2.3 | 25 Jun 2026 |
| CVE-2026-6450 | A CRL critical extension bypass exists in ParseCRL_Extensions where critical extensions are not properly enforced, allowing a crafted CRL with an unhandled critical extension to be accepted. This only affects builds with CRL support enabled and where a crafted CRL had a trusted signature when parsed. | Low 1.0 | 25 Jun 2026 |
| CVE-2026-6678 | Integer underflow in wc_PKCS7_DecryptOri when handling crafted Other Recipient Info, leading to incorrect length handling during decryption. | Low 1.0 | 25 Jun 2026 |
| CVE-2026-6679 | A heap buffer overflow could occur in the DTLS 1.3 ACK serialization path before the connecting peer is authenticated. The buffer overflow was due to an integer truncation when computing the length of the ACK record-number list, causing an undersized buffer to be allocated and then overrun. This affects builds using DTLS 1.3 and wolfSSL version 5.9.0 and earlier. A fix was added to the 5.9.1 relea | High 8.8 | 25 Jun 2026 |
| CVE-2026-6681 | The PKCS#7 decode path ignores the caller-supplied output buffer size (outputSz), allowing decoded content to be written past the bounds of the provided buffer. This affects wolfSSL 5.9.0 and earlier and was fixed in the 5.9.1 release. | Low 1.0 | 25 Jun 2026 |
| CVE-2026-6731 | X.509 name constraint bypass via the Subject Common Name when treated as a DNS-type name. A certificate whose Subject CN violates an issuing CA's DNS name constraints could be accepted. | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-7531 | Use-after-free in PQC hybrid key-share handling. This is an incomplete-fix follow-up to CVE-2026-5460 (released in 5.9.1): a malicious TLS 1.3 server sending a truncated PQC hybrid KeyShare can still trigger the error cleanup path to operate on freed memory. | Low 2.3 | 25 Jun 2026 |
| CVE-2026-55960 | Un-negotiated Raw Public Key (RFC 7250) accepted in place of an X.509 certificate, bypassing chain validation. A raw public key has no chain, so ParseCertRelative() accepts it without performing any trust verification; it must therefore only be accepted when RPK was actually negotiated for that peer. The check now defaults the expected type to X.509 (per RFC 7250/8446) when no type was negotiated, | High 8.2 | 25 Jun 2026 |
| CVE-2026-55964 | Chain intermediate CA:TRUE without keyCertSign accepted as a signing CA. Intermediate CA certificates are required to have the keyCertSign key usage when a Key Usage extension is present, but chain-supplied temporary CAs (WOLFSSL_TEMP_CA) added while building a certificate path were previously exempted from this check, so an intermediate asserting CA:TRUE but lacking keyCertSign was accepted as a | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-55958 | Out-of-bounds write in the Renesas TSIP TLS 1.3 transcript buffer. In tsip_StoreMessage() the capacity check guarding the fixed message bag (MSGBAG_SIZE) sets an error code but fails to return, so execution falls through to an XMEMCPY that writes past the end of the buffer once the accumulated TLS 1.3 handshake transcript exceeds MSGBAG_SIZE (8 KB), corrupting adjacent heap state and potentially c | High 8.3 | 25 Jun 2026 |
| CVE-2026-10512 | The X25519 x86_64 assembly implementation fails to clear the most significant bit during the final modular reduction, so the computed result may not be fully reduced modulo the field prime 2^255 - 19. This can leave the field element in a non-canonical form, producing an incorrect result from the scalar multiplication and potentially a wrong shared secret. The final carry-propagation chains in the | Low 2.3 | 25 Jun 2026 |
| CVE-2026-10592 | Certificates with wildcard DNS SANs (e.g. *.example.com) bypassed CA name-constraint checks. A certificate with a wildcard DNS SAN that should be rejected by the issuing CA's permitted/excluded DNS name constraints could be accepted. | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-11310 | X.509 trust-chain bypass in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra (OPENSSL_EXTRA) and whose application validates certificates by calling X509_verify_cert() with caller-supplied untrusted intermediate certificates; for those users it is critical, otherwise the library is unaffected. In particular, native wol | High 8.7 | 25 Jun 2026 |
| CVE-2026-12340 | Out-of-bounds heap read during SM2/SM3 certificate signature verification. When parsing a certificate with an SM3wSM2 signature, the Subject Key Identifier computation reads the trailing 65 bytes of the public key without checking that the key is at least that long. A public key shorter than 65 bytes results in an out-of-bounds heap read, leading to a potential crash (denial of service); there is | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-10097 | wolfSSL's AVX2-optimized ML-KEM implementation (mlkem_cmp_avx2) compares only 1536 of the 1568 ciphertext bytes during the Fujisaki-Okamoto re-encryption check in ML-KEM-1024 decapsulation. Ciphertexts that differ from the expected re-encryption solely in bytes 1536-1567 bypass implicit rejection and are accepted as valid, breaking IND-CCA2 security. An attacker able to submit chosen ciphertexts t | High 8.3 | 25 Jun 2026 |
| CVE-2026-6094 | Heap buffer overread in wc_PKCS7_DecodeEnvelopedData when parsing crafted PKCS7 EnvelopedData. This could theoretically be triggered by attacker-supplied data delivered via S/MIME or CMS. | Medium 6.3 | 25 Jun 2026 |
| CVE-2026-6291 | Bleichenbacher padding oracle in PKCS#7 KTRI decryption. When decrypting PKCS#7 EnvelopedData using RSA PKCS#1 v1.5 key transport, wolfSSL returned distinguishable error codes depending on whether RSA padding validation failed versus whether the decrypted content was malformed. An attacker able to submit crafted EnvelopedData messages and observe error responses could use this as a padding oracle | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-55961 | wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer | High 8.2 | 25 Jun 2026 |
| CVE-2026-55967 | AES-GCM encryption/decryption with extremely large cumulative single message sizes (>64 GiB) were not properly rejected by the streaming APIs, allowing counter wrap, keystream reuse, and consequent plaintext recovery. | Low 2.0 | 25 Jun 2026 |
| CVE-2026-6091 | Partial-chain certificate verification may accept chains that terminate at a peer-supplied, untrusted intermediate certificate rather than a trusted anchor. An attacker could present a chain that ends at an intermediate they control and have it accepted as valid. This affects the OpenSSL compatibility certificate-path-building path (wolfSSL_X509_verify_cert / X509_STORE, OPENSSL_EXTRA) when the X5 | Medium 6.0 | 25 Jun 2026 |
| CVE-2026-11999 | X.509 trust-chain bypass (path-depth exhaustion) in the OpenSSL compatibility certificate verifier (wolfSSL_X509_verify_cert()). This affects only builds with --enable-opensslextra whose application calls X509_verify_cert() with caller-supplied untrusted intermediates; for those users it is critical, otherwise the library is unaffected. Native wolfSSL TLS/DTLS usage is not impacted. X509_verify_ce | High 8.2 | 25 Jun 2026 |
| CVE-2026-5477 | An integer overflow existed in the wolfCrypt CMAC implementation, that could be exploited to forge CMAC tags. The function wc_CmacUpdate used the guard `if (cmac->totalSz != 0)` to skip XOR-chaining on the first block (where digest is all-zeros and the XOR is a no-op). However, totalSz is word32 and wraps to zero after 2^28 block flushes (4 GiB), causing the guard to erroneously discard the live C | High 8.2 | 10 Apr 2026 |
| CVE-2026-5479 | In wolfSSL's EVP layer, the ChaCha20-Poly1305 AEAD decryption path in wolfSSL_EVP_CipherFinal (and related EVP cipher finalization functions) fails to verify the authentication tag before returning plaintext to the caller. When an application uses the EVP API to perform ChaCha20-Poly1305 decryption, the implementation computes or accepts the tag but does not compare it against the expected value. | High 7.6 | 10 Apr 2026 |
| CVE-2026-5500 | wolfSSL's wc_PKCS7_DecodeAuthEnvelopedData() does not properly sanitize the AES-GCM authentication tag length received and has no lower bounds check. A man-in-the-middle can therefore truncate the mac field from 16 bytes to 1 byte, reducing the tag check from 2⁻¹²⁸ to 2⁻⁸. | High 8.7 | 10 Apr 2026 |
| CVE-2026-5501 | wolfSSL_X509_verify_cert in the OpenSSL compatibility layer accepts a certificate chain in which the leaf's signature is not checked, if the attacker supplies an untrusted intermediate with Basic Constraints `CA:FALSE` that is legitimately signed by a trusted root. An attacker who obtains any leaf certificate from a trusted CA (e.g. a free DV cert from Let's Encrypt) can forge a certificate for an | High 8.6 | 10 Apr 2026 |
| CVE-2026-5188 | An integer underflow issue exists in wolfSSL when parsing the Subject Alternative Name (SAN) extension of X.509 certificates. A malformed certificate can specify an entry length larger than the enclosing sequence, causing the internal length counter to wrap during parsing. This results in incorrect handling of certificate data. The issue is limited to configurations using the original ASN.1 parsin | Low 2.3 | 10 Apr 2026 |
| CVE-2026-5466 | wolfSSL's ECCSI signature verifier `wc_VerifyEccsiHash` decodes the `r` and `s` scalars from the signature blob via `mp_read_unsigned_bin` with no check that they lie in `[1, q-1]`. A crafted forged signature could verify against any message for any identity, using only publicly-known constants. | High 7.6 | 10 Apr 2026 |
| CVE-2026-5392 | Heap out-of-bounds read in PKCS7 parsing. A crafted PKCS7 message can trigger an OOB read on the heap. The missing bounds check is in the indefinite-length end-of-content verification loop in PKCS7_VerifySignedData(). | Low 2.3 | 10 Apr 2026 |
| CVE-2026-5393 | Dual-Algorithm CertificateVerify out-of-bounds read. When processing a dual-algorithm CertificateVerify message, an out-of-bounds read can occur on crafted input. This can only occur when --enable-experimental and --enable-dual-alg-certs is used when building wolfSSL. | Medium 6.3 | 10 Apr 2026 |
| CVE-2026-5448 | X.509 date buffer overflow in wolfSSL_X509_notAfter / wolfSSL_X509_notBefore. A buffer overflow may occur when parsing date fields from a crafted X.509 certificate via the compatibility layer API. This is only triggered when calling these two APIs directly from an application, and does not affect TLS or certificate verify operations in wolfSSL. | Low 2.3 | 10 Apr 2026 |
| CVE-2026-5460 | A heap use-after-free exists in wolfSSL's TLS 1.3 post-quantum cryptography (PQC) hybrid KeyShare processing. In the error handling path of TLSX_KeyShare_ProcessPqcHybridClient() in src/tls.c, the inner function TLSX_KeyShare_ProcessPqcClient_ex() frees a KyberKey object upon encountering an error. The caller then invokes TLSX_KeyShare_FreeAll(), which attempts to call ForceZero() on the already-f | Medium 6.3 | 10 Apr 2026 |
| CVE-2026-5507 | When restoring a session from cache, a pointer from the serialized session data is used in a free operation without validation. An attacker who can poison the session cache could trigger an arbitrary free. Exploitation requires the ability to inject a crafted session into the cache and for the application to call specific session restore APIs. | Medium 4.1 | 9 Apr 2026 |
| CVE-2026-5295 | A stack buffer overflow exists in wolfSSL's PKCS7 implementation in the wc_PKCS7_DecryptOri() function in wolfcrypt/src/pkcs7.c. When processing a CMS EnvelopedData message containing an OtherRecipientInfo (ORI) recipient, the function copies an ASN.1-parsed OID into a fixed 32-byte stack buffer (oriOID[MAX_OID_SZ]) via XMEMCPY without first validating that the parsed OID length does not exceed MA | Medium 5.9 | 9 Apr 2026 |
| CVE-2026-5503 | In TLSX_EchChangeSNI, the ctx->extensions branch set extensions unconditionally even when TLSX_Find returned NULL. This caused TLSX_UseSNI to attach the attacker-controlled publicName to the shared WOLFSSL_CTX when no inner SNI was configured. TLSX_EchRestoreSNI then failed to clean it up because its removal was gated on serverNameX != NULL. The inner ClientHello was sized before the pollution but | Medium 6.9 | 9 Apr 2026 |
| CVE-2026-5504 | A padding oracle exists in wolfSSL's PKCS7 CBC decryption that could allow an attacker to recover plaintext through repeated decryption queries with modified ciphertext. In previous versions of wolfSSL the interior padding bytes are not validated. | Medium 6.3 | 9 Apr 2026 |
| CVE-2026-5778 | Integer underflow in wolfSSL packet sniffer <= 5.9.0 allows an attacker to cause a program crash in the AEAD decryption path by injecting a TLS record shorter than the explicit IV plus authentication tag into traffic inspected by ssl_DecodePacket. The underflow wraps a 16-bit length to a large value that is passed to AEAD decryption routines, causing a large out-of-bounds read and crash. An unauth | Low 2.1 | 9 Apr 2026 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview wolfSSL is the TLS and cryptography stack for hardware with no room for OpenSSL. It runs in automotive control units, industrial controllers, medical devices, routers and set-top boxes, and it is one of curl's supported TLS backends, so the same code sits in embedded firmware and in ordinary Linux tooling. CVE-2026-5194 is the reference point: a digest-size check bypass in the FIPS path, rated critical. The vendor sells commercial licences and support, and the security policy documents a report template and a coordinated process with no reward of any kind attached. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published SECURITY-POLICY.md sets out severity criteria, a mandatory report template and a coordinated disclosure process, without carving the library into in-scope and out-of-scope components. Treat the whole wolfSSL tree as the target The TLS implementation across every version wolfSSL supports, client and server, covering handshake state, the record layer, session resumption and renegotiation DTLS and its retransmission, replay and cookie handling, which is a distinct state machine used heavily on the embedded side The certificate stack: ASN.1 and X.509 parsing, chain building, path validation, name checking, CRL and OCSP handling wolfCrypt in full, covering the symmetric ciphers, AEAD tag verification, the hash and MAC families, RSA, the elliptic curve implementations and the post-quantum algorithms The FIPS module, its boundary, its self-tests and the digest and key size checks it enforces The random number generator, its entropy sources on constrained targets, and its behaviour where no operating system entropy exists The OpenSSL compatibility layer, where an application ported from OpenSSL relies on a shim to preserve a check The hardware acceleration and cryptographic offload backends, along with the secure element and TPM integrations The companion products maintained in the same tree and by the same team where they are covered by this policy, including the SSH, MQTT and TPM libraries built on wolfCrypt The build system and the configuration surface, since a define that silently disables a check is a defect in a library designed to be compiled down Out of scope Weaknesses in a standardised algorithm rather than in wolfSSL's implementation of it A downstream vendor's firmware integration rather than the library, unless the library's documented usage leads there Configurations the project documents as insecure and gates behind an explicit opt-in define Attacks requiring physical possession of a device and invasive access to it, such as decapping or fault injection on the die Reports submitted to the unclaimed HackerOne directory page, which nobody at the project is triaging Most-valued findings Anything that defeats a check inside the FIPS module. CVE-2026-5194 was a critical digest-size check bypass in exactly that path, and a defect there invalidates the guarantee the certification was bought for Certificate and chain validation failures that accept a chain they should reject, because wolfSSL is the client side in a very large number of devices that phone home over TLS Memory corruption reachable from a peer-controlled handshake message, record or extension. On the embedded targets this library was written for, that is code execution on a device with no exploit mitigations Protocol state machine defects that let a peer skip, reorder or replay handshake steps, particularly in the DTLS path where the state machine is more permissive by nature Timing and power side channels in wolfCrypt, which matter far more here than in a server library because an attacker often has the device in hand Random number generator weaknesses on constrained targets, where the entropy story is thin and a predictable key is a fleet-wide compromise Defects in the OpenSSL compatibility layer where a ported application believes a check ran and it did not Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Use the wolfSSL Vulnerability Report Template. The policy makes it mandatory, so a free-form report is a slower report Send it to [email protected] , or to [email protected] ; both are documented and PGP is available for either hackerone.com/wolfssl is an unclaimed directory page rather than a programme, so do not submit there expecting triage or payment Name the build configuration. wolfSSL is compiled down to fit a target, and half the library can be absent, so the enabled defines decide whether a defect exists in a given firmware image State whether the finding is in the FIPS build. The FIPS module is a separate certified artefact and a defect in it carries a certification consequence alongside the security one Give the hardware and the crypto backend. wolfSSL offloads to hardware accelerators on many targets, and a software-path finding may not reproduce on a device that never runs that code The vendor sells licences and support and pays nothing for a vulnerability report; the policy contains no reward language at all Disclosure Coordinated with the vendor's security team by email under a documented policy with published severity criteria. wolfSSL publishes vulnerabilities on its own site and folds fixes into the next release, and the throughput is heavy enough that findings tend to travel in release-sized batches. The hard part of the embargo is downstream: firmware in a vehicle or a medical device is rebuilt on a timescale measured in quarters, so hold the detail past the release rather than to the release. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability