- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 11
- Public CVEs
- 9
- 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
11 assets you may test, 5 excluded.
Web 1
- https://mediaarea.net/en/MediaInfo
Products and areas 10
- Channel layout and channel-splitting logic, plus the duration, bitrate and frame-rate maths derived from parsed fields
- Codec header parsing for video and audio, where MediaInfo reads enough of a bitstream to describe it without decoding it
- MediaArea publishes no written security policy. GitHub private vulnerability reporting is enabled on MediaArea/MediaInfoLib and that is the path, and nothing narrows scope below the library and the tools built on it
- Subtitle and timed-text track handling, and the reference and playlist formats that point MediaInfo at further files
- Tag and metadata parsing: ID3v1 and ID3v2, APE tags, Vorbis comments, XMP and the container-native metadata boxes
- The broadcast and professional formats, covering MXF, LXF, GXF and the other house formats that get parsed far more often than they get audited
- The command-line tool and the desktop GUI, including how each handles a file it cannot make sense of
- The container readers in full: MP4 and ISOBMFF, Matroska, MPEG-2 transport and program streams, AVI, WAV and AIFF, Ogg and Flash Video
- The output serialisers for text, XML, JSON and the EBUCore and PBCore profiles
- The public library API and its bindings, covering the C and C++ interfaces and the .NET, Python and Java wrappers other systems drive it through
Out of scope (5)
- Distribution packaging and Homebrew or distro builds rather than upstream
- Incorrect or missing metadata output with no memory-safety or disclosure consequence
- The mediaarea.net website and the download infrastructure, which are not this codebase
- The project publishes no exclusion list. The items below are genuine boundaries rather than policy text
- Third-party libraries MediaInfoLib links against rather than its own parsing code
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.
-
Report through GitHub private vulnerability reporting on MediaArea/MediaInfoLib, the Security tab on that repo.
-
Attach the file.
-
Say whether the defect is in MediaInfoLib or in the GUI or CLI wrapper around it
-
Hold the detail until a release carries the fix
Not accepted
-
Incorrect or missing metadata output with no memory-safety or disclosure consequence
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-25713 | A heap-based buffer overflow vulnerability exists in the ID3v2 parsing functionality of MediaInfoLib (version(s): 26.01). A specially crafted media file that contains ID3v2 tags can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability. | High 7.8 | 26 May 2026 |
| CVE-2026-25104 | A heap-based buffer overflow vulnerability exists in the LXF parsing functionality of MediaInfoLib (version(s): 26.01). A specially crafted .lxf file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability. | High 7.8 | 26 May 2026 |
| CVE-2026-28764 | A heap-based buffer overflow vulnerability exists in the LXF element parsing functionality of MediaInfoLib (version(s): 26.01). A specially crafted .lxf file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability. | High 7.8 | 21 May 2026 |
| CVE-2026-22554 | A heap-based buffer overflow vulnerability exists in the Channel Splitting functionality of MediaInfoLib (version(s): 26.01). A specially crafted .riff file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability. | High 7.8 | 20 May 2026 |
| CVE-2020-36646 | A vulnerability classified as problematic has been found in MediaArea ZenLib up to 0.4.38. This affects the function Ztring::Date_From_Seconds_1970_Local of the file Source/ZenLib/Ztring.cpp. The manipulation of the argument Value leads to unchecked return value to null pointer dereference. Upgrading to version 0.4.39 is able to address this issue. The identifier of the patch is 6475fcccd37c9cf17e | Low 3.5 | 7 Jan 2023 |
| CVE-2020-26797 | Mediainfo before version 20.08 has a heap buffer overflow vulnerability via MediaInfoLib::File_Gxf::ChooseParser_ChannelGrouping. | High 7.5 | 18 Mar 2021 |
| CVE-2020-15395 | In MediaInfoLib in MediaArea MediaInfo 20.03, there is a stack-based buffer over-read in Streams_Fill_PerStream in Multiple/File_MpegPs.cpp (aka an off-by-one during MpegPs parsing). | High 7.8 | 30 Jun 2020 |
| CVE-2019-11373 | An out-of-bounds read in File__Analyze::Get_L8 in File__Analyze_Buffer.cpp in MediaInfoLib in MediaArea MediaInfo 18.12 leads to a crash. | Medium 6.5 | 20 Apr 2019 |
| CVE-2019-11372 | An out-of-bounds read in MediaInfoLib::File__Tags_Helper::Synched_Test in Tag/File__Tags.cpp in MediaInfoLib in MediaArea MediaInfo 18.12 leads to a crash. | Medium 6.5 | 20 Apr 2019 |
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 4 Last 12 months 8 Lifetime Memory safety 65 % Parsing/validation 20 % Denial of service 10 % Info disclosure 5 % Latest advisories Loading the feed Overview MediaInfo reads technical metadata out of essentially every container and codec header in existence, and MediaInfoLib is the engine underneath it. Broadcast, archival and asset-management systems run it automatically over files as they arrive, so it parses hostile input before a human ever sees the file. CVE-2026-25713 is the shape of the problem: a heap buffer overflow in ID3v2 tag parsing, one of four heap overflows reported in a single month of 2026. The library covers so many formats that most of them have never had a second pair of eyes on them. There is no policy file and no reward here, so sorona.xyz pays you directly on qualified, reproduced findings. In scope MediaArea publishes no written security policy. GitHub private vulnerability reporting is enabled on MediaArea/MediaInfoLib and that is the path, and nothing narrows scope below the library and the tools built on it The container readers in full: MP4 and ISOBMFF, Matroska, MPEG-2 transport and program streams, AVI, WAV and AIFF, Ogg and Flash Video The broadcast and professional formats, covering MXF, LXF, GXF and the other house formats that get parsed far more often than they get audited Codec header parsing for video and audio, where MediaInfo reads enough of a bitstream to describe it without decoding it Tag and metadata parsing: ID3v1 and ID3v2, APE tags, Vorbis comments, XMP and the container-native metadata boxes Channel layout and channel-splitting logic, plus the duration, bitrate and frame-rate maths derived from parsed fields Subtitle and timed-text track handling, and the reference and playlist formats that point MediaInfo at further files The output serialisers for text, XML, JSON and the EBUCore and PBCore profiles The public library API and its bindings, covering the C and C++ interfaces and the .NET, Python and Java wrappers other systems drive it through The command-line tool and the desktop GUI, including how each handles a file it cannot make sense of Out of scope The project publishes no exclusion list. The items below are genuine boundaries rather than policy text Third-party libraries MediaInfoLib links against rather than its own parsing code Incorrect or missing metadata output with no memory-safety or disclosure consequence The mediaarea.net website and the download infrastructure, which are not this codebase Distribution packaging and Homebrew or distro builds rather than upstream Most-valued findings Heap overflows in a container reader reached from the file alone. That is what the entire recent record consists of, and it is what fires in an automated ingestion pipeline with nobody watching The broadcast formats, above all LXF, which produced two of the four 2026 CVEs on its own. These parsers see real files daily in archive workflows and almost no security attention ever Tag parsers, the CVE-2026-25713 shape in ID3v2. Tags are attacker-controlled by design and they are parsed before anything decides whether the file is even valid Channel-layout and channel-splitting maths, where CVE-2026-22554 landed. A count taken from a header driving an allocation or an index is the recurring pattern here Anything reaching a write rather than a read, since MediaInfo typically runs unattended as a service account with access to the whole ingest store Findings in MediaInfoLib rather than in the GUI, because the library is the component that ends up embedded in commercial media systems 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 through GitHub private vulnerability reporting on MediaArea/MediaInfoLib, the Security tab on that repo. It is enabled and it is the only private route There is no SECURITY.md, so no timeline, no severity scale and no scope statement have been published. Do not expect an SLA [email protected] is a general contact rather than a security address. Use it only if the GitHub route fails Attach the file. This library exists to parse files, and the whole recent CVE record is reproduced by handing it one Say whether the defect is in MediaInfoLib or in the GUI or CLI wrapper around it, since the library is the part that gets embedded in other people's systems There is no reward anywhere in this project Disclosure Coordinated privately through GitHub, with fixes appearing in the library's regular releases. The four 2026 findings all came through coordinated reports, so the process demonstrably works, but nothing about it is written down and no embargo length is published. Hold the detail until a release carries the fix, and allow extra time for the commercial and broadcast systems that embed MediaInfoLib and update it on annual cycles. 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