The software you are running is almost certainly riddled with known, unfixed security bugs. These bugs can be trivially and quickly exploited by modern AI agents. This is not merely theoretical; I saw this during my sandbox escape research, and an old vulnerability in stable software was used as a part of the recently disclosed OpenAI hack:
From the official hack description
To say it simply: whatever you are running is almost certainly easily hackable by advanced AI. Luckily, there is a fix, and we (not just at Trail of Bits, but in the security industry more broadly) are working on it. But first, how did we get here?
Stability versus security
Software has bugs, and some are relevant to security. We try to fix them when we can, and the first place the fix happens is in the latest version of the software. Unfortunately, that’s often the only place where the fix happens. The process of getting a fix from the latest source code to older versions is called “backporting.”
Fixes for big-name, critical bugs are indeed often backported quickly. But for many other bugs, the backporting process never happens. It is easy to understand why: software packaging is often done by volunteers who are already overworked, and backporting is frustrating, thankless work that gets little credit or publicity. For open source projects staffed by teams of volunteers, backports are (understandably) a low priority.
The lack of backports is a problem because almost no one runs the latest and greatest version of software that’s been freshly built with today’s code changes. People overwhelmingly prefer slightly older, more tested software packaged in “long term stable” releases. For example, about 95% of Ubuntu Linux installations are of the Long Term Support (LTS) variety. When looking at installed Linux kernel packages from Debian’s popcon, the overwhelming majority are based on older stable trees:
This is a Codex-generated graph of recently installed kernel packages from Debian’s popcon. The overwhelming majority (about 96%) are older, stable releases, and not the latest kernel series.
This puts users in a bind: They can either stick with a stable, familiar version of software that has security flaws, or upgrade to a newer version that fixes those flaws but introduces other changes and new features they may not want.
We should not have to make this choice.
Seeing no evil
Even three years ago, we could stick our heads in the sand and pretend the problem didn’t exist: backporting all fixes was a genuinely difficult, time-consuming job and any attacks were extraordinarily unlikely.
Now, both of those assumptions are false. A swarm of cyber-capable AI agents can cut through a network of stable, known-vulnerable software like a hot knife through butter. On the positive side, AI has significantly lessened the burden for identifying and backporting security-relevant bugs.
Of course, we should assume all software has bugs (because it does), and use the lessons we learned in our computer security classes: mandatory access controls, code integrity checks, sandboxing, and privilege separation. This works. Mobile platforms are much safer because they enforce these standards. But desktop and server platforms don’t mandate this behavior, and few voluntarily enable protections. And yes, everyone should update to the latest software. But many people purposely do not update to releases. I think that this normal end-user behavior is entirely justified. Just recently, I updated my Mac to macOS 27 and couldn’t use a printer that had worked flawlessly for years (until Codex wrote a new, compatible printer driver, on the first try).
Regardless, it’s good practice to assume that something may have bugs and that they should be contained; leaving known, easily fixed bugs is negligent. So, let’s backport all the fixes!
Accounting for security liabilities
Let’s quantify the scale of the problem. To make counting simple, we can limit ourselves to known bugs (with assigned CVEs) that are patched in the latest release but missing from stable packages. For this example, we’ll look at the Linux kernel, Ubuntu 26.04 LTS and Debian 13 Stable. I’m not singling out those projects—they are all run very well! I’m using them because they have documentation and accounting for unfixed CVEs. Other projects lack this transparency. The first step towards a solution is knowing that there is a problem.
Let’s look at the number of outstanding CVEs in the Linux Kernel, by stable branch. The table below shows CVEs per supported stable branch that do not have a fix in that branch, but do have it in a newer branch. (Hence, older branches by definition have more unfixed CVEs.) The source is the kernel CVE team’s vulns.git as of September 18, 2026. This is not an exact bug count, as it both over- and under-counts due to several technicalities. It is also not a measure of exploitability. Rather, it’s a measuring stick showing that a
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: