- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 31
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
14 assets you may test, 5 excluded.
Web 1
- https://github.com/AcademySoftwareFoundation/openexr
Products and areas 13
- Deep data, both scanline and tiled, where per-pixel sample counts come from the file and are unbounded on their face
- Every compression codec in the tree: ZIP and ZIPS, RLE, PIZ, PXR24, B44 and B44A, and DWAA and DWAB
- Header and attribute parsing: the attribute type registry, channel lists, string and string-vector attributes, chromaticities, and custom attributes whose declared size comes from the file
- Multi-part files, covering part headers, per-part types and the shared offset structure across them
- The C core library added in 3.x, which is what most new callers link and which does its own parsing
- The chunk offset tables that tell the reader where every scanline block or tile lives
- The C++ layer above it, including the input file classes for scanline, tiled, deep and multi-part reads
- The command-line tools, exrheader, exrinfo, exrmaketiled and the rest, which run unattended in asset pipelines
- The memory limits and allocation guards the library applies before reading a declared size
- The policy accepts vulnerability reports through a GitHub security advisory or [email protected], commits to acknowledging receipt, and even sets out how it handles flaws inherited from upstream dependencies. It draws no component boundary inside the project
- The Python bindings shipped from this repository
- The threading layer and the task pool, including anything that goes wrong when a decode fails on one thread
- Tiled reading, including mipmap and ripmap levels and the level-size arithmetic behind them
Out of scope (5)
- Defects inside a dependency itself, such as Imath or the underlying compression library. The policy covers coordination for inherited flaws, and the fix belongs upstream
- Distribution packaging and distro-specific patches rather than the upstream tree
- Downstream consumers that link OpenEXR, including OpenCV, Blender and Nuke, and other Academy Software Foundation projects with their own repositories
- Memory exhaustion from a large but entirely well-formed file, where the caller ran with limits deliberately disabled
- Public GitHub issues used to report an unfixed vulnerability, when the private advisory route is documented at length
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
File a GitHub security advisory on the OpenEXR repository, which is the primary route the policy sets out
-
Use the address on the policy page if you cannot use GitHub. The policy tells you to escalate if that address does not acknowledge you, so hold it to that
-
Attach the EXR. Compression method, channel layout and part count are the bug in most of these findings and cannot be described accurately in prose
-
Say which API you came in through: the C core, the C++ layer, one of the command-line tools, or a consumer such as OpenCV
-
Check the advisory list before filing. Thirty-one are published and most of them landed in 2026, so the obvious decompressor surfaces have had recent attention
Not accepted
-
Defects inside a dependency itself, such as Imath or the underlying compression library
-
Memory exhaustion from a large but entirely well-formed file, where the caller ran with limits deliberately disabled
-
Distribution packaging and distro-specific patches rather than the upstream tree
-
Public GitHub issues used to report an unfixed vulnerability, when the private advisory route is documented at length
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
Sorona credits this project with 31 CVEs, 31 of them recent. The individual records appear here after the next sync.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 31 Last 12 months 31 Lifetime Memory safety in decompression 45 % Integer overflow in chunk geometry 25 % Out-of-bounds read 20 % Resource exhaustion 10 % Latest advisories Loading the feed Overview OpenEXR is the HDR image format the film industry standardised on, and the library that reads it is linked into far more than film tooling. OpenCV pulls it in, Blender and Nuke read it, and every major distribution packages it, so an EXR arriving at a render farm or an asset pipeline is parsed by this code. The format carries many compressed channels across tiled, deep and multi-part layouts, giving a crafted file plenty of arithmetic to poison before decompression even starts. Twenty-four advisories were published in 2026 alone, out of thirty-one in total. The Academy Software Foundation runs a formal security process with no money in it. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy accepts vulnerability reports through a GitHub security advisory or [email protected] , commits to acknowledging receipt, and even sets out how it handles flaws inherited from upstream dependencies. It draws no component boundary inside the project The C core library added in 3.x, which is what most new callers link and which does its own parsing The C++ layer above it, including the input file classes for scanline, tiled, deep and multi-part reads Header and attribute parsing: the attribute type registry, channel lists, string and string-vector attributes, chromaticities, and custom attributes whose declared size comes from the file The chunk offset tables that tell the reader where every scanline block or tile lives Every compression codec in the tree: ZIP and ZIPS, RLE, PIZ, PXR24, B44 and B44A, and DWAA and DWAB Tiled reading, including mipmap and ripmap levels and the level-size arithmetic behind them Deep data, both scanline and tiled, where per-pixel sample counts come from the file and are unbounded on their face Multi-part files, covering part headers, per-part types and the shared offset structure across them The threading layer and the task pool, including anything that goes wrong when a decode fails on one thread The memory limits and allocation guards the library applies before reading a declared size The command-line tools, exrheader , exrinfo , exrmaketiled and the rest, which run unattended in asset pipelines The Python bindings shipped from this repository Out of scope Defects inside a dependency itself, such as Imath or the underlying compression library. The policy covers coordination for inherited flaws, and the fix belongs upstream Downstream consumers that link OpenEXR, including OpenCV, Blender and Nuke, and other Academy Software Foundation projects with their own repositories Memory exhaustion from a large but entirely well-formed file, where the caller ran with limits deliberately disabled Distribution packaging and distro-specific patches rather than the upstream tree Public GitHub issues used to report an unfixed vulnerability, when the private advisory route is documented at length Most-valued findings The decompressors. PIZ Huffman decoding, the DWA paths and B44 all take compressed sizes and symbol tables straight from the file, and this is where the density of the record sits Integer overflow in chunk, tile and scanline geometry, where a header that passes validation yields an allocation the decompressor then overruns Deep data handling, where per-pixel sample counts are attacker-declared and the multiplication into a buffer size is the whole attack Attribute parsing with attacker-declared sizes, including custom attribute types the reader walks without knowing what they are Chunk offset tables pointing outside the file or overlapping in ways the reader does not expect Multi-part files where one part's header contradicts another's, since the cross-part consistency checks are newer than the single-part ones Uninitialised memory reaching output pixels, which in a render farm means process memory leaving in a rendered frame Non-terminating decode or unbounded allocation from a small file, because these libraries run unattended over thousands of frames with no human watching the job Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. File a GitHub security advisory on the OpenEXR repository, which is the primary route the policy sets out Use [email protected] if you cannot use GitHub. The policy tells you to escalate if that address does not acknowledge you, so hold it to that The policy commits to acknowledging receipt, so a silent thread is a reason to follow up rather than to assume the report is being worked Attach the EXR. Compression method, channel layout and part count are the bug in most of these findings and cannot be described accurately in prose Say which API you came in through: the C core, the C++ layer, one of the command-line tools, or a consumer such as OpenCV The policy has a section on flaws inherited from upstream dependencies. If the defect is really in a compression library or in Imath, say so and expect coordination rather than a fix in this tree Check the advisory list before filing. Thirty-one are published and most of them landed in 2026, so the obvious decompressor surfaces have had recent attention Disclosure Coordinated through a GitHub security advisory or the project security address, then published as a GitHub Security Advisory with a CVE alongside a release. The 2026 volume shows a security team that triages and publishes steadily rather than occasionally. The policy sets out the process at length, commits to acknowledging receipt and covers inherited upstream flaws, without fixing a single embargo length, so agree the publication date in the advisory thread and expect it to track the next release. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability