CVE-2023-54391 and beyond: excavating silent patches and the attacker-defender information gap

September 9, 2026

OLD POTS MAKE THE BEST SOUPS. CVE-2023-54391 and beyond: Excavating silent patches and the attacker-defender information gap

There is an old French proverb – “c'est dans les vieilles marmites qu'on fait les meilleures soupes” – that translates to: “It’s in the old pots that the best soups are made.”

It’s normally a compliment to experience: the well-worn cookware, seasoned by years of use, produces the richest results. Applied to cybersecurity, this proverb also provides an analogy for ‘silent patch gaps’: those vulnerabilities that were quietly fixed years ago, folded into a routine update, never announced and left to cook on forgotten, unpatched machines, waiting for attackers to discover and exploit them. Nobody labelled them, so nobody watching for labels ever noticed. The fix exists; the warning does not.

Silent patch gaps matter more now than ever for one specific reason: the cost of finding those old pots has collapsed. Diffing a vendor’s public git history for security-relevant commits that never got an advisory used to be expensive, expert work conducted by highly motivated actors. AI-assisted analysis has turned it into something cheap, scalable and automated.

An attacker can now mine years of commits for the exact shape of a silently patched bug in seconds, reconstruct the exploit and turn it loose on the installed base – while defenders, who key everything off a CVE that was never issued, get no signal at all. The result is a widening information asymmetry: the attacker reads the fix; the defender never hears about it.

CVE-2023-54391 is a textbook example of the pattern: a critical Proxmox VE authentication bypass, silently fixed in July 2023, rediscovered and exploited by attackers in August 2026, and only then assigned a CVE, three years late. We’ll start with the bug itself and its timeline, before zooming out to the systemic problem of silent patch gaps, how AI is changing the underlying economics, and what vendors, CNAs and vuln intel actors can do to meaningfully reduce the risk.

CVE-2023-54391: a silently fixed authentication bypass in Proxmox VE, three years ago

The CVE-2023-54391 bug has already been very well dissected, see for instance Flawfence's write-up for a thorough analysis or VulnCheck's advisory covering the operational facts. We won't re-derive their work; a short recap is enough to set the scene, because we’re interested more in the timeline than the technical details here.

The essentials:

  • Two-round login: Proxmox VE’s management API checks the password in Round 1. If a second factor is active, the server issues a signed intermediate ticket. The client must replay this ticket in Round 2 via the tfa-challenge parameter.
  • The flaw: On vulnerable versions (libpve-access-control >= 7.0-7, < 8.0.4), the API endpoint determines the login stage solely based on the presence of the tfa-challenge parameter.
  • The bypass: For accounts without a second factor configured (such as the default root@pam), providing this parameter causes the server to skip the password check entirely and never validate the challenge.
  • The impact: The server grants a full root@pam ticket without receiving any valid credential. Since root code execution is an inherent API feature (via node shells, in-guest agents or hook scripts), this vulnerability naturally receives a CVSS score of 9.8.

This technical flaw analysis can be easily derived by pointing an LLM at the Proxmox git history and asking it to read the relevant commits.

Fun fact: every public reference – the VulnCheck advisory, the NVD entry, writeups etc – says the fix sits in commit 032e7d6d (“fail if realm requires TFA but no challenge is generated”).

But our own two-minute LLM investigation shows something different: that commit closes a milder, still-credentialed 2FA-circumvention. The commit that actually kills the unauthenticated bypass is 0f3d14d6 (“read tfa.cfg also if the user.cfg entry has no ‘x’ marker”) – which makes user_get_tfa read the config unconditionally so $tfa_cfg is never undef, forcing the forged challenge through the signature check. The commit message mentions only an LDAP realm-sync edge case; nothing about something as severe as an admin takeover.

Both shipped in 8.0.4, so the CVE’s affected range is right even though the cited commit is wrong. Anyway, in a two-minute call, pointed at the same git history, our LLM had found and correctly interpreted the real story, yielding a ready-to-use root cause analysis, python exploit and vulnerable version range despite poorly explicit commit messages.

Years before VulnCheck’s publication of the CVE, low-skill attackers armed with similar capacities pointed at the public git log could have obtained the same material and weaponised it... and of course they did, in August 2026, against unpatched hosts that had been silently vulnerable since July 2023. The end of the story is finally more serious than the rapidly fixed auth bypass that could have been publicly disclosed back in 2023:

  • Because everyone expects high profile vulnerabilities to be assigned a CVE, people running outdated Proxmox VE 7.x (EOL July 2024) were kept unaware of the risk and did not patch.
  • While passive defenders relied on the full suite of CVE-driven tooling (scanners, IDS/WAF/EDR signatures, KEV, EPSS, ticketing), proactive attackers could simply mine the public git history to find the exploit and massively target unpatched hosts before a CVE was even assigned.
  • Because the CVE was disclosed years after the vulnerable version’s end of life (EOL), instances were left unpatched and internet-exposed for years without any automatic update or notification whatsoever.
  • Defenders were left in a reactive posture with no prepared detection rules, exposure signals or countermeasures. Attackers had a head start by construction.

