What does a RESERVED CVE record mean when the ID already appears in a public fix commit?

## The state machine, in one paragraph A CVE identifier moves through a small set of states. **RESERVED**: the number has been allocated to an assigner and nothing about the underlying issue is public. **PUBLISHED**: the record now carries a description, an affected product and version list, and references. **REJECTED**: the record has been withdrawn — a duplicate, not a vulnerability, or assigned in error — and carries a reason. A published record can also be marked as contested by one of the parties. What matters here is that the first of those states is an *administrative* fact about a number, not a *technical* fact about software. ## Why assigners hold identifiers before they have anything to say CNAs are allocated blocks of identifiers rather than requesting them one at a time. That exists because an identifier is needed at the *start* of handling an issue, not the end: to track a report internally, to coordinate with other affected parties who ship the same component, to reference the issue in a bug tracker, and to put a stable name on something that several organisations will be discussing for weeks. At the point of reservation nobody may yet know whether the report is valid, which versions are affected, or whether it will be published at all. That ordering is the whole answer to the interview question. Reservation is cheap and early; publication is the expensive, considered step. ## What is publicly visible behind a reserved identifier Essentially nothing: the identifier, the short name of the assigner, and the date it was reserved. There is no embargoed description sitting behind a lock that will be revealed on a schedule — the description does not exist publicly yet, and in many cases has not been written. This is why looking up a reserved identifier returns a stub, and why any site that shows you a rich description for one is showing you somebody's guess or a leak, not the record. ## The commit case Identifiers routinely become visible before their records do: in a fix commit message, a changelog line, a bug tracker entry, a mailing-list thread, a distribution's package changelog. None of that is a malfunction — it is what happens when a name is allocated early so that people can use it. What you may legitimately conclude when you see one in a public commit is bounded: - an assigner allocated an identifier for some issue, and - a change to the code has landed. What you may not conclude: what the flaw is; that it is a flaw at all rather than a hardening change somebody decided to number; which versions are affected; whether the fix is complete; whether the record will ever publish. If a customer or a colleague asks you what the number means, the accurate answer is that no description exists yet. ## Reserved and never published A large population of reserved identifiers never becomes a published record. Reports turn out to be duplicates, or not vulnerabilities, or the assigner loses contact with the reporter, or the issue is fixed silently and nobody completes the paperwork. There is no rule that forces publication after a period, and no automatic withdrawal of stale allocations. So the presence of a reserved identifier is weak evidence of anything: it says a process started, not that it finished or that it should have. ## The wrong answer this question is aimed at The common senior-level mistake is reading RESERVED as *under review by a central authority* — as if MITRE were adjudicating a queue and would grant or deny the number. Nothing like that happens. The assigner already holds the number; there is no central review step between reservation and publication for a CNA acting in its own scope. The second common mistake is reading it as *confirmed but embargoed*: reservation carries no confirmation, and embargo is a coordination agreement between people, not a property of the state. ## How to behave when you meet one Record the identifier against whatever you were tracking so that it joins up later, describe the issue by what you can observe rather than by the number, and wait for publication before you assert affected versions to anyone. If you need to know sooner, the source of truth is the assigner, not the number.