Governance
Configure fix approvals, protected paths, and account settings in one place.
Research
Hardening FFmpeg pipelines against malformed media
A practical guide to parser coverage, resource limits, and reproducible defensive testing in media-processing services.
The upload is more than a filename
A media-processing service exposes a large collection of parsers through an apparently simple upload workflow. Containers, codecs, metadata, subtitles, and image attachments can each select different code paths. A normal-looking extension does not establish which parser runs, and a successful probe does not guarantee that later decoding or conversion will be safe.
Start an assessment with the actual processing graph: ingest, identification, decoding, filters, encoding, and delivery. Record which steps accept user-controlled bytes and which run automatically. The same file may be examined by a thumbnail worker, a transcription job, and an archival service, each with different dependencies and privileges.
Make test coverage resemble production
A useful fuzzing harness needs to exercise the library entry points and build configuration used by the service. Testing a command-line decoder does not automatically cover a custom wrapper, optional demuxers, or a downstream filter chain. Build options and disabled components belong in the test record alongside the revision.
Seed the corpus with small valid examples from the formats the product actually accepts. Include truncated inputs, unusual metadata, boundary-sized dimensions, and combinations of streams. The objective is to explore parser states and error handling, not to maximize the number of nearly identical malformed files.
Use instrumentation to classify failures
Sanitizer-assisted builds can turn an intermittent crash into a more precise memory-safety report. Keep the original input, a minimized reproducer, the build flags, and an execution trace. Distinguish invalid memory access from an expected decoder rejection, an out-of-memory termination, or a timeout caused by a deliberately strict resource budget.
Do not equate every failing input with a distinct vulnerability. Several files may reach the same root cause. Group findings by the violated invariant and affected code path, then confirm the grouping with independent reruns. That prevents inflated counts and makes upstream reports easier to act on.
Contain the processing worker
Even a patched decoder should not inherit the application's full authority. Run untrusted media processing with limited filesystem access, constrained credentials, and explicit network restrictions. Apply limits to CPU time, memory, output size, frame dimensions, and recursion where the interface supports them. Enforce those limits outside the parser when possible.
Separate user uploads from application code and sensitive mounts. A failed conversion should not leave partially trusted artifacts in a public location. Account for temporary files and child processes as well as the final output, and clean up aborted jobs through a reliable lifecycle.
Turn a fix into lasting evidence
After a patch, rerun the minimized input and the surrounding corpus. Confirm that the repaired behavior rejects or safely processes the input and that normal media still works. Keep regression tests close to the affected component, rather than relying only on a service-level upload test whose failure may have several unrelated causes.
FFmpeg's development documentation and the OSS-Fuzz project guide provide primary references for contribution and fuzzing workflows. This guide describes a defensive evaluation method; it does not assert a new vulnerability count, claim unpublished discoveries, or establish that a particular production installation is affected without checking its build and execution path.
