From f8c3f96f0835e7839a130b00511657971677b506 Mon Sep 17 00:00:00 2001 From: Mark Atwood Date: Fri, 21 Aug 2026 15:41:09 -0700 Subject: [PATCH 1/4] docs: make SECURITY-POLICY.md the only disclosure policy wolfSSL published two disclosure policies that disagreed. The repo named support@wolfssl.com for reports, the website named secure@wolfssl.com, and the report template that gates CVE consideration appeared only in the repo, so a researcher following security.txt never saw it. SECURITY-POLICY.md becomes the whole policy and absorbs what was website-only: products covered, the proof-of-concept requirement, threat-model boundaries, the safe-harbour statement, the PGP fingerprint, and CRA obligations. CRA text corrected. Article 14 requires notification to the coordinator CSIRT and ENISA together through the Article 16 platform, not to ENISA alone. EUVD publication is Article 17(5). Support period is Article 13(8). Article 14 applies from 11 September 2026 and, under Article 69(3), covers products already on the market. SECURITY-POLICY.md and SECURITY-REPORT-TEMPLATE.md are added to EXTRA_DIST. Neither shipped in the release archive. --- .github/SECURITY.md | 13 +++++------ Makefile.am | 2 ++ SECURITY-POLICY.md | 56 +++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 60 insertions(+), 11 deletions(-) diff --git a/.github/SECURITY.md b/.github/SECURITY.md index 85b059eac4a..f01e3fd4fb0 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -7,8 +7,9 @@ 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. -Submit the completed template to **support@wolfssl.com**. You may also send it to -**secure@wolfssl.com** and encrypt it with our PGP key: +Submit the completed template to **support@wolfssl.com**, monitored continuously. +To send it encrypted, use **secure@wolfssl.com** with the +[wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc): Fingerprint: A2A4 8E7B CB96 C5BE CB98 7314 EBC8 0E41 5CA2 9677 Key server: keys.openpgp.org @@ -20,8 +21,6 @@ appropriate, addressed as hardening fixes in a future release. ## Full Policy -For the full policy — severity rubric, scope, coordinated-disclosure practice, -and reporter credit — see [`SECURITY-POLICY.md`](../SECURITY-POLICY.md). The same -policy is also published at - so that -other wolfSSL repositories can reference one canonical copy. +[`SECURITY-POLICY.md`](../SECURITY-POLICY.md) is the full policy: reporting, +severity rubric, scope and threat-model boundaries, supported versions, +disclosure practice, reporter credit, and EU Cyber Resilience Act obligations. diff --git a/Makefile.am b/Makefile.am index 30c3ccdf0ec..95befa3f690 100644 --- a/Makefile.am +++ b/Makefile.am @@ -160,6 +160,8 @@ dist_example_DATA= ACLOCAL_AMFLAGS= -I m4 EXTRA_DIST+= .cyignore +EXTRA_DIST+= SECURITY-POLICY.md +EXTRA_DIST+= SECURITY-REPORT-TEMPLATE.md EXTRA_DIST+= wolfssl.vcproj EXTRA_DIST+= wolfssl.vcxproj EXTRA_DIST+= wolfssl-VS2022.vcxproj diff --git a/SECURITY-POLICY.md b/SECURITY-POLICY.md index c423da91614..d49b3fce16d 100644 --- a/SECURITY-POLICY.md +++ b/SECURITY-POLICY.md @@ -4,16 +4,32 @@ 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. +## Products Covered + +This policy covers security vulnerabilities in wolfSSL products distributed under commercial license or open source, including but not limited to: + +- wolfSSL / wolfCrypt +- wolfBoot +- wolfSSH +- wolfMQTT +- wolfTPM +- wolfGuard +- wolfCOSE + ## 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**. +Submit the completed template to **support@wolfssl.com**, monitored continuously. To send it encrypted, use **secure@wolfssl.com** with the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc). 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. +### Evidence we require + +We require a working proof of concept or concrete reproduction steps that demonstrate real impact. Reports that describe only theoretical weaknesses, scanner output without validation, or bulk-generated findings without evidence of manual analysis will be closed without review. If you used automated tooling, state what you used and show the work you did to confirm the finding is real. + ## 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. @@ -39,6 +55,14 @@ Some defects are typically addressed as bug fixes rather than CVE-eligible vulne 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. +### Threat-model boundaries + +wolfSSL products assume the integrity of the local execution environment. Reports that require the attacker to already have arbitrary memory write access on the host, or that rely on a compromised operating system kernel, are outside our threat model and will not receive a CVE. + +A certificate authority or HSM that returns incorrect, misleading, or malformed results is a compromised trust anchor. wolfSSL's security guarantees depend on the correctness of the trust anchors the deployer has configured. A wrong trust decision caused by a lying CA or a misbehaving HSM is not a vulnerability in wolfSSL; it is the expected consequence of a broken trust anchor. We may choose to add hardening against such scenarios, but they do not warrant a CVE. + +However, wolfSSL must handle malformed data from any external source, including CAs, HSMs, and peer TLS endpoints, without memory corruption or privilege escalation. If a crafted or garbage response from an external component triggers a buffer overflow, use-after-free, out-of-bounds read, or other memory-safety defect in wolfSSL code, that is a valid finding regardless of whether the source is trusted. + ## Out of Scope - Third-party libraries bundled by customers @@ -52,6 +76,8 @@ Security fixes are released for the current stable release and the immediately p ## Coordinated Disclosure +We do not pursue legal action against good-faith security researchers. We ask reporters to allow us reasonable time to develop and distribute a fix before public 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 @@ -60,15 +86,37 @@ Reporters are credited in the advisory and release notes unless anonymity is req Credit text is coordinated with the reporter before publication. +## Obligations Under the EU Cyber Resilience Act + +wolfSSL Inc. is a manufacturer under the EU Cyber Resilience Act, Regulation (EU) 2024/2847. + +Where a vulnerability in one of our products is actively exploited, Article 14 requires notification simultaneously to the CSIRT designated as coordinator and to ENISA, filed through the single reporting platform that ENISA operates under Article 16. The deadlines are an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. + +Article 14 applies from 11 September 2026. Under Article 69(3) it reaches products placed on the market before the Regulation's general application date of 11 December 2027. + +Once a corrective or mitigating measure is available, ENISA adds the notified vulnerability to the European Vulnerability Database, in agreement with the manufacturer, under Article 17(5). + +We provide security updates for the support period of each product (Article 13(8)) and document known vulnerabilities in our published advisories. + ## Contact -- **support@wolfssl.com** — security vulnerability reports and general support +- **support@wolfssl.com** — security vulnerability reports; monitored continuously +- **secure@wolfssl.com** — PGP-encrypted security reports - **facts@wolfssl.com** — general inquiries +Reports may be encrypted to the wolfSSL security key: + + Fingerprint: A2A4 8E7B CB96 C5BE CB98 7314 EBC8 0E41 5CA2 9677 + Key server: keys.openpgp.org + Armoured: https://www.wolfssl.com/.well-known/pgp-key.asc + 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. +Material changes to this policy are announced via the wolfSSL blog. + +This file is the canonical policy. Reporting addresses also appear in +; keep them in step. -*Last updated: 2026-04-22* +*Last updated: 2026-08-21* From 72f749472dcb89c8f42b8419606bf403431f61de Mon Sep 17 00:00:00 2001 From: Mark Atwood Date: Fri, 21 Aug 2026 15:59:57 -0700 Subject: [PATCH 2/4] docs: route vulnerability reports to secure@, not Zendesk support@wolfssl.com feeds the Zendesk support queue. Vulnerability reports, including embargoed ones, should not land there. secure@wolfssl.com is the security team address and is the only UID on the published PGP key. Reports go there; support@ is listed as general support only. --- .github/SECURITY.md | 5 ++--- SECURITY-POLICY.md | 6 +++--- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/.github/SECURITY.md b/.github/SECURITY.md index f01e3fd4fb0..f007fd3570d 100644 --- a/.github/SECURITY.md +++ b/.github/SECURITY.md @@ -7,9 +7,8 @@ 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. -Submit the completed template to **support@wolfssl.com**, monitored continuously. -To send it encrypted, use **secure@wolfssl.com** with the -[wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc): +Submit the completed template to **secure@wolfssl.com**, optionally encrypted to +the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc): Fingerprint: A2A4 8E7B CB96 C5BE CB98 7314 EBC8 0E41 5CA2 9677 Key server: keys.openpgp.org diff --git a/SECURITY-POLICY.md b/SECURITY-POLICY.md index d49b3fce16d..28f415e77cd 100644 --- a/SECURITY-POLICY.md +++ b/SECURITY-POLICY.md @@ -20,7 +20,7 @@ This policy covers security vulnerabilities in wolfSSL products distributed unde **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**, monitored continuously. To send it encrypted, use **secure@wolfssl.com** with the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc). +Submit the completed template to **secure@wolfssl.com**, optionally encrypted to the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc). This address reaches the security team directly and is the correct channel for anything under embargo. 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. @@ -100,8 +100,8 @@ We provide security updates for the support period of each product (Article 13(8 ## Contact -- **support@wolfssl.com** — security vulnerability reports; monitored continuously -- **secure@wolfssl.com** — PGP-encrypted security reports +- **secure@wolfssl.com** — security vulnerability reports +- **support@wolfssl.com** — general support; do not send embargoed reports here - **facts@wolfssl.com** — general inquiries Reports may be encrypted to the wolfSSL security key: From 07245317949c6f2511720670143da69acda2ebef Mon Sep 17 00:00:00 2001 From: Mark Atwood Date: Fri, 21 Aug 2026 16:11:25 -0700 Subject: [PATCH 3/4] docs: word the canonical-policy line to survive copying --- SECURITY-POLICY.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/SECURITY-POLICY.md b/SECURITY-POLICY.md index 28f415e77cd..483050d1b7f 100644 --- a/SECURITY-POLICY.md +++ b/SECURITY-POLICY.md @@ -116,7 +116,8 @@ Published CVE advisories: https://www.wolfssl.com/docs/security-vulnerabilities/ Material changes to this policy are announced via the wolfSSL blog. -This file is the canonical policy. Reporting addresses also appear in +The canonical policy is `SECURITY-POLICY.md` in the wolfSSL source +repository. Reporting addresses also appear in ; keep them in step. *Last updated: 2026-08-21* From 43ad27b2a99c459ceddf7bb0bb31be8c7429e33e Mon Sep 17 00:00:00 2001 From: Mark Atwood Date: Fri, 21 Aug 2026 16:13:09 -0700 Subject: [PATCH 4/4] docs: drop maintainer aside from published policy --- SECURITY-POLICY.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/SECURITY-POLICY.md b/SECURITY-POLICY.md index 483050d1b7f..b822b6de2ea 100644 --- a/SECURITY-POLICY.md +++ b/SECURITY-POLICY.md @@ -20,7 +20,7 @@ This policy covers security vulnerabilities in wolfSSL products distributed unde **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 **secure@wolfssl.com**, optionally encrypted to the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc). This address reaches the security team directly and is the correct channel for anything under embargo. +Submit the completed template to **secure@wolfssl.com**, optionally encrypted to the [wolfSSL security PGP key](https://www.wolfssl.com/.well-known/pgp-key.asc). Use this address for anything under embargo. 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. @@ -36,10 +36,10 @@ wolfSSL files a CVE advisory for defects with meaningful security impact on real 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 +- **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. @@ -78,7 +78,7 @@ Security fixes are released for the current stable release and the immediately p We do not pursue legal action against good-faith security researchers. We ask reporters to allow us reasonable time to develop and distribute a fix before public 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. +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 @@ -100,9 +100,9 @@ We provide security updates for the support period of each product (Article 13(8 ## Contact -- **secure@wolfssl.com** — security vulnerability reports -- **support@wolfssl.com** — general support; do not send embargoed reports here -- **facts@wolfssl.com** — general inquiries +- **secure@wolfssl.com**: security vulnerability reports +- **support@wolfssl.com**: general support; do not send embargoed reports here +- **facts@wolfssl.com**: general inquiries Reports may be encrypted to the wolfSSL security key: @@ -117,7 +117,7 @@ Published CVE advisories: https://www.wolfssl.com/docs/security-vulnerabilities/ Material changes to this policy are announced via the wolfSSL blog. The canonical policy is `SECURITY-POLICY.md` in the wolfSSL source -repository. Reporting addresses also appear in -; keep them in step. +repository. The reporting addresses are also published in +. *Last updated: 2026-08-21*