- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 30
- 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/strukturag/libheif
Products and areas 13
- Auxiliary images, covering alpha planes, depth maps and thumbnails whose geometry can disagree with the primary image
- Colour information handling, including colr, NCLX parameters and embedded ICC profiles
- Image sequence handling, where per-frame structures multiply everything above
- Item location and extent resolution, where offsets and lengths declared in iloc decide what memory gets read
- Item properties and their association: ispe dimensions, pixi bit depths, clap cropping, irot and imir transforms, and the ipma index that binds properties to items
- Metadata items carried in the container, such as Exif and XMP payloads passed through to a consumer
- No written policy sets a scope. The private advisory channel on strukturag/libheif is enabled and demonstrably used, and it takes security defects anywhere in the upstream tree
- The bundled tools and loaders: heif-convert, heif-enc, heif-info and the GDK-Pixbuf loader shipped from this repository
- The decoder and encoder plugin interface, and specifically the shape of the data libheif hands across it to libde265, dav1d and the AV1 and VVC backends
- The encoding path, which matters because servers re-encode uploads rather than storing them untouched
- The ISOBMFF box parser end to end: ftyp, meta, hdlr, pitm, iinf, iloc, iref, idat and mdat, including size fields, extended sizes and truncated boxes
- The item reference graph and derived images: grids, overlays, identity transforms and tiled images assembled from many sub-images
- The public C API (heif_context_read_from_file, heif_context_read_from_memory and the decode calls), including the buffer and lifetime contract downstream callers rely on
Out of scope (5)
- Bugs that require a build configuration nobody ships, without a route to the same defect in a default build
- Defects inside the codec libraries themselves. A crash in libde265, dav1d, aom or x265 belongs to that project, and libde265 in particular runs its own disclosure process
- Distribution packaging and distro-specific patches rather than upstream libheif
- Downstream integrations such as GIMP, ImageMagick and libvips, which are maintained elsewhere
- Public GitHub issues used to report an unfixed memory-safety defect, when private reporting is enabled on the repository
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.
-
Report privately with the "Report a vulnerability" control at github.com/strukturag/libheif/security/advisories/new. The channel is enabled and the maintainers work it hard
-
There is no written policy behind that button, so no embargo window or response target is committed to anywhere. Propose your own timeline when you file
-
Attach the container. Box-level structure is the entire bug in this project and a prose description of the malformed box cannot be reproduced
-
Name the decoder plugin in play. libheif dispatches to libde265, dav1d, aom and others, and which one was built in changes the result
-
If the crash is inside the codec rather than inside libheif's container handling, it belongs to that codec's project. libde265 has its own policy and its own private channel
-
Check the advisory list first. Thirty are published and twenty-nine of them landed in 2026, so the obvious surfaces have had attention
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 30 CVEs, 30 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 30 Last 12 months 30 Lifetime Out-of-bounds access 40 % Integer overflow in geometry 25 % Memory corruption 20 % Resource exhaustion 15 % Latest advisories Loading the feed Overview libheif parses HEIF and HEIC, the container Apple made the default camera format, along with AVIF. On Linux it is the standard reader for both. GNOME and GIMP open a HEIC through it, ImageMagick and libvips pull it in, and every major distribution packages it, so this is the code that runs when a phone photo arrives at a server to be resized. Container parsing means acting on attacker-supplied box sizes and item offsets before a single pixel is decoded. Twenty-nine advisories were published against the project in 2026 alone, out of thirty in total. Nobody pays for any of them, so sorona.xyz pays you directly on qualified, reproduced findings. In scope No written policy sets a scope. The private advisory channel on strukturag/libheif is enabled and demonstrably used, and it takes security defects anywhere in the upstream tree The ISOBMFF box parser end to end: ftyp , meta , hdlr , pitm , iinf , iloc , iref , idat and mdat , including size fields, extended sizes and truncated boxes Item location and extent resolution, where offsets and lengths declared in iloc decide what memory gets read The item reference graph and derived images: grids, overlays, identity transforms and tiled images assembled from many sub-images Item properties and their association: ispe dimensions, pixi bit depths, clap cropping, irot and imir transforms, and the ipma index that binds properties to items Auxiliary images, covering alpha planes, depth maps and thumbnails whose geometry can disagree with the primary image Colour information handling, including colr , NCLX parameters and embedded ICC profiles Metadata items carried in the container, such as Exif and XMP payloads passed through to a consumer The decoder and encoder plugin interface, and specifically the shape of the data libheif hands across it to libde265, dav1d and the AV1 and VVC backends The encoding path, which matters because servers re-encode uploads rather than storing them untouched The public C API ( heif_context_read_from_file , heif_context_read_from_memory and the decode calls), including the buffer and lifetime contract downstream callers rely on The bundled tools and loaders: heif-convert , heif-enc , heif-info and the GDK-Pixbuf loader shipped from this repository Image sequence handling, where per-frame structures multiply everything above Out of scope Defects inside the codec libraries themselves. A crash in libde265, dav1d, aom or x265 belongs to that project, and libde265 in particular runs its own disclosure process Downstream integrations such as GIMP, ImageMagick and libvips, which are maintained elsewhere Distribution packaging and distro-specific patches rather than upstream libheif Bugs that require a build configuration nobody ships, without a route to the same defect in a default build Public GitHub issues used to report an unfixed memory-safety defect, when private reporting is enabled on the repository Most-valued findings Derived-image handling. Grids and overlays let a file declare a layout assembled from many sub-images with independent dimensions, and the arithmetic that reconciles them is the densest part of this codebase Extent resolution out of iloc , where an offset and a length taken from the file decide which bytes get read and copied Integer overflow in geometry arithmetic derived from ispe , pixi and tile counts, producing an allocation that the subsequent write outruns Property association indexing through ipma , where an index out of range reaches a property structure that was never parsed Auxiliary planes whose declared geometry contradicts the primary image, particularly alpha and depth, since consumers assume the two agree The plugin boundary, where libheif hands a codec a buffer whose size it computed from container fields the attacker wrote Unbounded allocation or non-terminating assembly from a small file, because this library sits inside synchronous server-side thumbnailing Anything reachable through the default HEIC path with the distro-standard plugin set, which is the configuration actually running in production 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. Report privately with the "Report a vulnerability" control at github.com/strukturag/libheif/security/advisories/new. The channel is enabled and the maintainers work it hard There is no written policy behind that button, so no embargo window or response target is committed to anywhere. Propose your own timeline when you file Attach the container. Box-level structure is the entire bug in this project and a prose description of the malformed box cannot be reproduced Name the decoder plugin in play. libheif dispatches to libde265, dav1d, aom and others, and which one was built in changes the result If the crash is inside the codec rather than inside libheif's container handling, it belongs to that codec's project. libde265 has its own policy and its own private channel Check the advisory list first. Thirty are published and twenty-nine of them landed in 2026, so the obvious surfaces have had attention Disclosure Coordinated through GitHub private vulnerability reporting and published as a GitHub Security Advisory alongside a release. The 2026 volume shows a maintainer team that triages and publishes steadily rather than in occasional batches, so expect your advisory to be timed to the next release. No policy document sets an embargo length or an acknowledgement target, so agree the publication date inside the advisory thread. 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