- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 10
- 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/strukturag/libde265
Products and areas 13
- CABAC entropy decoding and the context model machinery behind it
- In-loop filters, covering deblocking and sample adaptive offset
- NAL unit handling: the Annex B start-code scan, emulation-prevention byte removal and the unit header parse
- Parameter sets and every value derived from them. VPS, SPS and PPS, plus the picture dimensions, CTB sizes, tile layouts and scaling lists computed out of them
- Prediction: intra modes, inter prediction, motion vector derivation and the merge and AMVP candidate lists
- Reference picture set handling and the decoded picture buffer, including what happens when a stream refers to a picture that was never decoded
- Residual and coefficient decoding, transform and dequantisation, where loop counts come from the stream
- SEI message parsing and any other optional payload the decoder walks
- Slice segment headers, including the entry-point offsets that drive parallel decoding
- The parallel decoding paths: frame-level threading, wavefront parallel processing and tiles, and the shared state they touch
- The policy states what it accepts: memory safety defects in the decoder, crashes and hangs triggered by crafted H.265 bitstreams, and misuse of the public C API that leads to either. Everything below sits inside that
- The public C API (de265_new_decoder, de265_push_data, de265_decode, de265_get_next_picture and the rest), including the buffer lifetime contract libheif and other callers depend on
- The SIMD and assembly acceleration paths, which take different code for the same input
Out of scope (6)
- Container parsing, which belongs to libheif or to whichever demuxer produced the bitstream
- Distribution packaging and distro-specific patches
- Downstream players and integrations rather than the decoder itself
- Non-default build configurations the policy describes as unsafe, unless the same defect reaches a default build
- The experimental encoder, ruled out by name in the policy
- The sample and demo applications shipped with the source, also ruled out by name
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 GitHub private vulnerability reporting on strukturag/libde265, which the policy names as preferred, or by email to the address on the policy page as the documented fallback
-
Read the in-scope definition first. The policy wants memory safety in the decoder, crashes and hangs from crafted H.265 bitstreams, and public C API misuse that leads to either
-
The experimental encoder, the sample applications and non-default unsafe build configurations are all ruled out by name, so a finding there is not a security report
-
Attach the bitstream. Include whether it is raw Annex B or wrapped in a container, and which sample application or API sequence you used to feed it in
-
State the build: threading configuration, SIMD acceleration and compiler matter on a decoder, and a race only reproduces under the right thread count
-
Say whether the same input reaches the decoder through libheif's default HEIC path, because that answers the reachability question before anyone has to ask it
-
The policy commits to an advisory, a CVE request where appropriate and reporter credit, so say how you want to be named
Not accepted
-
The experimental encoder
-
The sample and demo applications
-
Non-default build configurations the policy describes as unsafe
-
Container parsing
-
Downstream players and integrations
-
Distribution packaging and distro-specific patches
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 10 CVEs, 10 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 10 Last 12 months 10 Lifetime Memory safety in decode 45 % Out-of-bounds access 25 % Crash or hang on crafted input 20 % Integer overflow 10 % Latest advisories Loading the feed Overview libde265 is an open H.265 decoder that reaches most of its users through images. libheif hands it every HEIC it opens, so libde265 is the code that runs when a Linux desktop views an iPhone photo or a server thumbnails an upload. A decoder consumes a bitstream the attacker controls completely, and every bounds check between that stream and the frame buffer is yours to break. The project publishes an unusually precise policy: memory safety in the decoder and crashes from crafted H.265 streams are what it wants, and it commits to an advisory and a CVE request. Ten advisories exist so far and none of them paid anything. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy states what it accepts: memory safety defects in the decoder, crashes and hangs triggered by crafted H.265 bitstreams, and misuse of the public C API that leads to either. Everything below sits inside that NAL unit handling: the Annex B start-code scan, emulation-prevention byte removal and the unit header parse Parameter sets and every value derived from them. VPS, SPS and PPS, plus the picture dimensions, CTB sizes, tile layouts and scaling lists computed out of them Slice segment headers, including the entry-point offsets that drive parallel decoding CABAC entropy decoding and the context model machinery behind it Residual and coefficient decoding, transform and dequantisation, where loop counts come from the stream Prediction: intra modes, inter prediction, motion vector derivation and the merge and AMVP candidate lists In-loop filters, covering deblocking and sample adaptive offset Reference picture set handling and the decoded picture buffer, including what happens when a stream refers to a picture that was never decoded The parallel decoding paths: frame-level threading, wavefront parallel processing and tiles, and the shared state they touch SEI message parsing and any other optional payload the decoder walks The SIMD and assembly acceleration paths, which take different code for the same input The public C API ( de265_new_decoder , de265_push_data , de265_decode , de265_get_next_picture and the rest), including the buffer lifetime contract libheif and other callers depend on Out of scope The experimental encoder, ruled out by name in the policy The sample and demo applications shipped with the source, also ruled out by name Non-default build configurations the policy describes as unsafe, unless the same defect reaches a default build Container parsing, which belongs to libheif or to whichever demuxer produced the bitstream Downstream players and integrations rather than the decoder itself Distribution packaging and distro-specific patches Most-valued findings Memory corruption in the decode loop reachable from a bitstream alone, with no unusual API sequence. That is exactly what the policy asks for and what the HEIC path delivers Arithmetic on values derived from SPS and PPS, where picture dimensions, CTB size and tile geometry produce an allocation the decode then overruns CABAC and coefficient parsing, where the stream drives loop counts and array indices directly Reference picture and DPB handling, particularly a stream that references a picture that does not exist, reaching uninitialised or already-released memory Races and shared-state corruption in the wavefront and tile threading paths, which fuzzers running single-threaded never touch Hangs and unbounded allocation from a small input, because libheif calls this synchronously inside server-side image processing Anything reachable through libheif's default HEIC path, since that is the configuration on every Linux desktop and in a large share of upload pipelines Divergence between the SIMD and reference paths, where the optimised routine writes past a bound the C version respects 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 GitHub private vulnerability reporting on strukturag/libde265, which the policy names as preferred, or by email to [email protected] as the documented fallback Read the in-scope definition first. The policy wants memory safety in the decoder, crashes and hangs from crafted H.265 bitstreams, and public C API misuse that leads to either The experimental encoder, the sample applications and non-default unsafe build configurations are all ruled out by name, so a finding there is not a security report Attach the bitstream. Include whether it is raw Annex B or wrapped in a container, and which sample application or API sequence you used to feed it in State the build: threading configuration, SIMD acceleration and compiler matter on a decoder, and a race only reproduces under the right thread count Say whether the same input reaches the decoder through libheif's default HEIC path, because that answers the reachability question before anyone has to ask it The policy commits to an advisory, a CVE request where appropriate and reporter credit, so say how you want to be named Disclosure Coordinated through GitHub private vulnerability reporting or maintainer email, then published as a GitHub Security Advisory with a CVE requested where the maintainer judges it appropriate, alongside a fix. The policy commits to that outcome and to crediting the reporter, which is more than most projects in this category put in writing. It sets no fixed embargo length, so agree the publication date with the maintainer once a fix is in hand. 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