Known Exploited Vulnerability - KEV Assertion Format

• Version: 1.0
• Status: Draft (for Public Review)
• Date: 2026-01-03
• Authors: GCVE Working Group
• BCP ID: BCP-07

This guide is distributed and available under CC-BY-4.0.

Copyright (C) 2025-2026 GCVE Initiative.

Introduction

Known Exploited Vulnerabilities (KEVs) have become a critical signal for vulnerability prioritization, operational risk management, and policy-driven remediation. Governments, CSIRTs, and sectoral authorities increasingly rely on KEV lists to mandate patching, trigger incident response, or inform compliance decisions. However, existing KEV publications are largely list-based and opaque, often asserting exploitation without clearly expressing who made the claim, when exploitation was observed versus declared, what type of evidence supports it, where it was seen, or with what level of confidence. As KEV data is increasingly consumed by automated systems and cross-border information-sharing mechanisms, the absence of structured, contextual metadata limits interoperability, trust calibration, and analytical reuse.

This Best Current Practice defines a standardized KEV assertion format that preserves the intentionally simple and binary nature of KEV while adding minimal but essential context. Within the GCVE or other ecosystem, where vulnerabilities may be disclosed and referenced by multiple independent authorities, exploitation claims must be clearly distinguishable from vulnerability identifiers and treated as attributable statements rather than universal truths. The format enables multiple, potentially conflicting assertions to coexist, supports explicit attribution and confidence signaling, and facilitates interoperability with existing vulnerability, CSIRT, and policy ecosystems without turning KEV into full threat intelligence or requiring disclosure of sensitive evidence.

Known Exploited Vulnerability - KEV Assertion Format

This format describes a generic KEV (Known Exploited Vulnerability) assertion format.

The goal is to express who claims exploitation, when, based on what, where it was observed, and with which level of confidence, without turning KEV into full threat intelligence. A KEV assertion is usually very binary and lacking some meta-information. The format adds some information which could better capture details about the exploitation. A majority of the fields are optional except vulnerability, status and evidence.[].source which are recommended.

Format

It’s a single JSON object (ECMA 404) per KEV entry. The KEV entry is associated to a vulnerability ID in GCVE ID or any known vulnerability identifier.

Sample

{
"vulnerability": {
    "vulnId": "GCVE-0-2025-55182"
  },
 "status": {
    "exploited": true,
    "status_reason": "confirmed",
    "status_updated_at": "2025-12-24T10:15:00Z"
  },
 "characteristics": {
    "remote_code_execution": true,
    "authentication_required": false,
    "local_access_required": false
  },
 "timestamps": {
    "first_seen_at": "2025-12-03T10:15:00Z",
    "asserted_at": "2025-12-05T12:10:11Z",
    "recorded_at": "2025-12-05T13:15:00Z",
    "last_seen_at": "2025-12-24T09:42:21Z"
  },
 "scope": {
    "observation_regions": ["Europe", "North America"],
    "victim_countries": ["LU","BE", "US", "CA"],
    "sector": ["Telecoms", "Aerospace"],
    "asset_exposure": ["internet-facing"],
    "notes": "Regions reflect observed evidence, not global exclusivity."
  },
"evidence": [
    {
      "type": "incident_response",
      "signal": "confirmed_compromise",
      "confidence": 0.9,
      "source": "national-csirt",
      "details": {
        "observed_outcome": ["initial-access", "rce"],
        "detection_basis": ["forensics", "log-analysis"]
      }
    },
    {
      "type": "honeypot",
      "signal": "in_the_wild_attempts",
      "confidence": 0.6,
      "source": "research-honeynet",
      "details": {
        "attempt_volume": "high",
        "successful_exploitation": false
      }
    }
  ],
  "references": [
    {
      "id": "GCVE-0-2025-55182",
      "url": "https://vulnerability.circl.lu/vuln/CVE-2025-55182#sightings"
    }
  ],
}

Field Description

vulnerability Object

Describes the vulnerability being asserted as exploited.

vulnerability.vulnId

