Vulnerability Disclosure Policy
HDF5 & Ecosystem
Report a Vulnerability
HDF5 Library: Submit via GitHub Security Advisories
Other HDF Projects: security@hdfgroup.org (PGP key available)
Introduction
The HDF Group’s goal is to make it safe and easy for users to report security issues, allow users to understand how and when they will be addressed, and then disclose the issue on a predictable schedule.
Safe Harbor
We support good-faith security research. We will not pursue legal action against researchers who follow this policy.
We will not pursue legal action against researchers who:
- Report vulnerabilities promptly and do not exploit them beyond proof-of-concept
- Do not perform denial of service attacks against production infrastructure
- Keep vulnerability details confidential until a fix is issued or the disclosure deadline passes
- Act in good faith and follow this policy
What to Include in Your Report
Please provide as much information as possible:
| Information | Description |
|---|---|
| Vulnerability Type | What kind of vulnerability is it? |
| Patch Status | Has the problem been patched? |
| Reproduction Steps | How can we reproduce the issue? Include POC files if available |
| Credit Preference | Would you like public credit? (Default: yes) |
| Additional Info | Any other relevant details |
Response Timeline
Standard Track
| Day | Action |
|---|---|
| Day 0 | Acknowledge report within 3 business days |
| Day 30 | Triage complete: validate, reproduce, plan fix, provide ETA |
| Day 90 | Fix released with security advisory (summary, affected versions, severity, mitigations, patches) |
| Day 120 | Full technical disclosure (root cause, PoC, diffs) |
Accelerated Track
For actively exploited vulnerabilities with credible evidence of exploitation in the wild:
| Day | Action |
|---|---|
| Day 0 | Acknowledge report within 1 business day |
| Day 3 | Triage complete |
| Day 7-10 | Fix released with full security advisory and technical details |
Please allow up to three days of grace period if a fix requires coordination.
Scope
In Scope:
- HDF5 library
- File format specs and validators
- Official plugins/connectors (VOL/VFD)
- HSDS
- HDFView
- Official tools (h5dump, h5stat, etc.)
- Build/packaging artifacts
- Documentation sites
- Distribution channels
Out of Scope:
- Third-party forks
- Community plugins not maintained by The HDF Group
Disclosure
We understand that reporters may wish to disclose issues publicly if they are not seeing movement on their issue. Please give us enough time to follow our security guidelines. If we have not met our own guidelines, then by day 120 you may publicly report the issue.
When We Assign CVEs
The HDF Group security team assigns a CVE ID to each confirmed vulnerability in products within our CNA scope, following the one-CVE-per-vulnerability rule. We assign the ID when a report is confirmed; we publish the CVE Record and advisory within seven days of a fix being released, or promptly upon public disclosure, whichever comes first. We practice Coordinated Vulnerability Disclosure (CVD) and ask reporters to maintain confidentiality while we work on a fix, typically aiming for a coordinated release within 90 days.
To help us triage and accurately describe vulnerabilities, reports should be submitted to either our security email or a security advisory report through Github and include affected versions, a minimal reproducer (e.g., a triggering file and tool invocation), build configuration, and observed impact.
Advisories are also summarized in our security newsletter. We update published CVE Records whenever new information — affected version ranges, severity, or corrections — becomes available.
When We Do Not Assign CVEs
The HDF Group security team does not assign CVE IDs for:
Products outside our CNA scope. Reports affecting software we do not maintain — including third-party bindings, wrappers, and downstream repackagings of HDF5 — should be directed to the responsible vendor or CNA. Where a vulnerability originates in a third-party dependency bundled with our products, we will coordinate with the upstream maintainer or CNA of Last Resort rather than assign a CVE ourselves. End-of-life versions. Vulnerabilities reproducible only in versions that have reached end of support do not receive new CVEs, unless the issue also affects a supported release. We will note EOL-only findings in advisories where doing so protects users. Bugs without a security impact. Defects that do not cross a trust boundary or violate a security property — incorrect results, resource-usage inefficiencies, build failures, or crashes that are triggerable only by the local user against their own data, with no plausible attacker — are handled through our normal issue-tracking process. Intended behavior and documented limitations. Behavior consistent with documented guarantees, including the absence of guarantees, is not a vulnerability. In cases of dispute, reporters may request a reassessment by providing a novel proof-of-concept demonstrating a security boundary violation.
Position on Malformed and Untrusted Files
HDF5 is routinely used to open files from untrusted sources, and we treat memory-safety violations reachable through crafted files as security vulnerabilities. Specifically: out-of-bounds writes, out-of-bounds reads, use-after-free, type confusion, and uncontrolled memory allocation triggered by parsing a malformed file are in scope for CVE assignment, because file contents constitute attacker-controlled input in common deployment scenarios.
A crash alone does not determine severity. A null-pointer dereference or controlled abort in a command-line tool such as h5dump is a denial-of-service attack against a single invocation and will typically be assessed as low severity; the same root cause, reachable through the library API in a long-running service, may be assessed as higher severity. We calculate severity ratings using the Common Vulnerability Scoring System (CVSS) standard. We assign the CVE to the root cause in the library, listing the tools affected via the shared code rather than issuing separate CVEs per tool.
Reports based solely on fuzzer output without triage (e.g., an ASAN log with no analysis of reachability or impact) may be deduplicated against known issues and consolidated: multiple test cases that exercise the same root cause receive a single CVE.
Coordination & Embargo
We will coordinate with major downstreams (Linux distros, HPC vendors, package registries) under brief embargoes consistent with the timelines above. Embargo breaks or active exploitation trigger the 7-day track immediately.
Questions?
Contact security@hdfgroup.org with any questions about this policy.