mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-07-05 16:50:48 +02:00
Merge pull request #10284 from ColtonWilley/security_policy_and_report_template
Publish wolfSSL Security Policy and Vulnerability Report Template
This commit is contained in:
David Garske
GitHub
+6
-5
@@ -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).
|
||||
|
||||
@@ -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*
|
||||
@@ -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*
|
||||
Reference in New Issue
Block a user