Skip to content

GPAC

Bug bounty on Sorona gpac.io

Accepting reports open-source
Top reward
$1,500
Top severity paid
Critical
Assets in scope
12
Public CVEs
425
Last change
No changes yet

At a glance

What to know before you start testing.

Pays from $1,500
for critical bugs.
Partial safe harbor
Some legal protection; read the terms.
Public disclosure allowed
You may publish your report.

Rewards

What Sorona lists as the payout for each severity.

Severity 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

12 assets you may test, 5 excluded.

Web 1

  • https://gpac.io

Products and areas 11

  • Codec bitstream parsing where GPAC does it itself: AVC, HEVC, AV1 and VVC parameter sets and their inspection paths
  • Demuxers for the other containers GPAC reads, covering MPEG-2 TS, AVI, Matroska and the raw elementary stream readers
  • Encryption and DRM handling: CENC, key management and the encrypted-media paths
  • MP4Box itself, every option it accepts and every file it will open on the strength of one
  • Network-facing code: the DASH and HLS clients, HTTP handling and the RTP and RTSP stack
  • Subtitle and caption handling, including the VobSub index reader and the timed-text formats
  • The DASH, HLS and CMAF segmenters, plus the manifest parsers on the client side: MPD, m3u8 and Smooth Streaming index parsing
  • The filter session and the whole filter graph, including how filters are linked and how buffers move between them
  • The ISOBMFF and MP4 layer in libgpac: box parsing, sample tables, fragmented MP4 and the movie fragment index
  • The player and the bindings, covering the gpac player, the Node and Python interfaces and anything that drives libgpac programmatically
  • The policy takes vulnerability reports through the public issue tracker by default and through [email protected] where openness is inappropriate. It names no component boundary, so the whole toolkit is in
Out of scope (5)
  • Bugs in third-party libraries GPAC links against rather than in GPAC's own code
  • Distribution packaging rather than upstream code
  • Format-support gaps and files GPAC simply refuses to open
  • Isolated overflows produced by a fuzzer that do not lead to a crash, ruled out by name in the policy
  • Requests for a project-assigned CVE, since GPAC states it does not assign them

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz.
  • Use the private address when the finding is exploitable rather than a crash
  • Attach the input file and the exact MP4Box or gpac command line.
  • GPAC does not assign CVEs. If you want an identifier you request it from MITRE yourself
  • The project does not use GitHub Security Advisories, so expect the fix in a commit and a release rather than in a published advisory

Not accepted

  • Isolated overflows produced by a fuzzer that do not lead to a crash
  • Bugs in third-party libraries GPAC links against rather than in GPAC's own code
  • Requests for a project-assigned CVE
  • Format-support gaps and files GPAC simply refuses to open
  • Distribution packaging rather than upstream code
  • isolated overflows generated by fuzzers that do not lead to a crash

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.

