- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 0
- 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, 6 excluded.
Web 1
- https://github.com/AOMediaCodec/libavif
Products and areas 13
- Alpha plane handling, including alpha declared with geometry that disagrees with the colour image, and premultiplied alpha conversion
- Colour conversion: YUV to RGB, bit-depth conversion, matrix coefficient handling and the libyuv wiring behind it
- Exif and XMP metadata items carried through the container and handed on to a consumer
- Gain map support and the extra image and metadata it introduces
- Grid and derived image assembly, where a single logical image comes from many independently declared cells
- Image geometry derived from the container: ispe dimensions, bit depth, chroma subsampling, clap cropping and the rotation and mirror properties
- Image sequence handling, where every per-item structure repeats per frame
- The AVIF container parser: the ISOBMFF boxes libavif reads directly, including meta, iinf, iloc, iref, iprp, ipco and ipma, along with item extents and truncated or oversized box handling
- The bundled tools, avifdec, avifenc and the gain map utility, which are what scripted pipelines call
- The codec adapter layer and the buffers libavif hands across it to libaom, dav1d, libgav1, rav1e and SVT-AV1
- The decoder API (avifDecoder and friends), including the incremental and streaming decode paths that consume partial input
- The encoding path, which is reachable wherever a server re-encodes an upload rather than storing it untouched
- The policy asks for anything found in libavif to arrive privately as a GitHub advisory with version, reproduction steps and impact, rather than as a public issue. It draws no boundary inside the library
Out of scope (6)
- crabbyavif, the separate Rust implementation Chromium now uses, which shares no code with this tree
- Defects inside the AV1 codecs themselves. libaom, dav1d, libgav1, rav1e and SVT-AV1 are separate projects with their own processes
- Distribution packaging and distro-specific patches rather than upstream libavif
- Downstream integrations such as GIMP, ImageMagick and libvips
- libyuv and other third-party libraries libavif links, unless libavif's own use of them is what makes the defect reachable
- Public issue reports for an unfixed vulnerability, which the policy asks you not to file
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 at github.com/AOMediaCodec/libavif/security/advisories/new. The policy asks you not to disclose it as a public issue
-
Include what the policy asks for: the version, the reproduction steps and the impact
-
The policy requests a 90-day embargo, so plan for that window and say up front if your own disclosure deadline is shorter
-
Name the codec backend. libavif dispatches to libaom, dav1d, libgav1, rav1e or SVT-AV1 depending on the build, and which one was compiled in changes what happens
-
State whether the defect lives in libavif's container and geometry handling or inside the AV1 codec. Only the first is this project's code
-
Do not report against crabbyavif and call it libavif. Chromium's AVIF decoding moved to that separate Rust project, and the two share no code
Not accepted
-
Defects inside the AV1 codecs themselves
-
crabbyavif, the separate Rust implementation Chromium now uses, which shares no code with this tree
-
libyuv and other third-party libraries libavif links, unless libavif's own use of them is what makes the defect reachable
-
Downstream integrations such as GIMP, ImageMagick and libvips
-
Distribution packaging and distro-specific patches rather than upstream libavif
-
Public issue reports for an unfixed vulnerability
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.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
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 Latest advisories Loading the feed Overview libavif is the reference AVIF implementation from the Alliance for Open Media, and it is how most non-browser software reads AV1 images. GIMP, ImageMagick, libvips and the distro image tooling all link it. Browsers used to be the loudest consumer. Chromium now pulls a Rust decoder called crabbyavif instead, which removed the one route by which a bug in this C code could earn a reward while leaving every server-side and desktop caller exactly where it was. The project asks for private reports and a ninety-day embargo, and has published no advisories yet. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for anything found in libavif to arrive privately as a GitHub advisory with version, reproduction steps and impact, rather than as a public issue. It draws no boundary inside the library The AVIF container parser: the ISOBMFF boxes libavif reads directly, including meta , iinf , iloc , iref , iprp , ipco and ipma , along with item extents and truncated or oversized box handling Image geometry derived from the container: ispe dimensions, bit depth, chroma subsampling, clap cropping and the rotation and mirror properties Grid and derived image assembly, where a single logical image comes from many independently declared cells The decoder API ( avifDecoder and friends), including the incremental and streaming decode paths that consume partial input The codec adapter layer and the buffers libavif hands across it to libaom, dav1d, libgav1, rav1e and SVT-AV1 Alpha plane handling, including alpha declared with geometry that disagrees with the colour image, and premultiplied alpha conversion Gain map support and the extra image and metadata it introduces Colour conversion: YUV to RGB, bit-depth conversion, matrix coefficient handling and the libyuv wiring behind it The encoding path, which is reachable wherever a server re-encodes an upload rather than storing it untouched Image sequence handling, where every per-item structure repeats per frame The bundled tools, avifdec , avifenc and the gain map utility, which are what scripted pipelines call Exif and XMP metadata items carried through the container and handed on to a consumer Out of scope Defects inside the AV1 codecs themselves. libaom, dav1d, libgav1, rav1e and SVT-AV1 are separate projects with their own processes crabbyavif, the separate Rust implementation Chromium now uses, which shares no code with this tree libyuv and other third-party libraries libavif links, unless libavif's own use of them is what makes the defect reachable Downstream integrations such as GIMP, ImageMagick and libvips Distribution packaging and distro-specific patches rather than upstream libavif Public issue reports for an unfixed vulnerability, which the policy asks you not to file Most-valued findings Integer overflow in geometry arithmetic. Width, height, bit depth, plane strides and grid cell counts all come from the file and all feed allocation sizes, and this is the classic AVIF bug shape Item extent and offset handling in the container parser, where the file decides which bytes get read and how many Grid assembly, where cells with mismatched dimensions, depths or subsampling get composited into one buffer The boundary where libavif hands a codec a buffer sized from container fields, since a disagreement between the two sides is written by the codec and never checked again Alpha and gain map planes whose declared geometry contradicts the primary image, a surface that gets a fraction of the attention the colour path receives The incremental decode path, which parses partial input and is exercised far less than a whole-file decode Colour conversion with attacker-chosen bit depth, range and matrix, where the arithmetic changes shape per combination Anything in the encoder reachable from an attacker-supplied input image, because re-encoding uploads is the common server-side pattern Nothing here has been picked over in public. There are no published advisories against this repository, so the ordinary decode surface is a genuinely open field 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 at github.com/AOMediaCodec/libavif/security/advisories/new. The policy asks you not to disclose it as a public issue Include what the policy asks for: the version, the reproduction steps and the impact The policy requests a 90-day embargo, so plan for that window and say up front if your own disclosure deadline is shorter Name the codec backend. libavif dispatches to libaom, dav1d, libgav1, rav1e or SVT-AV1 depending on the build, and which one was compiled in changes what happens State whether the defect lives in libavif's container and geometry handling or inside the AV1 codec. Only the first is this project's code Do not report against crabbyavif and call it libavif. Chromium's AVIF decoding moved to that separate Rust project, and the two share no code No advisories have been published from this repository yet, so the process is documented rather than exercised. Expect to help the maintainers work the mechanics as well as the bug Disclosure Coordinated privately through a GitHub security advisory on the AOMediaCodec repository, with a ninety-day embargo requested in the policy. Nothing has been published through that channel so far, so there is no cadence to read and no acknowledgement time on record. Treat the ninety days as the stated expectation, confirm receipt early, and settle the publication date in the advisory thread rather than assuming the process will run itself. 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