By NHI Mgmt Group Editorial TeamDomain: Breaches & IncidentsSource: IntruderPublished February 3, 2026

TL;DR: Publicly disclosed vulnerabilities can remain invisible to teams that depend only on the National Vulnerability Database, while attackers monitor the same disclosure channels for early exploitation, according to Intruder. The result is a shrinking remediation window that forces vulnerability management to treat disclosure streams, not NVD alone, as the operational source of truth.


At a glance

What this is: This is an analysis of Ghost CVEs, showing how publicly disclosed vulnerabilities can be exploited before they appear in NVD.

Why it matters: It matters because vulnerability management teams, IAM and PAM owners, and security architects need to respond to disclosure-time risk, not wait for catalogue-time visibility.

By the numbers:

👉 Read Intruder's analysis of Ghost CVEs and the NVD delay problem


Context

Ghost CVEs are a visibility problem in vulnerability management: a real weakness can be publicly disclosed, discussed, and weaponised before it is fully reflected in the National Vulnerability Database. That lag matters because defenders often treat NVD as the authoritative starting point, while attackers are already working from disclosure feeds, advisories, and code commits.

For identity and access programmes, the lesson is broader than patching. Any control that depends on an upstream registry being complete can lag behind the threat, including asset triage, privilege review, and exposure management for systems that host credentials, tokens, or service accounts. Intruder's example is typical of the gap between disclosure and catalogue enrichment, not an edge case.


Key questions

Q: How should vulnerability teams respond before a CVE appears in NVD?

A: Teams should treat public disclosure channels as the first alert, not NVD. Triage the affected product immediately, map it to exposed assets, and decide whether to patch, isolate, or apply compensating controls before the catalogue entry arrives. The goal is to collapse the delay between disclosure and action, especially for internet-facing systems and identity-adjacent services.

Q: Why is NVD alone not enough for vulnerability prioritisation?

A: NVD is authoritative, but it is not instantaneous. If an organisation depends on it alone, attackers can act on earlier disclosures while defenders are still waiting for formal enrichment. That creates a blind spot in the highest-risk part of the lifecycle, when the vulnerability is known publicly but not yet widely operationalised in internal workflows.

Q: What breaks when disclosure monitoring is missing from vulnerability management?

A: Teams lose the earliest chance to correlate a newly disclosed weakness with their own footprint. That means risk scoring, patch planning, and ownership assignment all start late, which is especially harmful for systems that store secrets or mediate access. The practical failure is not just slower patching. It is slower containment of the assets most likely to be exploited first.

Q: How do organisations reduce exposure during the NVD delay window?

A: They combine disclosure monitoring with asset inventory, ownership data, and rapid decision-making. That allows teams to identify whether a public vulnerability affects critical systems, then apply fixes or mitigations before attackers capitalise on the lag. The best programmes measure time from public reference to containment, not just time from NVD entry to patch.


Technical breakdown

Why NVD lag creates a disclosure-time attack window

NVD is a catalogue, not the first point of disclosure. A vulnerability usually becomes public through a CNA, advisory, commit message, mailing list, or vendor bulletin before it is enriched and published in NVD. That creates a window where defenders may not yet have a searchable record, while attackers can already correlate the disclosure with affected software, version ranges, and exploitability clues. The gap can be minutes, hours, or days, and each stage extends the period in which detection and prioritisation rely on manual triage rather than automated feeds.

Practical implication: build response around disclosure sources and not just NVD ingestion.

How Ghost CVEs turn public references into operational signals

Ghost CVEs are vulnerabilities that are real and documented, but not yet visible in the main catalogue most teams query. The operational trick is simple: monitor public references for CVE identifiers before NVD publishes the entry, then correlate those identifiers with your own asset inventory and exposure data. This is not exploit prediction, but early warning. It shifts vulnerability management from passive intake to active discovery, which is particularly important when internet-facing services, identity systems, or applications handling secrets are in scope.

Practical implication: wire disclosure monitoring into triage so exposed assets are checked before catalogue publication.

Why identity and secrets-bearing systems need faster exposure triage

When the affected component sits near authentication, secrets storage, or machine-to-machine access, disclosure delay becomes an identity risk as much as a patching risk. Service accounts, API keys, and session-bearing systems often sit behind the same vulnerable software that appears in Ghost CVE streams. If those systems are not identified quickly, the delay can become a credential exposure problem rather than a simple software defect. In practice, the control failure is not that a CVE exists. The failure is that the organisation cannot map disclosure to identity-sensitive assets fast enough.

Practical implication: prioritise identity-adjacent assets in your disclosure-to-remediation workflow.



NHI Mgmt Group analysis

Ghost CVEs expose a governance failure in dependency on delayed vulnerability catalogues. Security teams often treat NVD completeness as if it were contemporaneous with disclosure, but the article shows that assumption is wrong. The practical issue is not catalogue quality alone. It is the governance gap between public disclosure and internal action, which leaves organisations blind during the most dangerous part of the lifecycle. Practitioners should treat disclosure-time visibility as a control objective, not a nice-to-have.

