<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Copyright (c) Contributors to the OpenEXR Project -->

# Security Policy

## Reporting a Vulnerability

If you think you've found a potential vulnerability in OpenEXR, please
report it by filing a GitHub [security
advisory](https://github.com/AcademySoftwareFoundation/openexr/security/advisories/new). Alternatively,
email security@openexr.com and provide your contact info for further
private/secure discussion.  If your email does not receive a prompt
acknowledgement, your address may be blocked.

Our policy is to acknowledge the receipt of vulnerability reports
within 48 hours. Our policy is to address critical security vulnerabilities
rapidly and post patches within 14 days if possible.

## CVE Assignment

We request a CVE when an untrusted party can plausibly trigger the flaw
through normal product inputs (for example, a crafted EXR or other data
the application is meant to process); otherwise we treat it as a regular
bugfix, document it in a GitHub security advisory or release notes when
helpful, and do not request a CVE for API-only or caller-controlled
failures with no realistic adversarial path.

Flaws whose root cause lies in a bundled dependency (such as OpenJPH)
are fixed upstream; the upstream project owns the CVE when one is
warranted.  Note that this applies even when a flaw is detected in
dependency code vendored into OpenEXR's `external/` source directory.
OpenEXR addresses them by updating the dependency and noting the
upstream advisory in release notes. We request a CVE for OpenEXR
itself only when the flaw is in our code and untrusted input can reach
it through normal use of the library.

## Known Vulnerabilities

| CVE | Affected Versions | Patched Versions |
| --- | ----------------- | ---------------- |

| [CVE-2026-42217](https://www.cve.org/CVERecord?id=CVE-2026-42217) | 3.2.0–3.2.8, 3.3.0–3.3.10, 3.4.0–3.4.10 | 3.2.9, 3.3.11, 3.4.11 |
| [CVE-2026-42216](https://www.cve.org/CVERecord?id=CVE-2026-42216) | 3.2.0–3.2.8, 3.3.0–3.3.10, 3.4.0–3.4.10 | 3.2.9, 3.3.11, 3.4.11 |
| [CVE-2026-41142](https://www.cve.org/CVERecord?id=CVE-2026-41142) | 3.2.0–3.2.8, 3.3.0–3.3.10, 3.4.0–3.4.10 | 3.2.9, 3.3.11, 3.4.11 |
| [CVE-2026-40250](https://www.cve.org/CVERecord?id=CVE-2026-40250) | 3.2.0–3.2.7, 3.3.0–3.3.9, 3.4.0–3.4.9 | 3.2.8, 3.3.10, 3.4.10 |
| [CVE-2026-40244](https://www.cve.org/CVERecord?id=CVE-2026-40244) | 3.2.0–3.2.7, 3.3.0–3.3.9, 3.4.0–3.4.9 | 3.2.8, 3.3.10, 3.4.10 |
| [CVE-2026-39886](https://www.cve.org/CVERecord?id=CVE-2026-39886) | 3.4.0–3.4.9 | 3.4.10 |
| [CVE-2026-34589](https://www.cve.org/CVERecord?id=CVE-2026-34589) | 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.8 | 3.2.7, 3.3.9, 3.4.9 |
| [CVE-2026-34588](https://www.cve.org/CVERecord?id=CVE-2026-34588) | 3.1.x, 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.8 | 3.2.7, 3.3.9, 3.4.9 |
| [CVE-2026-34545](https://www.cve.org/CVERecord?id=CVE-2026-34545) | 3.4.0–3.4.6 | 3.4.7 |
| [CVE-2026-34544](https://www.cve.org/CVERecord?id=CVE-2026-34544) | 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.7 | 3.2.7, 3.3.9, 3.4.8 |
| [CVE-2026-34543](https://www.cve.org/CVERecord?id=CVE-2026-34543) | 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.7 | 3.2.7, 3.3.9, 3.4.8 |
| [CVE-2026-34380](https://www.cve.org/CVERecord?id=CVE-2026-34380) | 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.8 | 3.2.7, 3.3.9, 3.4.9 |
| [CVE-2026-34379](https://www.cve.org/CVERecord?id=CVE-2026-34379) | 3.2.0–3.2.6, 3.3.0–3.3.8, 3.4.0–3.4.8 | 3.2.7, 3.3.9, 3.4.9 |
| [CVE-2026-34378](https://www.cve.org/CVERecord?id=CVE-2026-34378) | 3.4.0–3.4.8 | 3.4.9 |
| [CVE-2026-27622](https://www.cve.org/CVERecord?id=CVE-2026-27622) | 2.x, 3.0.x, 3.1.x, 3.2.0–3.2.5, 3.3.0–3.3.7, 3.4.0–3.4.5 | 3.2.6, 3.3.8, 3.4.6 |
| [CVE-2026-26981](https://www.cve.org/CVERecord?id=CVE-2026-26981) | 3.3.0–3.3.6, 3.4.0–3.4.4 | 3.3.7, 3.4.5 |
| [CVE-2025-64183](https://www.cve.org/CVERecord?id=CVE-2025-64183) | 3.2.0–3.2.4, 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.2.5, 3.3.6, 3.4.3 |
| [CVE-2025-64182](https://www.cve.org/CVERecord?id=CVE-2025-64182) | 3.2.0–3.2.4, 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.2.5, 3.3.6, 3.4.3 |
| [CVE-2025-64181](https://www.cve.org/CVERecord?id=CVE-2025-64181) | 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.3.6, 3.4.3 |
| [CVE-2025-48074](https://www.cve.org/CVERecord?id=CVE-2025-48074) | 3.3.2 | 3.3.3 |
| [CVE-2025-48073](https://www.cve.org/CVERecord?id=CVE-2025-48073) | 3.3.2 | 3.3.3 |
| [CVE-2025-48072](https://www.cve.org/CVERecord?id=CVE-2025-48072) | 3.3.2 | 3.3.3 |
| [CVE-2025-48071](https://www.cve.org/CVERecord?id=CVE-2025-48071) | 3.3.0–3.3.2 | 3.3.3 |
| [CVE-2025-12840](https://www.cve.org/CVERecord?id=CVE-2025-12840) | 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.3.6, 3.4.3 |
| [CVE-2025-12839](https://www.cve.org/CVERecord?id=CVE-2025-12839) | 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.3.6, 3.4.3 |
| [CVE-2025-12495](https://www.cve.org/CVERecord?id=CVE-2025-12495) | 3.3.0–3.3.5, 3.4.0–3.4.2 | 3.3.6, 3.4.3 |
| [CVE-2023-5841](https://nvd.nist.gov/vuln/detail/CVE-2023-5841) | 3.1.0–3.1.11, 3.2.0–3.2.1 | 3.2.2 |
| [CVE-2021-45942](https://nvd.nist.gov/vuln/detail/CVE-2021-45942) | 3.1.0–3.1.3 | 3.1.4 |
| [CVE-2021-20296](https://nvd.nist.gov/vuln/detail/CVE-2021-20296) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3479](https://nvd.nist.gov/vuln/detail/CVE-2021-3479) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3478](https://nvd.nist.gov/vuln/detail/CVE-2021-3478) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3477](https://nvd.nist.gov/vuln/detail/CVE-2021-3477) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3476](https://nvd.nist.gov/vuln/detail/CVE-2021-3476) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3475](https://nvd.nist.gov/vuln/detail/CVE-2021-3475) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2021-3474](https://nvd.nist.gov/vuln/detail/CVE-2021-3474) | 2.4.0–2.4.2, 2.5.0–2.5.3 | 2.4.3, 2.5.4 |
| [CVE-2020-16589](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16589) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0 | 2.4.0 |
| [CVE-2020-16588](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16588) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0 | 2.4.0 |
| [CVE-2020-16587](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16587) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0 | 2.4.0 |
| [CVE-2020-15306](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15306) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0–2.4.1, 2.5.0–2.5.1 | 2.5.2 |
| [CVE-2020-15305](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15305) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0–2.4.1, 2.5.0–2.5.1 | 2.5.2 |
| [CVE-2020-15304](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15304) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0–2.4.1, 2.5.0–2.5.1 | 2.5.2 |
| [CVE-2020-11765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11765) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11764](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11764) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11763) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11762](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11762) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11761](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11761) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11760](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11760) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11759](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11759) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2020-11758](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11758) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0, 2.4.0 | 2.4.1 |
| [CVE-2018-18444](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18444) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0 | 2.4.0 |
| [CVE-2018-18443](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18443) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1, 2.3.0 | 2.4.0 |
| [CVE-2017-9116](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9116) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9115](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9115) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9114](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9114) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9113](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9113) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9112](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9112) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9111](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9111) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-9110](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9110) | 2.0.0–2.0.1, 2.1.0, 2.2.0 | 2.2.1 |
| [CVE-2017-12596](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12596) | 2.0.0–2.0.1, 2.1.0, 2.2.0–2.2.1 | 2.3.0 |
| [CVE-2009-1722](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1722) | 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x, 1.5.x, 1.6.x | 1.7.0 |
| [CVE-2009-1721](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1721) | 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x, 1.5.x, 1.6.x | 1.7.0 |
| [CVE-2009-1720](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1720) | 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x, 1.5.x, 1.6.x | 1.7.0 |

See the [release notes](CHANGES.md) for more information.

## Supported Versions

This gives guidance about which releases/branches are supported with bug fixes and patches to
security vulnerabilities.

| Version / branch  | Supported                                            |
|-------| ---------------------------------------------------- |
| main  | :white_check_mark: :construction: All fixes immediately, although this branch is under development with potential unstable ABI/API
| 3.4.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility
| 3.3.x | :white_check_mark: All fixes that can be backported without breaking ABI compatibility
| 3.2.x | :warning: Patch releases considered in response to specific requests
| 3.1.x | :warning: Patch releases considered in response to specific requests
| 3.0.x | :warning: Patch releases considered in response to specific requests
| 2.5.x | :warning: Patch releases considered in response to specific requests
| 2.4.x | :warning: Patch releases considered in response to specific requests
| 2.3.x | :x: No longer receiving patches of any kind
| 2.2.x | :x: No longer receiving patches of any kind
| 2.1.x | :x: No longer receiving patches of any kind
| 2.0.x | :x: No longer receiving patches of any kind
| 1.x   | :x: No longer receiving patches of any kind

## Signed Releases

Releases artifacts are signed via
[sigstore](https://www.sigstore.dev). See
[release-sign.yml](.github/workflows/release-sign.yml) for details.

To verify a downloaded release at a given tag:

    % pip install sigstore
    % sigstore verify github --cert-identity https://github.com/AcademySoftwareFoundation/openexr/.github/workflows/release-sign.yml@refs/tags/<tag> openexr-<tag>.tar.gz

## Security Expectations

### Software Features

- The OpenEXR project implements the EXR image file format, used
  throughout the motion picture industry and beyond, on Linux, macOS,
  and Windows.

- The project consists of a software run-time library, implemented in
  C/C++ and built via cmake, that reads and writes image data
  files. The project also distributes python wrappings for the C/C++
  I/O API.

- The library reads and writes binary image data and text-based
  metadata, treated as blind data, none of which is executable code.

- Other than the website and online technical documentation, the
  project implements no web/online services or network communication
  protocols.  The library never requests any security or
  authentication credentials or login information from users.

  The website implements no interactive features and requires no login
  credentials.

- The library reads and writes only to file paths specifically requested
  via the C/C++ API. The runtime library uses no system configuration
  files or sidecar data files. Access to data files uses only standard
  file I/O system calls.

- The library compresses/decompresses data via standard compression
  algorithms but uses no cryptographic or confidentiality protocols.

### Software Dependencies

OpenEXR depends on
[Imath](https://github.com/AcademySoftwareFoundation/Imath), a library
of basic math operations also maintained and distributed by the
OpenEXR project. Imath follows the same security conventions
documented here for OpenEXR itself. The core Imath library has no
external dependencies. The Imath python bindings depend on python and
boost.

The only
external library dependency of OpenEXR is
[libdeflate](https://github.com/ebiggers/libdeflate), which implements
standard deflate/zlib/gzip compression and decompression.

The project uses
[Snyk](https://github.com/AcademySoftwareFoundation/openexr/blob/main/.github/workflows/snyk-scan-pr.yml)
to scan for dependency vulnerability.

### Potential Vulnerabilities

Potential entry points are images being loaded using the
library. Malformed images could caused issues such as heap buffer
overflows, out-of-memory faults, or segmentation faults that could be
exploitable as denial-of-service attacks.

### Image Size Limits and Out-of-Memory Failures

The OpenEXR file format places no fixed limit on image size, except
that image width and height are represented by signed 32-bit integers
and therefore technically limited to a maximum of 2,147,483,647.

Memory allocation failures caused by large image dimensions declared
in file headers are not considered security vulnerabilities when the
allocation size is proportional to the declared image dimensions. EXR
files can legitimately describe very large images, and the memory
required to decode them is inherently proportional to their pixel
count. Exhausting available memory on a given machine is a system
resource constraint, not a library defect — the same file that
triggers an out-of-memory error on one machine may load successfully
on another with more memory.

The OpenEXR library provides 
`Imf::Header::setMaxImageSize(int maxWidth,int maxHeight)` and
`Imf::Header:"setMaxTileSize(int maxWidth,int maxHeight)` (and
`exr_set_default_maximum_image_size()` and
`exr_set_default_maximum_tile_size()` in OpenEXRCore) to allow
applications to reject files with dimensions exceeding a configurable
limit before any large allocation occurs. Applications processing
untrusted EXR files should set these limits to values appropriate for
their deployment environment.

### Hardening

#### Testing

The OpenEXR project implements a comprehensive suite of validation
tests, including fuzz testing to harden against malicious input
data. Note that fuzz testing hardens only against *small* input data
files and is not a comprehensive test against all potential input.

Note that the
[exrcheck](https://github.com/AcademySoftwareFoundation/openexr/tree/main/src/bin/exrcheck)
utility is intended to be used by testers to demonstrate a particular
proof-of-concept input file exposes a vulnerability, and it is very
helpful to let us know if a vulnerability can be reproduced using that
tool.

The project also uses the [OSS
Fuzz](https://bugs.chromium.org/p/oss-fuzz) service for continuous
fuzz testing.

#### Development Cycle and Distribution

OpenEXR is downloadable and buildable by C/C++ source via GitHub. Only
members of the project's Technical Steering Committee, all veteran
software engineers at major motion picture studios or vendors, have
write permissions on the source code repository. All critical software
changes are reviewed by multiple TSC members.

The library is distributed in binary form via many common package
managers across all platforms.