• Type: string
• Required: yes
• Description: GCVE, CVE identifier, GHSA or any identifier of the vulnerability.
• Example: "GCVE-0-2025-55182"

status Object

Represents the current exploitation status.

status.exploited

• Type: boolean
• Description: Indicates whether exploitation has been observed or asserted.
• Semantics: Does not imply global prevalence or universal exploitability.

status.status_reason

• Type: string (enum)
• Allowed values: confirmed, suspected, disputed, historical, unknown
• Description: Rationale behind the exploitation status.

status.status_updated_at

• Type: string (RFC3339 datetime)
• Description: Timestamp of the last change to the exploitation status in the KEV assertion.

characteristics Object

Describes high-level technical characteristics of the vulnerability that are relevant to exploitation assessment, without providing exploit details or turning the KEV assertion into full threat intelligence.

These fields describe properties of the vulnerability itself, not necessarily every observed exploitation instance.

characteristics.remote_code_execution

• Type: boolean
• Description: Indicates whether successful exploitation can result in remote code execution.
• Notes: Does not imply exploit reliability or ease of weaponization.

characteristics.authentication_required

• Type: boolean
• Description: Indicates whether authentication is required to exploit the vulnerability.
• Notes: Reflects the weakest known exploitation path.

characteristics.local_access_required

• Type: boolean
• Description: Indicates whether local system access is required prior to exploitation.
• Notes: Useful to distinguish remote exploitation from post-compromise privilege escalation.

timestamps Object

Separates different notions of time to avoid ambiguity.

timestamps.first_seen_at

• Type: string (RFC3339 datetime)
• Description: Earliest known exploitation activity based on technical observation.
• Notes: May be estimated and updated retroactively.

timestamps.asserted_at

• Type: string (RFC3339 datetime)
• Description: Date when an authority or source officially declared exploitation.
• Notes: Mirrors fields such as “date added” in KEV lists.

timestamps.recorded_at

• Type: string (RFC3339 datetime)
• Description: Timestamp when this assertion was ingested or recorded by the collector.
• Notes: System-specific and independent of the source.

timestamps.last_seen_at

• Type: string (RFC3339 datetime)
• Description: Most recent confirmed observation of exploitation activity.
• Notes: Optional and often unavailable.

scope Object

Defines the observed context of exploitation.

scope.observation_regions

• Type: array of strings
• Description: Geographic regions where exploitation evidence was observed. The region can be described in UN M49 format to facilitate automation.
• Notes: Reflects sensor or reporting coverage, not global limits.

scope.victim_countries

• Type: array of strings
• Description: Countries in ISO 3166 where confirmed victims were identified.
• Notes: Often incomplete or unavailable.

scope.sector

• Type: array of strings
• Description: Sectors targeted or affected by exploitation. The sector SHALL come from the MISP galaxy sector.
• Example: "Telecoms", "Aerospace"

scope.asset_exposure

• Type: array of strings
• Allowed values: internet-facing, internal, vpn-accessible, unknown
• Description: Exposure context of affected assets.

scope.notes

• Type: string
• Description: Human-readable clarifications to prevent misinterpretation.

evidence Array

Collection of independent signals supporting the exploitation claim.

evidence[].type

• Type: string (enum)
• Allowed values: incident_response, telemetry, honeypot, sinkhole, vendor_report, research_report, unknown
• Description: Origin of the exploitation evidence.

evidence[].signal

• Type: string (enum)
• Allowed values: (can be multiple) in_the_wild_attempts, successful_exploitation, confirmed_compromise, mass_scanning, weaponized_exploit_available
• Description: Nature of the observed exploitation signal.

evidence[].confidence

• Type: number (0.0–1.0) or enum
• Description: Confidence level associated with this evidence.

evidence[].source

• Type: string
• Description: Logical identifier of the reporting entity or data source. MISP org UUID? What about existing KEV source like CISA, ENISA or alike. Should we have an enum with existing ones? The source would be the only required fields has many KEV like the type of signal.

evidence[].details

• Type: object
• Description: Structured, free-form metadata describing how the signal was derived.
• Notes: Content is implementation-specific.