How CVEs fall through the cracks in upstream bug trackers

Most modern software relies on long-standing codebases, which have been passed from maintainer to maintainer over many years. Over time, this transfer of ownership has increasingly blurred the maintenance and security responsibility.

As a result, some CVEs end up in a sort of limbo – neither clearly owned nor consistently tracked – leaving users exposed and maintainers unsure who should fix what. In this blog, we’ll examine how some CVEs have gone untracked for years, still triggering scans without a fix recorded.

The case of CVE-2017-13716

CVE-2017-13716, disclosed by MITRE in August 2017, describes a memory leak in the C++ symbol demangler within GNU libiberty. An attacker could exploit it with a specially crafted file to trigger excessive memory allocation and crash an application.

GNU libiberty is a support library for the GNU toolchain and is distributed by several GNU projects separately, including GCC and binutils. It’s never released as a standalone library and doesn't have its own version or release schedule. The GNU project even recommends copying its source code directly into your project, making ownership murky by design.

So, when MITRE published CVE-2017-13716 in August 2017, they decided to assign it to the binutils package, rather than to the GCC package, which is the actual maintainer of libiberty as understood by GNU collaborators. On the binutils bug tracking forums, an official maintainer informed the reporter that the bug report should be re-filed with the GCC project and asked them to do it. The reporter agreed, but no bug report was ever filed with GCC, and there aren't any other external links in any CVE database pointing to additional sources.

Fast forward to 2025: our team tried to reproduce the error ourselves by running the exact commands the bug reporter specified, but it turns out the bug doesn't even reproduce. In fact, it looks like it’s been fixed for a really long time. It was most likely discovered independently by a GCC maintainer, patched, and fixed. Binutils, meanwhile, upgraded their version of libiberty in some routine update, unknowingly patching the CVE. What does this mean? The issue in the binutils bug tracker was already marked as "RESOLVED WONTFIX," eight years have passed with no change, and it’s the only issue connected with the MITRE CVE, making it unlikely that this CVE will ever be marked as resolved – so it will continue to pop up in your vulnerability scan results.

The case of old OpenSSH CVEs

Untracked CVEs aren't limited to obscure libraries – they show up in widely used software too. Take OpenSSH on Debian: it currently lists nine unresolved CVEs, most of them more than five years old, and three dating back over 15 years.

The two oldest entries involve vulnerabilities in the S/KEY authentication system – an early one-time-password algorithm from the 1990s. OpenSSH’s support for S/KEY was always optional and required a separate PAM (Pluggable Authentication Module) called libpam-opie. But if you spin up a modern Debian container and search for libpam-opie, you’ll come up empty. Even Debian Bullseye, the oldest still-supported release, doesn’t include it. In fact, libpam-opie was removed back in Debian Wheezy, which officially reached end-of-life in 2018.

Both these CVEs are of course irrelevant, and have been so for many years, but the CVEs were never formally closed, updated with current package status, or removed from the record. The result? They still trigger vulnerability scanners, wasting security teams’ time and obscuring results.

Why old CVEs persist

Much of the foundational software that modern systems still depend on was written in the 1980s and 1990s, and has been accumulating bugs and CVEs ever since. As we saw with binutils and OpenSSH, many of those vulnerabilities no longer apply to today’s systems.

And these are just two examples. Similar patterns likely exist in GCC, glibc, TLS libraries, and countless other core components. The problem is compounded by how responsibility is distributed – or rather, not distributed. Packages like binutils often fall outside the scope of distribution-level security maintenance. Debian and other distros frequently consider developer tools lower-priority targets for patching. Even when a fix is identified upstream, distributions may acknowledge it but not actively backport or apply the patch.

Over time, these CVEs are rarely revisited by the maintainers. They’re left open in public trackers – unresolved not because the issues remain, but because no one owns the process of formally closing the loop. That leaves end users and security teams with a frustrating task: figuring out, case by case, whether each CVE still matters – and what to do about it.

What can be done about long lasting CVEs

We’ve been down this road ourselves. In building secure base images, we’ve had to trace countless CVEs back to their original context – digging through bug trackers, analyzing old patches, and trying to reproduce issues in modern environments. It’s tedious, delicate work, and rarely straightforward.

If you wanted to go through this process on your own, you'd need to research each CVE case by case. That starts with finding the original bug report, which is sometimes linked from the CVE page, but often isn’t. From there, you’d need to understand what part of the package is affected, how the vulnerability is triggered, and whether it still exists under your system’s configuration and dependencies. Only then can you test whether the CVE is actually relevant – or if it’s been quietly patched, deprecated, or rendered obsolete.

It’s a heavy lift. Doing this for even one CVE can take hours. Doing it at scale is rarely feasible, and it’s certainly not something most developers want to waste their time on.

Where this leaves us

Despite how far software development has come, critical infrastructure still depends on decades-old code with unclear ownership and unresolved vulnerabilities. While lingering CVEs often have no impact on real-world systems, they continue to surface in scans and generate noise that consumes valuable engineering time.

Investigating these issues is slow, manual, and rarely conclusive – and that’s just for vulnerabilities that no longer apply. For the ones that do, teams still face the massive burden of patching, testing, and rebuilding. Expecting every organization to reverse-engineer CVEs from the 1980s isn't realistic.

Fortunately, better options are emerging. Secure-by-design approaches now exist to alleviate the vulnerability management burden and help teams focus on what actually matters – without adding overhead. For teams trying to keep their foundations clean and their time focused, that shift can't come soon enough.