Search NVD
CVESeverityPublished
CVE-2026-79522 Medium 6.5 9 Sep 2026
CVE-2026-79513 Medium 6.5 9 Sep 2026
CVE-2026-79514 Medium 6.5 9 Sep 2026
CVE-2025-60464 High 7.8 25 Jun 2026
CVE-2025-60465 Medium 6.1 25 Jun 2026
CVE-2025-60466 Medium 5.0 25 Jun 2026
CVE-2025-60473 Medium 5.5 25 Jun 2026
CVE-2025-60467 High 7.5 24 Jun 2026
CVE-2025-60474 High 7.5 24 Jun 2026
CVE-2025-60468 Medium 5.5 24 Jun 2026
CVE-2025-60471 Medium 5.5 24 Jun 2026
CVE-2025-55639 Medium 6.5 23 Jun 2026
CVE-2025-55648 Medium 5.5 15 Jun 2026
CVE-2025-55649 Medium 5.5 15 Jun 2026
CVE-2025-55650 Medium 5.5 15 Jun 2026
CVE-2025-55652 Medium 5.5 15 Jun 2026
CVE-2025-55660 Medium 5.5 15 Jun 2026
CVE-2025-55661 Medium 5.5 15 Jun 2026
CVE-2025-55663 Medium 5.5 15 Jun 2026
CVE-2025-55645 Medium 5.5 15 Jun 2026
CVE-2025-55647 Medium 5.5 15 Jun 2026
CVE-2025-55641 Medium 5.5 15 Jun 2026
CVE-2025-55642 Medium 6.5 15 Jun 2026
CVE-2025-55643 Medium 5.5 15 Jun 2026
CVE-2025-55644 Medium 5.5 15 Jun 2026
CVE-2025-55658 Medium 6.5 9 Jun 2026
CVE-2025-55659 Medium 6.5 9 Jun 2026
CVE-2025-52292 High 7.5 9 Jun 2026
CVE-2025-52293 High 7.5 9 Jun 2026
CVE-2025-55651 Medium 5.5 9 Jun 2026
CVE-2025-55657 High 7.5 9 Jun 2026
CVE-2026-9572 Low 1.9 26 May 2026
CVE-2026-8124 Low 1.9 8 May 2026
CVE-2026-39103 Medium 5.5 5 May 2026
CVE-2026-33144 Medium 5.8 20 Mar 2026
CVE-2026-27821 High 7.7 26 Feb 2026
CVE-2026-1416 Low 1.9 26 Jan 2026
CVE-2026-1417 Low 1.9 26 Jan 2026
CVE-2026-1418 Low 1.9 26 Jan 2026
CVE-2026-1415 Low 1.9 26 Jan 2026
CVE-2025-70302 Medium 5.5 15 Jan 2026
CVE-2025-70303 Medium 5.5 15 Jan 2026
CVE-2025-70299 Medium 6.5 15 Jan 2026
CVE-2025-70307 High 7.5 15 Jan 2026
CVE-2025-70308 High 7.5 15 Jan 2026
CVE-2025-70309 Medium 5.5 15 Jan 2026
CVE-2025-70310 Medium 5.5 15 Jan 2026
CVE-2025-70298 High 8.2 15 Jan 2026
CVE-2025-70304 High 7.5 15 Jan 2026
CVE-2025-70305 Medium 5.5 15 Jan 2026
CVE-2025-7797 Medium 5.5 18 Jul 2025
CVE-2025-25723 High 8.4 28 Feb 2025
CVE-2024-57184 Medium 5.5 24 Jan 2025
CVE-2024-50664 High 7.8 23 Jan 2025
CVE-2024-50665 Medium 5.5 23 Jan 2025
CVE-2023-4679 Medium 5.5 15 Nov 2024
CVE-2024-6064 Medium 4.8 17 Jun 2024
CVE-2024-6063 Medium 4.8 17 Jun 2024
CVE-2024-6061 Medium 4.8 17 Jun 2024
CVE-2024-6062 Medium 4.8 17 Jun 2024

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 68 Last 12 months 425 Lifetime Memory safety 50 % Parsing/validation 25 % Denial of service 20 % Info disclosure 5 % Latest advisories Loading the feed Overview GPAC is the MP4Box toolkit and the packager that turns mezzanine files into DASH and HLS output. It sits inside broadcast and streaming infrastructure, and inside a good deal of tooling that ingests video nobody vetted first. It also carries the heaviest bug yield in this whole category: 68 CVEs in the last twelve months, most of them memory corruption reached by handing MP4Box a malformed container. CVE-2026-15185 in the VobSub index reader is a representative entry. The project offers no reward and does not assign CVEs itself, pointing reporters at MITRE instead. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy takes vulnerability reports through the public issue tracker by default and through [email protected] where openness is inappropriate. It names no component boundary, so the whole toolkit is in The ISOBMFF and MP4 layer in libgpac: box parsing, sample tables, fragmented MP4 and the movie fragment index MP4Box itself, every option it accepts and every file it will open on the strength of one The filter session and the whole filter graph, including how filters are linked and how buffers move between them The DASH, HLS and CMAF segmenters, plus the manifest parsers on the client side: MPD, m3u8 and Smooth Streaming index parsing Demuxers for the other containers GPAC reads, covering MPEG-2 TS, AVI, Matroska and the raw elementary stream readers Subtitle and caption handling, including the VobSub index reader and the timed-text formats Codec bitstream parsing where GPAC does it itself: AVC, HEVC, AV1 and VVC parameter sets and their inspection paths Network-facing code: the DASH and HLS clients, HTTP handling and the RTP and RTSP stack Encryption and DRM handling: CENC, key management and the encrypted-media paths The player and the bindings, covering the gpac player, the Node and Python interfaces and anything that drives libgpac programmatically Out of scope Isolated overflows produced by a fuzzer that do not lead to a crash, ruled out by name in the policy Bugs in third-party libraries GPAC links against rather than in GPAC's own code Requests for a project-assigned CVE, since GPAC states it does not assign them Format-support gaps and files GPAC simply refuses to open Distribution packaging rather than upstream code Most-valued findings Memory corruption in the ISOBMFF box layer reached from an ordinary MP4 handed to MP4Box. This is the densest part of a 425-CVE record and it fires wherever a pipeline accepts an upload Anything reaching a write primitive rather than a read. With this much fuzz-shaped volume, a demonstrated write is what separates a report from the noise Manifest parsing on the client side, the CVE-2026-50810 shape, where a NULL dereference in Smooth Streaming index parsing comes off a remote manifest rather than a local file The subtitle and index readers, where CVE-2026-15185 landed in the VobSub path. These parsers get a fraction of the attention the container code gets Bugs reachable through a plain MP4Box command line rather than through an exotic harness, since the policy explicitly discards fuzzer artefacts that never reach a crash Defects in the encryption and key-handling paths, where the failure is confidentiality rather than a crash 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. Read the channel carefully before filing. The policy sends vulnerabilities to the public GitHub issue tracker by default, and reserves [email protected] for cases where public disclosure seems unreasonable or confidential information has to be shared Use the private address when the finding is exploitable rather than a crash, since the default channel puts the detail in the open immediately Fuzzer noise is excluded by name: isolated overflows generated by fuzzers that do not lead to a crash will not be treated as vulnerabilities Attach the input file and the exact MP4Box or gpac command line. The bug yield here is high enough that a report without a minimal repro competes with a lot of other reports GPAC does not assign CVEs. If you want an identifier you request it from MITRE yourself The project does not use GitHub Security Advisories, so expect the fix in a commit and a release rather than in a published advisory There is no reward. The SECURITY.md mentions none Disclosure Unusually open. The default path is a public issue, so disclosure often begins at the moment of reporting, and fixes land as ordinary commits rather than as advisories. Where you use [email protected] instead, coordinate the timing with the maintainers directly, since the policy sets no embargo period and the project publishes no advisory stream to embargo against. Identifiers come from MITRE on your own initiative. 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