You’ve probably heard the word “monoculture” used literally in agriculture to describe the risk of relying too heavily on a single crop, or metaphorically in IT to describe the risk of having just one product, service or process that dominates the market.
Bananas, one of the most popular fruits in the world, are a commonly-cited example of monoculture risk.
Apparently, the most widely-farmed strain of banana until the 1950s was the gloriously-named Big Mike (Gros Michel), but a fungal disease that was peculiarly harmful to that particular variety all but wiped out the world’s supply.
The “solution,” such as it was, involved switching to new strains of banana that were resistant to the devastating fungus, and the world’s commercial banana production recovered.
Except that all of those new banana varieties, it seems, were derived from a single plant that had been imported into England in the 1830s from the tropical island of Mauritius, and carefully propagated over many years in a greenhouse owned by a certain William Cavendish, Sixth Duke of Devonshire.
(England, as you will know if you have ever visited, has a surprisingly temperate climate for its latitude, but is far from tropical, and had no indigenous banana varieties of its own.)
One monoculture ended up replaced by another.
You can probably guess what has happened since then: a new variant of the dreaded fungus has arisen that affects the so-called Cavendish strain that dominates the world’s supply today.
And that’s the obvious risk of a monoculture, because an injury to one can turn surprisingly quickly into a injury to all.
In software engineering, monocultures can work for both good and bad.
For example, many modern operating systems rely heavily on the concept of shared libraries, or DLLs (dynamic link libraries) as they’re known on Windows.
The idea is that instead of making every app developer write their own code to perform special functions such as rendering graphics or encrypting data, the OS itself provides a centrally-managed set of “sub-applications” that everyone can use.
This not only saves disk space (with only one copy of the code for everyone), but can also save huge amounts of memory (every app can share the read-only parts of the code once it’s loaded).
It also means that a single patch in the event of a bug will quickly and automatically secure everyone, even application vendors who use the buggy code but haven’t bothered to keep informed about the flaw.
Of course, the flipside is that a single bug that isn’t patched (a zero-day, in the jargon) could affect hundreds of different vendors and apps at once.
That means you can end up with all the risks of a monoculture, even when there are plenty of competing vendors and software products to choose from.
The problem of shared dependencies causing shared vulnerabilities isn’t just limited to DLLs curated by the operating system itself.
Complex software tools, notably including image and video encoders, may end up sharing the same open-source code for the performance-critical and quality-critical processing they need, so that bugs in so-called codecs (which is just shorthand for “coder and decoder”) may hit users widely.
And we’ve just seen an example of that very problem, with Mozilla and Google releasing the latest versions of the Firefox and Chrome/Chromium browsers (139 and 137 respectively) on the very same day.
Both browsers included a fix for a memory mismanagement bug dubbed CVE-2025-5283, discovered in Google’s code by Mozilla researchers just over a month ago.
As Firefox notes in its latest security advisory (MFSA 2025-42):
A double-free could have occurred in
vpx_codec_enc_init_multiafter a failed allocation when initializing the encoder for WebRTC. This could have caused memory corruption and a potentially exploitable crash.
To explain, the term double-free is programmers’ jargon for a bug where one part of a program borrows a chunk of memory to use temporarily, then hands back that memory so it can be used elsewhere…
…but forgets that it already paid back its loan and erroneously returns the memory a second time.
At first thought, this sort of error sounds harmless, or at least much better than handing back memory but continuing to use it even though it’s now reserved for use by another part of the program.
The problem is that if the returned memory has already been lent out again, then the “double free” could result in the system assuming that its new owner no longer requires it, reclaiming it, and and recycling it yet again while the new owner confidently assumes it’s safe to use.
Clearly, this is likely to cause a crash even without a hostile attacker in the loop, given that two parts of the program will unknowingly be sharing the same memory.
But determined attackers may be able to exploit this sort of problem quite deliberately, for example by:
Even if this doesn’t give the attackers an immediate way to get what’s known as RCE (remote code execution) by injecting rogue software instructions into the program flow, they may be able to compromise the software anyway.
For example, they may be able to modify configuration settings to remove security protections that would otherwise keep them out, to grab hold of passwords and authentication tokens that give them access in future, or to steal personal data from other parts of the program.
Even if they can’t reliably control the program’s behavior, they will very likely be able to crash it at will, provoking what’s known as a DoS, or a denial-of-service attack.
libvpx toolkit in your own software, as a direct or indirect dependency, get ready to update your own app or service.Remember that many apps combine “check my version” with “get missing updates now, if any,” so that explicitly checking for broken updates often fixes missed patches at the same time.
The human touch goes an awful long way, even in this era of hyper-automation!
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
