wolfssl/SECURITY-REPORT-TEMPLATE.md

# 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*