wolfSSL bug bounty programs
wolfssl.com Updated
WolfSSL runs two public programs: a Sorona bug bounty paying up to $1,500 and a Sorona bug bounty paying up to $1,500.
- Top reward
- $1,500
- Sorona
- Programs
- 2
- 2 pay cash
- Targets in scope
- 19
- 2 types, deduplicated
- Last change
- None yet
- Tracked since Nov 2026
Where to report
2 programs, side by side. Report where the affected target is in scope; when two programs cover it, pick the one that pays more.
Start here
wolfSSL
Sorona · Pays the most of the 2 programs: up to $1,500.
| Program | Critical | High | Medium | Low | Top reward | Safe harbor | KYC | First response | Status |
|---|---|---|---|---|---|---|---|---|---|
|
wolfSSL
Sorona · Bug bounty |
– | – | – | $100 (highest) | $1,500 | Partial | – | – | Open |
|
wolfBoot
Sorona · Bug bounty |
– | – | – | $100 | $1,500 | Partial | – | – | Open |
-
- Critical
- –
- High
- –
- Medium
- –
- Low
- $100 (highest)
- Safe harbor
- Partial
-
- Critical
- –
- High
- –
- Medium
- –
- Low
- $100
- Safe harbor
- Partial
Amounts are the top reward per severity in the currency each program pays. Green marks the highest per severity. First response is the platform's measured average when it publishes one, else what the policy promises.
What is in scope
19 targets across all 2 programs, each listed once with the programs that cover it. 11 excluded.
-
DTLS and its retransmission, replay and cookie handling, which is a distinct state machine used heavily on the embedded side
Products and areas
Covered by wolfSSL
-
Every platform port the project ships, covering Arm Cortex-M, RISC-V, PowerPC and x86, whose linker and memory-protection assumptions differ from one another
Products and areas
Covered by wolfBoot
-
Reports go to wolfSSL through the address in the project's SECURITY.md. The covered object is the GPL-3.0 upstream bootloader in full, with the paid commercial build variants sitting outside it
Products and areas
Covered by wolfBoot
-
Signature verification across every algorithm the bootloader supports, covering the ECDSA, Ed25519, RSA and post-quantum LMS and XMSS paths, where a verification flaw makes an unsigned image boot
Products and areas
Covered by wolfBoot
-
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
Products and areas
Covered by wolfSSL
-
The certificate stack: ASN.1 and X.509 parsing, chain building, path validation, name checking, CRL and OCSP handling
Products and areas
Covered by wolfSSL
-
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
Products and areas
Covered by wolfSSL
-
The FIPS module, its boundary, its self-tests and the digest and key size checks it enforces
Products and areas
Covered by wolfSSL
-
The hardware acceleration and cryptographic offload backends, along with the secure element and TPM integrations
Products and areas
Covered by wolfSSL
-
The OpenSSL compatibility layer, where an application ported from OpenSSL relies on a shim to preserve a check
Products and areas
Covered by wolfSSL
-
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
Products and areas
Covered by wolfSSL
-
The random number generator, its entropy sources on constrained targets, and its behaviour where no operating system entropy exists
Products and areas
Covered by wolfSSL
-
The TLS implementation across every version wolfSSL supports, client and server, covering handshake state, the record layer, session resumption and renegotiation
Products and areas
Covered by wolfSSL
-
The update machinery end to end: rollback and anti-downgrade version enforcement, the update-partition state machine that decides which image is authoritative, encrypted-update key handling, and the swap and backup logic for A/B updates, including behaviour across an interrupted or power-cut swap
Products and areas
Covered by wolfBoot
-
The whole pre-verification parsing surface: firmware image header (manifest) parsing and the TLV field walker, which run on attacker-supplied bytes before any signature has been checked
Products and areas
Covered by wolfBoot
-
TPM 2.0 measured-boot integration and the wolfTPM interface, where a measurement that can be influenced breaks attestation
Products and areas
Covered by wolfBoot
-
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
Products and areas
Covered by wolfSSL
No target matches. Try part of a host name, such as the company name.
Out of scope 11
Don't test these. A program can exclude a host another program covers; the program you report to decides.
-
A downstream vendor's firmware integration rather than the library, unless the library's documented usage leads there
wolfSSL
-
Attacks requiring physical possession of a device and invasive access to it, such as decapping or fault injection on the die
wolfSSL
-
Configurations the project documents as insecure and gates behind an explicit opt-in define
wolfSSL
-
Non-exploitable crash-only one-liners, which sit at the bottom of the reward ladder and often below it
wolfBoot
-
Patches over twelve months old, which fall outside the program's age window
wolfBoot
-
Patches the wolfSSL maintainers decline, since the reward is contingent on the merge rather than on the idea
wolfBoot
-
Physical-attack scenarios such as glitching or decapping that assume laboratory access to the die rather than a software path
wolfBoot
-
Reports submitted to the unclaimed HackerOne directory page, which nobody at the project is triaging
wolfSSL
-
The commercially licensed build variants insofar as they diverge from the GPL-3.0 upstream
wolfBoot
-
Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail
wolfBoot
-
Weaknesses in a standardised algorithm rather than in wolfSSL's implementation of it
wolfSSL
Recent changes
Reward and scope changes across every wolfSSL program, newest first.
No changes recorded yet. New targets and reward moves show up here and in the RSS feed.
Recent CVEs
Published vulnerabilities in wolfSSL products, from the NVD.
-
CVE-2026-93304 Medium
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
-
CVE-2026-94417 Low
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
-
CVE-2026-94417 Low
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
-
CVE-2026-93304 Medium
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
-
CVE-2026-89102 High
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
-
CVE-2026-89134 Medium
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,
-
CVE-2026-89133 Medium
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
-
CVE-2026-89135 Medium
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
About this page
This page gathers every public program listed under wolfssl.com: platform programs, self-hosted policies and security.txt contacts. Each program's own policy decides what is in scope and what it pays; check it before you test.
Something wrong or missing? Report a correction.