A newly discovered critical vulnerability in the FFmpeg media processing framework bundled in a huge number of open source and commercial applications points, again, to the need for CSOs to have strategies to deal with software supply chain vulnerabilities, which should include demanding a software bill of materials for all products.

Found by researchers at JFrog, the hole (CVE-2026-8461) is a heap out-of-bounds write in the MagicYUV decoder that can crash any application that uses the framework. It runs in everything from desktop video players like Kodi and mpv, to Linux file-manager thumbnail generators, to cloud transcoding pipelines (such as AWS MediaConvert and Cloudflare Stream) and self-hosted media servers.

The hole has been dubbed PixelSmash.

“The vulnerability can be used to crash systems and, in worst cases, can be escalated to remote code execution, meaning it should be taken seriously and prioritized by security teams and developers,”  Yuval Moravchik, JFrog’s vulnerability research team lead, said in an email. “CSOs and developers should make sure their application security products alert them to the presence of this vulnerability, the sooner the better.”

The researchers said they have demonstrated the full exploit, achieving remote code execution on two independent targets: a Jellyfin media server (via automatic library scan) and a Nextcloud collaboration platform instance (via the video preview provider), in both cases by simply uploading a crafted 50 KB AVI file.

In fact, any crafted media file (AVI, MKV, or MOV container) will work on an application that uses FFmpeg’s libavcodec. Even a file folder containing the app is vulnerable, because the file manager’s thumbnail generator will trigger the bug.

“All it takes is processing a single malicious media file,” the researchers say.

There is one workaround: If the MagicYUV decoder is not needed, it can be disabled by developers at build time.

However, Garrett Calpouzos, principal security researcher at Sonatype, doubts full exploitation will be common. “I would be surprised to see broad, reliable exploitation of this specific bug in modern, hardened environments,” he told CSO in an email. “The more realistic near-term risk is denial-of-service (DoS), especially for services that process untrusted media at scale.”

Regardless, users of FFmpeg should upgrade to the patched version (8.1.2) as soon as possible if they know it’s in their application or are so informed by vendors.

A foundational dependency

JFrog notes FFmpeg is bundled with or linked to by virtually every media-processing application on every platform. It confirmed crashes against Kodi, mpv, ffmpegthumbnailer (used by GNOME, KDE, XFCE), Jellyfin, Emby, Nextcloud, Immich, PhotoPrism, and OBS Studio, among others.

The vulnerability is a single bug in the codec decoder inside FFmpeg, but it’s a foundational dependency embedded in hundreds of downstream projects that cascades to every application that links libavcodec, an open source library that provides the core encoding and decoding capabilities for audio and video streams.

None of the affected projects introduced this bug, the researchers note. They inherited it silently through their dependency on FFmpeg. And most, they add, have no mechanism to detect or mitigate it independently.

This isn’t the first security issue in FFmpeg. As researchers at DepthFirst pointed out earlier this month, Google’s Big Sleep team disclosed 13 vulnerabilities, and Anthropic, using its Claude Mythos preview model, found a 16-year-old hole. In April, researchers at SentinelOne described a buffer overflow vulnerability, and last December researchers at ZeroPath reported finding seven memory vulnerabilities.

Combatting supply chain vulnerabilities

Software supply chain vulnerabilities due to weaknesses in third party libraries and open source components have long been known as a security risk. Arguably the most infamous is the 2020 compromise of the update mechanism for SolarWinds Orion IT infrastructure management platform in which a Russian threat group called APT20/Cozy Bear installed a backdoor into a legitimate update that went to 18,000 customers, although a much smaller group was exploited.

To combat supply chain vulnerabilities, experts say developers need to adopt strategies to scrutinize code before it is deployed. These include software composition analysis, which gives visibility into the software’s dependencies, static application security testing, container scans, and having or generating a software bill of materials (SBOM).

[Related content: What is an SBOM?]

SBOMs critical

SBOMs are easy to create if a developer is building their own app. They’re harder to get from downloaded or commercial applications.

Johannes Ullrich, dean of research at the SANS Institute, told CSO that a transparent declaration of dependencies via SBOMs is critical if organizations are to accurately understand the risks posed by software. In particular, commercial software vendors are often hesitant to declare components; the perceived value that commercial software attempts to project is often incompatible with the wrappers it implements around commonly used open-source components.

One of the problems with the PixelSmash vulnerability, he pointed out, is the use of FFmpeg in an application is often neither obvious nor declared. An SBOM would help CSOs or heads of development teams quickly learn if any of their applications are affected.

What will it take to encourage CSOs to make SBOMs part of their security strategies? “Compliance regulation,” Ullrich replied. “These changes are usually only made if compliance requires them. Some influence may be exerted by government customers requiring SBOMs, but again, that will only happen if compliance requires this as part of purchasing guidelines.”

Lesson: Attack surface management

Sonatype’s Calpouzos said one big lesson for enterprises from the PixelSmash discovery is attack surface management. MagicYUV is a niche lossless video format used more in high-end video editing workflows than in mainstream web video delivery, he pointed out, and FFmpeg is typically built with every decoder enabled, meaning most applications end up exposing code paths they may never actually need. Infosec teams need to ensure they only enable the formats and features that their organization actually use in applications.

“This is also exactly where SBOMs matter,” he added. “Most organizations do not have a complete understanding of where FFmpeg is embedded, whether it is bundled or statically linked, or which optional features are enabled. An SBOM helps security teams move from ‘Are we exposed?’ to ‘Where are we exposed, and how fast can we fix it?’ In the AI era, attackers and researchers alike can increasingly comb through mature open source projects for overlooked vulnerabilities in obscure features, so organizations need to know what they ship, minimize what they expose, keep default security controls enabled, and patch quickly.”

Recommendations for SBOMs

The US Cybersecurity and Infrastructure Security Agency (CISA) has circulated a suggested list of minimum elements a software bill of materials should include.

“An effective mechanism for sharing and using software data must be machine-processable and scalable,” the it notes. “The SBOM model achieves both by capturing software component data in a machine-processable format and supporting operations that analyze, share, and manage it. SBOM data can be mapped to other data sources such as security advisories or organization-level ‘approved/not approved’ software databases to improve other priority practices (e.g., secure software development, vulnerability management). SBOM will not resolve all software security and supply chain concerns, but it is a necessary step that enables and empowers risk-informed security decision making.”

Separately, last month the G7 cybersecurity working group, which includes the US, Germany, Canada, France, Italy, Japan, the United Kingdom, and the European Union, released joint guidance, Software Bill of Materials for AI – Minimum Elements, to help public and private sector stakeholders improve transparency in their artificial intelligence (AI) systems and supply chains.

However, JFrog’s Moravchik argues that while a software bill of materials is an essential first step, it’s only a starting point to more secure applications. “The teams that stay ahead pair it with continuous CVE mapping and exploitability analysis, scan at the binary level where these dependencies actually live, and disable codecs and features they don’t use,” he told CSO.

Infosec leaders also need to shift from reacting to proactively gating, he said. That means moving security enforcement upstream so risk is blocked at the door, through automated governance of every package, model, and agentic tool entering the pipeline paired with AI-powered threat detection, rather than remediating in the wild after a CVE drops.