FFmpeg

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 Separately, for a merged upstream patch : up to $15,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. FFmpeg is named by git URL in the Tier 1 scope table under 'Core infrastructure data parsers', which carries a 3× memory-safety multiplier through the end of 2026, though the $15,000 program cap still binds. Patches must be one to twelve months old, it is rate-limited to three submissions a month, one-liner fixes for non-exploitable crashes and resource-exhaustion DoS are excluded, and sanctions and territory exclusions apply. CVE history 14 Last 12 months 487 Lifetime Memory safety 45 % Parsing/validation 30 % Denial of service 15 % Info disclosure 7 % Latest advisories Loading the feed Overview FFmpeg is effectively the universal media substrate. Chrome and Firefox media pipelines, VLC, Kodi, MPV, HandBrake, OBS, Plex, Jellyfin, Audacity, Blender, every major CDN transcoder and essentially every Linux distribution's default media stack either link it or shell out to it. Its most dangerous position is server-side: a file uploaded to a web application reaches FFmpeg's demuxers with no user interaction at all, running as the application's own user, and there is no serious alternative implementation to fall back on. A parser bug here is close to a monoculture event. FFmpeg has no bounty of its own and pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to [email protected] and cover FFmpeg's own tree in full, every library and every tool the project ships. Only code FFmpeg links against but does not vendor sits outside libavformat in full: every demuxer and muxer, MOV and MP4, Matroska, ASF, FLV, HLS and MPEG-TS among them, plus the long tail of formats nobody names libavcodec in full: the H.264, HEVC, VP9 and AV1 bitstream parsers, the encoders, and the legacy codecs such as Cinepak, Indeo and RealVideo that are still compiled in libavfilter filter-graph construction and buffer handling across the whole filter set libswscale and libswresample colour-space, scaling and sample-rate conversion libavutil and libavdevice , the shared allocation, arithmetic and capture-device layers that everything above is built on Protocol and I/O handling in libavformat/protocols : HTTP, RTSP and RTMP, and the SSRF-adjacent concat and subfile handlers The ffmpeg , ffprobe and ffplay command-line tools, their option parsing and the input they accept from a caller Secure-by-design work across the parser layer: replacing C-style buffers, integer-arithmetic cleanup in stride and dimension maths, and Rust interop scaffolding Out of scope One-liner patches for non-exploitable crashes and for denial of service that amounts to resource exhaustion Patches older than twelve months or younger than one month at submission A vulnerability report with no merged patch behind it, where the Google money is concerned: that rail pays for the fix rather than the finding Anything the FFmpeg maintainers decline to merge, since Google will not override a maintainer's decision Third-party libraries FFmpeg links against but does not vendor, which need their own scope line even though most are separately in OSS-Fuzz Most-valued findings Heap corruption in a libavformat demuxer reachable from an ordinary user-uploaded file. That is where most historical FFmpeg CVEs live, memory safety is 45 percent of the record, and it is the highest-value class here because it fires server-side with no interaction Memory-safety defects in the legacy codec decoders, which are still compiled in by default, are still reachable from a crafted file, and receive almost no attention Integer-arithmetic errors in stride, dimension and geometry maths in libswscale , a recurring source of heap overflows on odd dimensions, where a wrapped size feeds a later allocation or copy SSRF or local-file access through the concat , subfile and HTTP protocol handlers, which turns a transcoding pipeline into a request forwarder A structural fix that removes a whole class from the parser layer rather than one instance of it, since the top Patch Rewards band pays for changes that almost certainly prevent major vulnerabilities and Tier 1 memory-safety work carries a 3× multiplier 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. Send a detailed, reproducible report to [email protected] with the sample file that triggers it; if it cannot be reproduced it is not eligible Show the bug in FFmpeg itself rather than in a third-party library FFmpeg links against but does not vendor, since those need their own scope line Resource-exhaustion denial of service and non-exploitable crashes are not rewarded on the patch rail, which rules out a large share of naive fuzz output here If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month. That is a separate pathway with its own rules Budget for maintainer discretion on that pathway: Google's own FAQ answer to 'the maintainers don't want my patch, can you help' is 'Nope!', and rewards are paid entirely at Google's discretion Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the FFmpeg security team through [email protected] , with fixes landing in the project's own releases. Patch Rewards adds no confidentiality or embargo term, so timing is upstream's call; hold the detail until the fix has shipped, and bear in mind that downstream players and distributions lag the upstream tree by a long way. 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