Excerpt: A new ecosystem-level audit identifies recurring failure classes, clarifies where authority and responsibility reside, and proposes a phased mitigation roadmap for HDF5 and its wider software and data ecosystem.
HDF5 is foundational infrastructure for science and engineering. It stores experimental observations, simulation results, images, models, sensor data, and long-lived scientific records. That reach makes a broad question such as “Is HDF5 secure?” too blunt to be useful.
Risk depends on the file, library version, enabled extensions, surrounding application, process privileges, deployment policy, storage environment, and data lifecycle.
The HDF Group and Lifeboat, LLC have released HDF5-SHINES-2026-001, the HDF5 Audit Report, written by Gerd Heber and Elena Pourmal.
The report is a targeted, ecosystem-level technical assessment of safety, security, and privacy. It examines the HDF5 file format and core library, official command-line tools, VOL connectors, filter plugins, VFDs, selected language bindings and applications, the upstream and downstream software supply chain, independent implementations, and long-term data accessibility.
It is not a certification, penetration test, exhaustive source review, or assurance opinion. Its findings apply to defined scenarios and boundaries, not to HDF5 as a technology or to every release and deployment.
What the audit found
The report’s central conclusion is simple:
HDF5 input is not necessarily inert data.
File-controlled metadata can influence allocation, traversal, external-file access, plugin loading, deserialization, storage behavior, and information disclosure. Understanding who supplies the authority is therefore as important as understanding who parses the bytes.
Patch defects, then eliminate the class. Historically, affected core-library and tool paths repeatedly failed to validate file-derived sizes, counts, offsets, and related state before using them in trusted C operations. Fixing each known defect is necessary. Preventing recurrence requires an explicit invariant registry, centralized checked arithmetic, validation before native object construction, structure-aware fuzzing, and permanent regression evidence.
Put controls where the authority resides. Applications can turn legitimate HDF5 features into attack mechanisms when they process untrusted files while holding authority that the file’s originator did not possess. Examples include access to local files, dynamic plugin loading, application deserialization, and large resource allocations. In these cases, the decisive control belongs at the application or deployment boundary, not automatically in the core parser.
Separate readability, conformance, and safety. A file opening successfully does not prove that it conforms to the specification. A stricter reader rejecting a file does not automatically prove a regression. A conforming file can still be unsafe for a deployment if its privileges or resource limits allow it to cause unintended effects.
Treat privacy as more than payload encryption. Privacy harm does not require an attacker or software defect. Object names, attributes, structural layout, provenance, external references, caches, logs, temporary files, and other workflow artifacts can expose sensitive context during normal, authorized operation. Protecting raw values alone does not necessarily protect the information carried by the full HDF5 artifact.
The audit also gives non-adversarial safety a distinct place. Storage exhaustion during a write, abrupt process or host termination, reader/writer disagreement, and the future disappearance of required non-core filters can leave data corrupted, unreadable, or uninterpretable, even when no one acted maliciously.
How to read the findings
The report registers 14 formal findings, seven Rated and seven Provisional. Four additional observations remain in an evidence backlog.
These numbers are navigation aids, not an HDF5-wide score or estimate of how common the conditions are. An evidence backlog also does not mean Low risk. It means the report lacks enough evidence to assign a defensible scenario rating.
The single Critical finding concerns a bounded downstream-service scenario in which file-selected external storage was combined with worker access to local files. It is not a Critical rating of HDF5. Its Immediate response route applies only to an equivalent deployment that remains exposed.
The report assigns no Immediate action to The HDF Group in this revision. Our near-term responsibilities include establishing affected scope, treating confirmed affected core and tool paths, cataloging candidate deserializer checks that may disappear from release builds, and improving operational containment for write-side failures.
From audit to mitigation
The report includes a phased roadmap, but no proposed mitigation should be read as already adopted or effective.
The roadmap combines immediate containment with longer-term prevention. Proposed work includes:
- deployment and version inventories;
- treatment of confirmed affected paths;
- explicit parser invariants and checked arithmetic;
- a decode, validate, construct, and separately authorize model;
- security profiles for trusted, untrusted, and forensic file access;
- structure-aware fuzzing and permanent regression corpora;
- governed plugin and extension loading;
- supply-chain and release controls;
- privacy minimization and lifecycle practices;
- dependency reporting and preservation planning for long-lived data.
The audit is not the end of the work. It provides a common evidence base, a vocabulary for discussing responsibility, and a proposed route from individual findings to durable controls.
Read the full report: https://www.hdfgroup.org/wp-content/uploads/2026/09/HDF5_SHINES_2026_001.pdf
Discuss the findings: https://forum.hdfgroup.org/t/released-the-hdf5-safety-security-privacy-audit/13877
Join the HDF5 SSP SIG: https://groups.io/g/hdf5-ssp-discuss
Report a vulnerability privately: https://github.com/HDFGroup/hdf5/security/advisories/new
We welcome evidence that confirms, narrows, contradicts, or extends the report. That includes deployment data, reproductions, recovery experience, interoperability cases, privacy examples, extension dependencies, and concrete offers to own or verify mitigation work.
Acknowledgment: This material is based upon work supported by the U.S. National Science Foundation under Federal Award No. 2534078. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.