The systemic problem: everything hinges on the CVE – and silence removes this signal

Modern vulnerability management is, operationally, organised around CVEs. Those identifiers are the pivot on which everything downstream turns:

  • Discovery: scanners and SBOM tooling match installed versions to CVE IDs
  • Detection: IDS/WAF/EDR signatures, Nuclei templates and Sigma rules are filed under CVE IDs
  • Prioritisation: EPSS, CISA KEV, patch SLAs and ticketing are driven by CVE IDs
  • Alerting: the notification that tells a busy administrator “patch this now” fires upon a CVE’s publication

Remove the CVE and you remove the trigger for the entire chain. A silently fixed bug is invisible to every one of these systems. The diligent operator who tracks updates is protected by luck; the operator who decided “nothing urgent this month” receives no signal at all, because the machinery that forwards signals never learns the vulnerability exists.

This leads to a structural asymmetry between attackers and defenders:

  • Attackers do not need the CVE at all. Diffing a vendor’s public git history for unadvertised security-relevant commits is now cheap, scalable and increasingly automated. AI-assisted triage clusters auth, parsing and boundary-check changes and surfaces the exploitable ones at a fraction of historical costs. The silent fix is the exploit specification. EOL, internet-exposed software finally offers a large target surface at a low cost of discovery.
  • Defenders live and die by the CVE. With no identifier there is no scanner rule, no KEV entry, no signature, no prioritised ticket – nothing to proactively build before exploitation, because no one knew there was anything to build for.

The resulting timeline is structural. Defenders are placed in the worst possible posture, reacting to exploitation instead of preventing it: quiet fix → years of latent exposure on unpatched hosts → rediscovery → mass exploitation → then, reactively, a CVE.

Recall that the official CVE record, assembled by a professional CNA, points at the wrong commit, while a cheap LLM pass over the same public history identified the right one. That inversion is the whole thesis in miniature: the raw material (the commits) is symmetric and public, but the analysis and conversion cost has collapsed asymmetrically.

An attacker willing to run automated triage over a vendor’s git log can now be much faster, more accurate and cheaper than the human-curated advisory the defender is waiting on. As the marginal cost of excavating and correctly interpreting silent patches keeps falling, the asymmetry only widens: “the fix is old” and “there’s no CVE yet” are no longer reassuring signals – they can be exactly what attackers look for.

How rare are exploited silent patch gaps?

We wanted to quantify how common the ‘old pot’ phenomenon is in the CVE corpus and whether we observe a rising trend. Under MITRE’s rules, a CVE identifier encodes the year (like CVE-2023-XXXXX) when the vulnerability was first identified or fixed. Each record also carries a publication date. When a record is published years after its identifier year, that gap is the observable shadow of delayed CVE publication.

We thus computed lag = pub_year − id_year for every published record in the full CVE List V5 corpus (CVEProject/cvelistV5, 2026-09-04 release, 386,205 records).

On-time disclosures sit on the diagonal. Everything below it is a record published after its identifier year – and the region is densely, persistently populated across two decades. CVE-2023-54391 is one cell within it (id 2023, published 2026, lag 3).

CVE publication lag by duration

Based on 380,030 published CVE records:

Lag ≥ 1 year: 80,188 records (21.1%)
Lag ≥ 2 years: 25,565 records (6.7%)
Lag ≥ 5 years: 6,585 records (1.73%)

Roughly one published CVE in 15 is at least two years older than the year it is disclosed. Some 4,415 of them were published in 2025 alone.

But dangerous silent patch gaps only account for a tiny fraction of that volume. This lag matrix is only an upper bound.

Not every delayed CVE is dangerous: a taxonomy of old pots

We searched for historic cases of silently patched, then exploited in the wild vulnerabilities, and the first finding is reassuring: the genuinely dangerous pattern is rare. The large-lag population is dominated by benign or low-consequence causes. Sorted by what actually happened, the cases fall into four categories.

Category #1: administrative backfills (not silent fixes at all)

The single largest source of large lags is bookkeeping: a long-known, openly-documented flaw finally getting a standardised CVE number, often via a modern CNA cleaning up history or promoting a regional identifier (CNVD, JVN, WooYun) into the global catalogue.

Example #1: ProFTPD 1.3.3c backdoor

In 2010 attackers trojaned the official ProFTPD source tarball. The project caught it in four days and went fully public (MD5 checks, mass alerts). It was in Metasploit for years.

