diff --git a/.github/SECURITY.md b/.github/SECURITY.md index 2bab9b6ff2a..a5b9a7cf010 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -2,11 +2,12 @@ ## Reporting a Vulnerability -If you discover a vulnerability, please report it to support@wolfssl.com +**Use of the wolfSSL Vulnerability Report Template is mandatory.** All security reports must use [`SECURITY-REPORT-TEMPLATE.md`](../SECURITY-REPORT-TEMPLATE.md), with every required field completed. Reports that do not use the template, or that leave required fields incomplete, will not receive CVE consideration. - 1. Include a detailed description - 2. Include method to reproduce and/or method of discovery - 3. We will evaluate the report promptly and respond to you with findings. - 4. We will credit you with the report if you would like. +Submit the completed template to **support@wolfssl.com**. + +Non-template submissions may still be reviewed on the merits and, where appropriate, addressed as hardening fixes in a future release. **Please keep the vulnerability private** until a fix has been released. + +For the full policy — severity rubric, coordinated-disclosure practice, and reporter credit — see [`SECURITY-POLICY.md`](../SECURITY-POLICY.md). diff --git a/SECURITY-POLICY.md b/SECURITY-POLICY.md new file mode 100644 index 00000000000..8f5c989ca67 --- /dev/null +++ b/SECURITY-POLICY.md @@ -0,0 +1,74 @@ +# wolfSSL Security Policy + +## About This Policy + +This document defines how wolfSSL Inc. handles security vulnerabilities in its products: how to report them, how we evaluate them, and how we coordinate disclosure. + +## Reporting a Vulnerability + +**Use of the wolfSSL Vulnerability Report Template is mandatory.** All security reports must be submitted using [`SECURITY-REPORT-TEMPLATE.md`](SECURITY-REPORT-TEMPLATE.md), with every required field completed. Reports that do not use the template, or that leave required fields incomplete, will not receive CVE consideration. + +Submit the completed template to **support@wolfssl.com**. + +Non-template submissions may still be reviewed on the merits and, where appropriate, addressed as hardening fixes in a future release. CVE assignment requires a complete template. + +We aim to acknowledge reports as they come in and engage with reporters throughout triage. Investigations proceed at the pace the material requires. + +## What wolfSSL Treats as a Vulnerability + +wolfSSL files a CVE advisory for defects with meaningful security impact on realistic wolfSSL deployments, where exploitability is demonstrated or clearly analyzable. wolfSSL determines whether a finding meets this bar. + +We classify confirmed vulnerabilities across four severity tiers: + +- **Critical** — Remote, practically exploitable defects in default configurations +- **High** — Serious defects with realistic exploitability +- **Medium** — Defects with meaningful impact under favorable conditions +- **Low** — Defects requiring specialized configurations or narrow deployment scenarios + +Reporter-proposed severity is input to the process, not its conclusion. + +## What Is Not Considered a Vulnerability + +Some defects are typically addressed as bug fixes rather than CVE-eligible vulnerabilities. These include: + +- Issues requiring physical access, physical-level side channels, or fault injection +- Issues the attacker can reach only with capabilities that already grant the outcome +- Issues reachable only through unsupported or undocumented API use +- Issues without a working reproducer +- Availability impact outside narrow protocol-facing cases + +wolfSSL determines whether a finding meets the CVE threshold. Findings below the threshold are addressed through normal release channels where appropriate; dispositions may be revisited when new information warrants. + +## Out of Scope + +- Third-party libraries bundled by customers +- Non-library code (example programs, test harnesses, developer tools) +- Documentation errors +- Performance issues without security implications + +## Supported Versions + +Security fixes are released for the current stable release and the immediately prior stable release. Older releases receive security fixes only under active commercial support agreements. + +## Coordinated Disclosure + +We investigate and fix confirmed vulnerabilities privately, coordinate disclosure timing with the reporter, and release the fix and security advisory together. Embargo extensions for ecosystem coordination — downstream integrators, certification bodies, or equivalent — are considered case-by-case. CVE records are published consistent with CVE Program rules. + +## Credit + +Reporters are credited in the advisory and release notes unless anonymity is requested. Reports are welcome from independent security researchers, academic researchers, and organizations conducting authorized security testing. + +Credit text is coordinated with the reporter before publication. + +## Contact + +- **support@wolfssl.com** — security vulnerability reports and general support +- **info@wolfssl.com** — general inquiries + +Published CVE advisories: https://www.wolfssl.com/docs/security-vulnerabilities/ + +## Policy Changes + +Material changes to this policy are announced via the wolfSSL blog. The canonical version of this policy is maintained in the wolfSSL GitHub repository. + +*Last updated: 2026-04-22* diff --git a/SECURITY-REPORT-TEMPLATE.md b/SECURITY-REPORT-TEMPLATE.md new file mode 100644 index 00000000000..eb03fb7a879 --- /dev/null +++ b/SECURITY-REPORT-TEMPLATE.md @@ -0,0 +1,243 @@ +# wolfSSL Vulnerability Report + +**Completion of every required field in this template is mandatory for CVE +consideration.** Reports that omit required fields, or that do not use this +template, will not receive CVE consideration. + +Non-template or incomplete submissions may still be reviewed on the merits +and, where appropriate, addressed as hardening fixes in a future release. + +Submissions that pass automated verification of the claims you make below +enter our triage queue per the Security Policy. + +--- + +## 1. Reporter Information + +**Name or handle:** _required_ +**Organization (if any):** _optional_ +**Contact email:** _required_ +**Preferred credit text** (or "anonymous"): _required_ + +**Discovery method** _required_: describe how you found this defect — manual +code review, fuzzer (name and version), static analysis tool (name), or other +methodology. + +**Prior reports:** has this defect been reported to wolfSSL or any other +party previously? If yes, provide details and any prior CVE or ticket +references. + +--- + +## 2. Affected Components + +**Product** _required_: wolfSSL, wolfCrypt, wolfSSH, wolfMQTT, wolfBoot, +wolfTPM, wolfSentry, wolfProvider, wolfHSM, wolfIP, wolfPSA, wolfPKCS11, or +the OpenSSL compatibility layer. + +**Versions tested** _required_: list the specific released versions you +verified the defect against (e.g., "5.8.4, 5.9.0, 5.9.1"). + +**Build configuration** _required_: state whether the defect is reachable in +a default `./configure` build. If not, list every `--enable-*` / +`--disable-*` flag, `WOLFSSL_*` macro, compiler version, target architecture, +and optimization level required for reachability. + +--- + +## 3. Defect Location + +**Source file** _required_: full path from repo root (e.g., +`wolfcrypt/src/asn.c`). + +**Function name** _required_. + +**Line numbers** _required_: the specific lines containing the defect. + +**Defect type and technical description** _required_: identify the class of +defect (heap buffer overflow, use-after-free, NULL dereference, signature +verification bypass, timing side channel, etc.) and describe in two to four +sentences what the code does, what it should do, and what goes wrong. + +--- + +## 4. Reachability from a wolfSSL Integration + +**Documented integration that routes attacker-controlled bytes to this code +path** _required_: identify the specific integration. Examples of qualifying +integrations include the TLS or DTLS protocol stack, X.509 peer certificate +validation during TLS authentication, OCSP / CRL fetching during TLS +verification, the OpenSSL compatibility layer consumed by a named integration +(nginx, Apache httpd, curl, OpenVPN, stunnel, MySQL, libssh, etc.), PKCS7 / +CMS verify or decrypt paths consumed by EST or SCEP enrollment, or PKCS#12 +parsing in dynamic credential provisioning (WPA supplicant, hostapd, +NetworkManager). + +**Byte-flow trace** _required_: starting from where attacker bytes enter +wolfSSL's API surface, list each function call (with file and line number) +through which the bytes travel until they reach the defective code. A trace +of three to ten steps is typical. + +Example of an acceptable trace: + +> Attacker bytes enter via TLS record at `wolfSSL_read()` → +> `ProcessReply` (ssl.c:18742) → `DoTls13HandshakeMessage` (tls13.c:11203) +> → `DoTls13Certificate` (tls13.c:8847) → `ProcessPeerCerts` (internal.c:14228) +> → `ParseCert` (asn.c:32104) → defective code at asn.c:33871. + +--- + +## 5. Attacker Model + +**Attacker position** _required_: describe who the attacker is — remote +unauthenticated network peer, on-path network attacker, authenticated remote +peer, local unprivileged user, local privileged user, attacker with prior +code execution on the device, or other. Be specific. + +**Prerequisites** _required_: list every capability the attacker must already +possess before the defect can be triggered, including any access, credentials, +configuration control, or environmental conditions. + +**New capability gained** _required_: describe the *delta* between what the +attacker can do before exploitation and what they can do after. + +**Realistic deployment context** _required_: identify one or more wolfSSL +customer deployment patterns where the attacker position you describe is +plausible. wolfSSL is deployed in embedded, industrial, automotive, medical, +avionics, and IoT contexts. + +--- + +## 6. Security Impact + +**Primary security property impacted** _required_ — pick one and justify +below: + +- [ ] **Integrity** — memory corruption enabling control-flow hijack, + arbitrary write, or state corruption with attacker control +- [ ] **Authenticity** — signature verification bypass, certificate + validation bypass, MAC forgery, algorithm downgrade, trust-chain bypass +- [ ] **Confidentiality of secret material** — disclosure of private keys, + session keys, password material, or pre-authentication server plaintext +- [ ] **Availability** — denial of service + +**Justification** _required_: in two to four sentences, explain how the +defect produces the impact you've selected, with reference to the byte flow +in Section 4 and the attacker model in Section 5. + +--- + +## 7. Working Proof-of-Concept + +**A working proof-of-concept is required.** Reports without one will not +receive CVE consideration. + +Provide: + +- Source code, packet capture, malformed input file, or other artifact that + triggers the defect +- Exact build and run instructions, including the wolfSSL version and build + configuration declared in Section 2 +- Expected output demonstrating the defect — crash trace, sanitizer report, + leaked memory contents, forged signature accepted by the verifier, or + equivalent concrete observable effect + +We compile and run submitted PoCs against the affected version. PoCs that do +not reproduce the claimed behavior, or that demonstrate behavior materially +different from the claim, will not receive CVE consideration. + +The following are not proofs-of-concept and will not satisfy this requirement: + +- Prose claims that the defect "may lead to memory corruption," "could + potentially crash the process," "is theoretically exploitable," or similar +- A description of an analytical exploitation chain without a runnable + artifact that produces the claimed effect +- A PoC that demonstrates a different effect than the impact claimed in + Section 6 (for example, a PoC that produces a NULL dereference accompanied + by a claim of remote code execution) +- Source code that does not compile, or instructions that do not run as + written + +--- + +## 8. Related Work Check + +**Have you verified this defect is not already being addressed?** _required_: +describe your review of open pull requests and recent commits in the +relevant wolfSSL repository that touch the same file or function. Include +the search terms you used and any specific PRs or commits you examined +(with URLs). AI-assisted tooling makes this search efficient and is a +reasonable way to perform it. + +**If related work is ongoing or merged** _required_: explain how your +report is novel relative to that work — e.g., your defect is in a +different code path, a different return value, a different call site, +or a different attacker reachability. + +Reports of issues already being addressed in open work are treated as +duplicates and do not receive CVE consideration. + +--- + +## 9. Caller API Usage + +**Does triggering the defect require the caller to use wolfSSL APIs outside +their documented behavior?** _required_: answer yes or no, then describe the +specific API calls, options, and sequences used. + +--- + +## 10. Severity Self-Assessment + +**Reporter-proposed severity** _required_: Critical, High, Medium, or Low. + +**CVSS 3.1 vector string** _optional_: e.g., `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. + +**Justification** _required_: in two to three sentences, map the severity to +the realistic attacker model and impact described above. + +wolfSSL performs its own severity assessment per the published rubric. Your +assessment is input, not the final classification. + +--- + +## 11. Disclosure Coordination + +**Requested embargo period** _required_: state your preferred embargo +duration. Longer embargoes for ecosystem coordination may be requested. + +**Downstream coordination** _required_: identify any downstream integrators, +certification bodies, or other parties whose involvement affects disclosure +timing. + +**Public disclosure plans** _required_: describe any planned blog post, +conference talk, paper, or other public disclosure, with tentative timing, +so we can coordinate the advisory release. + +--- + +## 12. Suggested Fix _(optional)_ + +If you have a proposed patch, attach it. Patches are not required, but they +accelerate the fix timeline. + +--- + +## What Happens Next + +1. **Acknowledgment.** We acknowledge receipt as reports arrive. +2. **Automated verification.** Our triage tooling cross-checks the claims + in your report against the source code: function names, line numbers, + call paths, version ranges, integration routes, and PoC reproduction. +3. **Initial triage verdict.** Once verification is complete, we provide + an initial verdict: CVE-eligible, hardening fix, or more information + needed. Complex or contested reports take longer than straightforward + ones. +4. **Coordination.** For CVE-eligible reports, we develop a fix privately + and coordinate disclosure timing with you. +5. **Disclosure.** The fix release and CVE advisory publish together. + +For questions about this template or the process, contact +**support@wolfssl.com**. + +*Last updated: 2026-04-22*