GCVE BCP-05-X-03 in practice: when was this vulnerability fixed?

“How long was this vulnerability exploited before a fix was available?” is one of the first questions asked about any vulnerability that makes the news. It is also one that vulnerability records, as they are published today, almost never let you answer.

Earlier this month we introduced GCVE BCP-05-X-03 - Vulnerability Handling and Disclosure Timeline (announcement). This post looks at one concrete use case: the date a fix became available, why it is missing from records, and what a single timeline event changes.

What a record says, and what it does not

A CVE record carries dates, but they describe the record, not the vulnerability: dateReserved, datePublished, dateUpdated. Everything else has to be inferred.

The information about the fix is usually there, in two forms, but neither carries a date:

• References tagged patch: a link to a commit, a pull request or a vendor page. The tag says that the link points to a fix. It does not say when the fix was released, or whether it was released at all.
• The fixed version in affected: "lessThan": "2.5.48" tells you which release fixes the vulnerability. It does not tell you when that release was published.

To measure how much this matters, we looked at the 3,575 vulnerabilities with evidence of exploitation known to Vulnerability-Lookup at the end of October 2026, from Known Exploited Vulnerability catalogs and sightings:

Of the 3,012 exploited vulnerabilities without a dated fix:

So for nearly half of these vulnerabilities, the record already names the release that fixes them. What is missing is the one fact only the publisher knows for sure: when that release became available to users. Recovering it means leaving the record, finding the project’s repository or the vendor’s release notes, and matching version strings to dates. For closed-source products, which make up most of the list, there is no repository to look in.

Two records, two opposite errors

Two records published in October show that a patch tag cannot simply be read as “fixed”.

A fix released three weeks before the advisory

CVE-2026-112192 is a MISP vulnerability (module settings exposing redacted values), published by CIRCL on 19 October 2026, also as GCVE-1-2026-20310. Its only reference is the fix commit, tagged patch, and affected states "lessThan": "2.5.48".

The record also carries a BCP-05-X-03 timeline, generated by patch2vuln from the commit, with a fix-developed event at the time of the commit, 28 September. As first published, it had no fix-available event. Yet the fix was released in MISP v2.5.48 on 29 September, 20 days before the advisory.

A consumer relying on the record therefore saw a vulnerability unpatched since its disclosure. That is what the Vulnerability-Lookup timeline reported: correct for the record as published, but wrong for anyone running MISP.

A fix merged, not yet released

CVE-2026-116566 is a CPython vulnerability in socket.getaddrinfo(), published on 29 October 2026 at 17:45 UTC. Two references are tagged patch: the pull request and its commit, merged into the main branch half an hour earlier.

At the time of writing, no CPython release contains that commit, and the backports to the 3.15 and 3.14 branches are still open pull requests. affected states "lessThan": "3.16.0", a version that has not been released yet.

Here, reading the patch tag as a fix date would report a fix that no user can install yet. The record is correct. It just cannot say “not yet released” in a machine-readable way.

The same tag, two opposite errors. In the first case the record understated the fix; in the second, a naïve reader would overstate it. Neither can be resolved from the record alone.

What the timeline adds

BCP-05-X-03 separates the three moments that a patch tag merges into one:

The specification is strict about the middle one: fix-available MUST NOT be used merely because a fix is planned or expected. That is exactly the distinction the two records above need.

We have since added the missing event to the MISP record. Its timeline now reads:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

"x_timeline": {
  "events": [
    {
      "description": "Corrective change authored (6c02f0f5c33aab96e90df8791c3873303d7e99ce): fix: [settings] Module settings keep the flags the module",
      "id": "evt-fix-developed-1",
      "references": [
        "https://github.com/MISP/MISP/commit/6c02f0f5c.patch"
      ],
      "timestamp": "2026-09-28T10:14:28Z",
      "type": "fix-developed"
    },
    {
      "description": "Fix released in MISP v2.5.48.",
      "id": "evt-fix-available-1",
      "referencedEvents": [
        "evt-fix-developed-1"
      ],
      "references": [
        "https://github.com/MISP/MISP/releases/tag/v2.5.48"
      ],
      "timestamp": "2026-09-29T08:11:29Z",
      "type": "fix-available"
    }
  ]
}

One event was enough. A consumer no longer has to guess or resolve anything: the timeline of GCVE-1-2026-20310 now dates the patch to 29 September and shows Disclosure to patch: −20 days 1.28 hours (the fix came first) and Time unpatched: 0 hours. Both ends are full timestamps, so both values are exact. The CVE record follows as the update propagates.

For CPython, the timeline would contain fix-developed today, and fix-available once a release ships, one event per release line if the 3.14 and 3.15 backports ship on different days. Until then, the absence of fix-available is the honest answer. And because the specification says that consumers MUST NOT infer that an omitted event did not occur, a missing event is never read as “never fixed”.

Precision matters too

BCP-05-X-03 accepts both an RFC 3339 date-time and a bare ISO 8601 date. Both are useful, but they do not say the same thing.

A bare date only places the event somewhere within a day. When the other end of an interval falls on the same day, the order of the two events is unknown. Vulnerability-Lookup therefore shows such an interval as a range, for example “−1 day to +1 day”, instead of a misleading “0 hours”.

When the exact time is known, as it is for a commit, a release or an advisory, producers should publish it, in UTC.

The same applies to the other end of the interval

The exploitation side has the same problem. In the population above, most exploitation dates are the dates on which a KEV catalog listed a vulnerability, not the dates on which exploitation was observed. Some of those listings are catalogs adding a backlog of dozens of vulnerabilities on a single day.

An exploit-observed event from the party that established the exploitation, or a first-seen date in a BCP-07 KEV assertion, turns that upper bound into an observation. Together with reported, acknowledged and fix-available, it gives the full set of dates that vulnerability lifecycle metrics have needed since they were first proposed. Kouns and Price’s VTEM, presented at Black Hat USA 2015, already relied on the date the vendor was informed and the date the fix was released, and records still do not publish them.

Seeing it in Vulnerability-Lookup

Every vulnerability page on Vulnerability-Lookup now has a Timeline tab. It shows the dated events from the record, the linked records (CSAF advisories, NVD, national databases), KEV catalogs and sightings, together with the derived durations:

• time unpatched;
• disclosure to patch;
• exploitation to patch;
• disclosure to exploit;
• and others.

Each duration lists the source dates it was computed from. The same data is available from the API at /api/vulnerability/<id>/timeline.

Records that carry a BCP-05-X-03 timeline are read directly. A fix-available event becomes the patch date, an exploit-observed event the exploitation date. Their precision, date or date-time, is carried through to the durations.

What publishers can do

For a GNA or a CNA, closing the gap is cheap. The publisher already knows the dates, and in most cases already writes them in a changelog or a release note:

1. Publish fix-available with the release date of the fixed version, and a reference to the release. Keep fix-developed for the commit.
2. Update the timeline when a fix ships after the advisory, with an advisory-updated event, instead of leaving the record frozen at “not yet released”.
3. Publish reported and acknowledged when the case went through coordinated disclosure. These are the dates every vendor-response metric needs, and the ones no record in our population carries today.
4. Use date-times in UTC when the time is known.

Tooling is already there: patch2vuln generates BCP-05-X-03 timelines by default, and Vulnerability-Lookup consumes them, in GNA workflows as well as in its public timeline. We have started by completing our own records, beginning with the MISP one above.

The specification is available here:

GCVE BCP-05-X-03 - Vulnerability Handling and Disclosure Timeline

Feedback from vulnerability producers, analysts, vendors, CSIRTs and tooling developers is very welcome.