Trail of Bits 呼吁回移安全修复：稳定版积压大量未修复 CVE

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:

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 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 substantial amount of known CVEs have not been fixed in stable kernel branches:

The package landscape is not any better. These are non-kernel CVEs reported as open or affected in Debian 13 and Ubuntu 26.04 (raw data via their respective bulk CVE data feeds, compiled by Codex). These are distro-metadata findings, not individually source-confirmed vulnerabilities. Again, this is not meant to be an exact bug count, but more of a measuring stick indicating how many unfixed vulnerabilities remain in stable software packages:

Fixing the bugs

We realized this was an issue and have been fixing it proactively. First, we started with the equivalent of finding $20 on the sidewalk: there are bug fixes to known CVEs which apply cleanly to the stable kernel trees, but the fix was just never pulled into the kernel. We used Codex with GPT-5.6 to find these fixes, and asked the maintainers to apply the existing patches. They did, graciously, and 142 fixes representing 90 CVEs in stable trees are currently applied; the list on our backport tracker just keeps growing. We are now backporting patches, starting with the most trivial to validate and review, and are slowly moving towards more complex changes.

We’ve done the same for Linux distributions: we used Codex and GPT-5.6 to identify known vulnerabilities in shipping stable packages, and then backport and validate a fix. We have begun reaching out to Linux distributions with an initial batch of patches. If you run an open source project or a Linux distribution and would like help backporting security fixes, please apply at trailofbits.com/patch-the-planet and we’ll be glad to assist.

The big upside of stable software that does not add features is that we can, in theory, fix all the bugs before the bad guys do. So, let’s continue to patch the planet!