The incident was never silent – only the CVE number (CVE-2010-20103) was, arriving via VulnCheck in August 2025, a 15-year administrative gap.

Example #2: WinRAR filename spoofing

This vulnerability (CVE-2014-125119) was fixed in WinRAR 5.0, shipped with a Metasploit module at the time, tracked for a decade under third-party IDs – then retroactively numbered in 2025 during a historical-exploit cleanup.

These inflate the statistics but carry no hidden exposure: everyone who cared already knew. Still, it is a valuable contribution to the ecosystem: a CVE number, even if assigned long after the fact, is what lets scanners, signatures, KEV entries and all the downstream tooling work.

Category #2: Silently fixed, but never meaningfully exploited

Plenty of bugs are quietly patched and do get a late CVE yet never attract attackers because the exploitation economics are poor.

Example: WordPress core stored XSS (the_meta())

This CVE (CVE-2022-4973) was late, but EPSS stays under 1% and it never entered CISA KEV. It needs an authenticated account and a theme still calling the obsolete the_meta() function – a combination modern installs rarely present.

The bug is real and deserves a CVE, but is not an urgent threat to the installed base. The late CVE is more a bookkeeping artifact than addressing a latent risk.

Category #3: Silently fixed, high latent risk, not yet exploited

This category is the uncomfortable middle: a quietly-fixed bug with genuinely dangerous mechanics and a high exploitation-probability score, which simply has not been picked up by attackers yet. Invisible to scanners (no CVE), unremarked by defenders, one rediscovery away from a wave. These are the pots still simmering – safe only by luck, and only for now.

Any critical CVE on a widely deployed product published with a lag greater than two years, but with no KEV entry, potentially falls into this category. The EPSS score is a good proxy for latent risk: the higher it is, the more likely an attacker will eventually find and weaponise it.

Example: MainWP Dashboard WordPress plugin unauthenticated stored XSS

CVE-2016-15041 was fixed in 2016 but only numbered in 2024 (8 years silent patch gap). When researcher Jouko Pynnönen discovered this vulnerability in 2016, the developer of this widely deployed plugin responded very quickly by releasing a patch in version 3.1.3.

The vast majority of users updated it via WordPress’s built-in notification system. Paradoxically, although its EPSS reached 65% at the time of its late disclosure, no exploitation has been publicly reported.

The vulnerability therefore seemed theoretically attractive to potential attackers, but it did not capture their interest. In short, it was only by chance that massive exploitation was avoided.

Category #4: the dangerous class – rediscovered and weaponised

This is the class to fear, and the Proxmox issue, CVE-2023-54391, belongs to it. We identified two mechanisms.

Mechanism #1: The fix was missed by defenders and found by attackers

A security-relevant patch ships with no advisory; the wider community never notices; an actor eventually diffs it, reconstructs the bug and exploits the unpatched installed base at scale. A CVE is minted only afterwards, reactively.

In some cases, the sudden need to add it to the KEV mandates the reactive disclosure. The recent Proxmox CVE-2023-54391 is a perfect illustration.

We observe that pattern recurs more visibly around Asian enterprise software that silently patches and rarely files CVEs – and the automated 2026 reactive-assignment sample makes it concrete. For example, the following CVEs were published in 2026 with a lag greater than two years and added to KEV or vKEV following the reported exploitation by Shadowserver:

[INSERT]

Each was fixed (or patchable) years before it was numbered, exploited in the wild in the interim, and only labelled once the damage forced the issue.

Mechanism #2: The CVE existed, but its severity was underestimated for years

Here the identifier is not late; the understanding is. A bug is disclosed as something mild, defenders deprioritise it and an attacker who analyses it properly discovers it is far worse than advertised.

CVE-2021-44529, relating to Ivanti EPM CSA, was disclosed in December 2021 simply as a code injection vulnerability. Later analysis by GreyNoise showed that its actual impact was far more severe: an unauthenticated RCE backdoor in the bundled open-source csrf-magic.php, allowing a specially crafted cookie to trigger remote command execution. Because the original description understated the severity of the issue, thousands of internet-facing appliances went unpatched. Alpha Spider ransomware affiliates later weaponised the vulnerability, and CISA added it to KEV in March 2024 – more than two years after the original patch.

These mechanisms look distinct from one another but share one root cause: an information asymmetry between attackers and defenders. In 4a the attacker sees a fix the defender never heard about; in 4b the attacker understands a danger the defender underrated. Either way, whoever analyses faster and cheaper moves first - and for now, that is increasingly the attacker.

Who mints these numbers – and the lesson for vendors

Identifiers are assigned by CVE Numbering Authorities (CNAs). Sorting the records with a lag of at least two years by assigning CNA is instructive:

