Serguey Asael Shinder: An advisory without a CVE number is still an advisory
On 6 October Netty released 4.2.19.Final and 4.1.139.Final with sixteen security fixes: request smuggling, an SNI routing bypass, a use-after-free, several ways to exhaust memory. Every one of them is listed as CVE-2026-XXXXX. The release notes explain why: the CVE infrastructure was under such strain that not a single number was assigned in time, so the advisories were published without.
That sentence is worth reading as a test of your own process.
What depends on the number. Many dependency checks match a library version against a list of CVE IDs. Dashboards count CVEs. Upgrade policies say "patch within N days of a critical CVE". All of that is keyed on an identifier that, in this case, does not exist yet. The vulnerabilities are real and documented, each with a GitHub security advisory, but a pipeline that waits for a CVE would see a routine maintenance release.
The number is a pointer, not the finding. A CVE ID is a shared name for a problem so that different tools and people can refer to it. It is useful exactly because it is a convention. The finding itself is the advisory: which module, which versions, what an attacker can do. When the naming system is slow, the finding does not become less true.
What to check in your own setup.
- Does your tooling read GHSA identifiers and the project's own security advisories, or only CVE feeds? Netty's notes link every fix to a GitHub advisory.
- Who reads release notes for the libraries on your network edge? A framework that parses HTTP from the internet deserves a person who reads "we strongly recommend upgrading" and acts on it, rather than waiting for a scanner to agree.
- Does "no known CVEs" appear anywhere as a gate? It is a statement about a database, not about the code.
The general rule is older than this release: a label is evidence that someone classified a problem, and its absence is evidence of nothing. When the source says "security fix", believe the source.