Disclosure monitoring is now part of operational vulnerability management, not optional enrichment. If teams wait for the formal record, they are accepting avoidable delay into triage, prioritisation, and remediation. That delay becomes most dangerous for internet-facing services and systems with identity or secret exposure, where exploitation can cascade into access abuse. The right lens is continuous intake from advisories, commits, and mailing lists, then rapid mapping to affected assets. Practitioners should operationalise the earliest credible signal.

Disclosure-time exposure is the real named concept here: vulnerabilities become actionable before they become visible. That is the control gap Ghost CVEs surface, and it explains why traditional vulnerability dashboards can look reassuring while risk is already rising. The identity bridge matters because systems holding credentials or supporting machine access can be compromised before teams even know they need to triage them. Practitioners should shorten the time between public reference and containment decision.

Vulnerability intelligence must be joined to asset and identity context to be useful. A CVE identifier alone does not tell a team whether the affected system is externally exposed, privileged, or coupled to sensitive identities. The article's example shows that rapid patching only works when discovery is linked to inventory, ownership, and criticality. Without that linkage, teams are still reacting after the attacker has already had time to move.

From our research:

  • The GhostCVEs repository had only 14 stars on GitHub at the time of writing, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
  • When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
  • Read Ultimate Guide to NHIs for the broader exposure context that makes early vulnerability and identity response matter.

What this signals

The practical signal for security programmes is that vulnerability management needs an intake layer that starts before formal catalogue enrichment. Teams that already correlate disclosures with asset inventory, ownership, and exposure state will outperform teams that wait for a single authoritative feed. The governance shift is small in wording but large in outcome: disclosure-time triage becomes part of the control plane.

Disclosure-time visibility: this is the control concept to watch as teams move from catalogue-driven response to source-driven response. The organisations that close this gap will treat advisories, commits, and mailing lists as operational telemetry, not background noise, and they will reduce the time attackers have to exploit newly public weaknesses.

For identity programmes, the implication is sharper still. Any vulnerable service that can expose credentials, tokens, or access paths should be prioritised as soon as the weakness is public, because the remediation clock starts at disclosure, not publication in NVD.


For practitioners

  • Track disclosure sources before NVD publication Monitor vendor advisories, CNA notices, GitHub commits, and mailing lists so newly disclosed CVEs enter triage before the catalogue catches up.
  • Map disclosure alerts to identity-sensitive assets Tag internet-facing systems, credential stores, and services that handle API keys or service accounts so they are prioritised first when a Ghost CVE appears.
  • Create a disclosure-to-remediation SLA Set a response target from public disclosure to risk decision, patch, or compensating control, then measure whether teams meet that target consistently.
  • Automate early correlation with asset inventory Use vulnerability intake that matches CVE identifiers against known software, owners, and exposure state so analysts do not rely on manual searching after publication.

Key takeaways

  • Ghost CVEs show that vulnerability risk begins at public disclosure, not at NVD publication.
  • The delay window matters most for systems that can expose credentials, tokens, or privileged access paths.
  • Teams need disclosure-driven triage, not catalogue-only monitoring, to close the gap attackers exploit first.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKTA0003 , Persistence; TA0006 , Credential Access; TA0007 , DiscoveryThe article focuses on attacker use of newly disclosed weaknesses before defenders respond.
NIST CSF 2.0RA.5Ghost CVEs affect how organisations identify and prioritise vulnerabilities.
NIST SP 800-53 Rev 5SI-2Rapid vulnerability remediation is central to the article's response model.
CIS Controls v8CIS-7 , Continuous Vulnerability ManagementThe article is fundamentally about faster vulnerability awareness and response.

Add disclosure monitoring to continuous vulnerability management so triage starts before catalogue publication.


Key terms

  • Ghost CVE: A Ghost CVE is a real vulnerability that has been publicly disclosed but is not yet visible in the main vulnerability catalogue many teams rely on. The gap creates an early risk window where attackers can act on public information before defenders have complete automated coverage.
  • Disclosure-time visibility: Disclosure-time visibility is the ability to detect and triage vulnerabilities as soon as they become public, even before formal enrichment or catalogue publication. It depends on monitoring advisories, commits, mailing lists, and other early signals, then linking them to affected assets quickly.
  • Rapid Response workflow: A Rapid Response workflow is an accelerated process for turning vulnerability intelligence into action. It combines early detection, asset correlation, ownership assignment, and remediation decisions so teams can reduce exposure before attackers exploit the window created by delayed publication.

What's in the full article

Intruder's full research covers the operational detail this post intentionally leaves for the source:

  • A practical view of how Ghost CVEs fit into Intruder's Rapid Response workflow
  • The specific example of CVE-2026-24512 and how early disclosure changed remediation timing
  • Why the team argues that vulnerability visibility should start before NVD enrichment
  • How early warning can be turned into faster customer protection decisions

👉 Intruder's full article covers the disclosure workflow, the real-world example, and the response model in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It gives practitioners a structured way to connect identity controls to broader security operations.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org