Below mitre (root/backfill authority) and Linux (the kernel’s high-volume CNA), the third-largest producer of CVEs that are at least two years old is VulnCheck (2,328) – the same CNA that assigned CVE-2023-54391. That is not coincidence: part of VulnCheck’s mission is to assign identifiers to real, exploited-in-the-wild vulnerabilities that vendors left unlabelled. They are, in effect, professional excavators of silent fixes – a role that exists only because the silent fixes keep accumulating.

The actionable lesson is for vendors. A CNA is not a bureaucratic hurdle, nor an adversary that reveals your weaknesses to the world. By the time you are silently patching a bug, the weakness already exists in your public commit history or in deployed systems; the only open question is whether defenders or attackers act on it first.

Assigning a CVE – even retroactively, even for a bug you already fixed – is what lets the industry build scanners, signatures, KEV entries and prioritised tickets before your git log becomes someone else’s incident. Silence does not make the vulnerability disappear; it only surrenders the timing.

The good news is that YesWeHack is a CNA too! We operate as a CVE Numbering Authority – one of the few European private entities in that role – so we see this from both sides of the fence.

Through our Bug Bounty and vulnerability-disclosure programs, security-relevant fixes reach us constantly. Assigning an identifier and publishing structured, machine-consumable metadata is part of the standard workflow, not an afterthought bolted on after an incident.

If you are a vendor sitting on quietly patched bugs, or a maintainer without a CNA of your own, this is exactly the friction we exist to remove: we can assign the CVE, including retroactively, so the defensive ecosystem gets its signal before your commit history becomes an exploit spec. The excavation is going to happen either way – the only choice is whether you label the soup or wait for someone else to.

Recommendations

Reducing this information gap requires action on both sides: vendors and maintainers need to make security-relevant fixes visible, while asset owners need to assume that a lack of CVE does not necessarily mean a lack of risk.

For vendors and maintainers

  • Treat CVE assignment as part of shipping a security fix, not an optional afterthought. A labelled fix protects strangers who will never read your changelog; a silent fix protects only the diligent and arms whoever diffs your commits.
  • Assign retroactively when a past fix is recognised as security-relevant. Do not wait for exploitation to force the identifier. If you are not a CNA yourself, partner with one. This is precisely the service YesWeHack provides as a CNA, including retroactive assignment for already-fixed bugs.
  • Emit structured security-relevance metadata in release artifacts even before a full narrative advisory exists, so downstream tooling can act.

For asset owners and operators

  • Keep an inventory of what is reachable from the internet, and hold management planes – hypervisors, orchestration APIs, identity gateways – to tighter patch SLAs. They have no business on the front line.
  • Treat ‘quietly fixed’ as ‘quietly urgent’. Some of the most important security updates never carry a CVE. Read changelogs and release notes. Do not let ‘no CVE yet’ become ‘deprioritise’.
  • Track end of life (EOL) exposure explicitly. Proxmox VE 7.x reached EOL in July 2024; the August 2026 wave ran against never-updated, internet-exposed 7.x hosts that shouldn’t have been there in the first place.

Conclusion

Technically speaking, CVE-2023-54391 is not a cutting-edge vulnerability. It’s a guard placed one line too high, fixed two years before anyone outside Proxmox knew it existed, that went on to compromise hypervisors in 2026.

The technical flaw was closed in July 2023. The systemic flaw – a fix that carried no warning – stayed open for three years. The commit that closed the bug described an LDAP edge case, and may well have looked like one at the time. Telling a security fix from a routine one is hard for every vendor.

Historically, dangerous consequences were rare: of the 25,565 CVEs published two or more years late, most are quiet fixes no attacker ever cared about. Only a thin slice was rediscovered and exploited before defenders heard of it.

That slice is rare because analysis used to be expensive: identifying the security-relevant commit among years of code changes required significant expertise and time. A cheap LLM-assisted pass over the same public history now does it in minutes – well enough, in our small test, to spot a commit the official record had overlooked. As that cost keeps falling, so does the safety margin that silence used to provide.

The answer to the systemic issue is not a better fix, it’s a label. A CVE does not make a vulnerability more dangerous; it lets defenders act on something attackers can already read. Assigning it after the incident is better than never, but the label belongs at the front of the lifecycle, before the excavation.

That is where a CNA like YesWeHack can help. As one of the few European private CNAs, we assign identifiers to quietly-fixed bugs – including retroactively – so a fix becomes a signal defenders can act on. If you maintain software and have no route to a CNA of your own, talk to us.

“C'est dans les vieilles marmites qu'on fait les meilleures soupes.” It really is in the old pots that the best soups are made, and silent fixes only get richer with age: the exploit simmers in your commit history while the label that would warn defenders never gets written. What ultimately matters is who gets to eat the soup.

References & further reading