What about project with a license that allows for easy inclusion of source in another project (BSD license, for example). If most people are exposed to the bug through a bunch of other projects that include it, what do you name it? Any choice likely implies something that might keep people from looking closer initially when they are affected.
What about this specific but? Should it say CoreAudio, or iOS, MacOS, or just Apple?
Naming things usefully in a way that conveys additional information is hard. Looking up CVEs is fairly easy. Just throw it into a search engine.
You can remember CoreAudio Corruption Antelope a lot longer than you can care about 2025 301200.
As for whether it's CoreAudio or IOS or Apple or whatever: as long as it is not woefully inaccurate, it's fine. The format is necessary to prevent people from marketing "Extreme Apocalypso" as the name for an input issue in syslog that can only be used to fill a disk slowly.
A CVE is not the actual exploit or security issue, it's a way to reference the exploit or security issue. Internally, before this got a CVE entry, it likely also had an entry in Apple's internal bug system tracking. The identifier for that is similarly just another way to reference this specific problem.
A CVE number is no different than an incrementing ID in a database, except that it encodes slightly more information in the name. You can try to put additional information in the identifier, but it's hard to change after the fact, so you want to be careful what you put. Should you put the score in the identifier? Careful, they often increase after additional scrutiny is given to the issue. What about the product name, as is requested here? Sometimes additional products are discovered that are affected later. Sometimes those are just as important or more as the original, but the correct people that knew weren't contacted until the CVE was released. A CVE is most useful in providing a global id that different parties can use to reference the same item in their own databases.
It's an identifier. Keep it simple. Call it whatever you want in addition to that. If you subscribe to the CISA catalog update mailing list, they reference items like so, which is perfectly fine IMO:
- CVE-2025-4632 Samsung MagicINFO 9 Server Path Traversal Vulnerability
But that's not the CVE itself that is noting what it affects, that is CISA proving a summary of the problem, and notably in this case, one that's more descriptive than listed on the item itself and a combination of a few fields.
Edit: I'll note that from looking at a different response to me, that if you were just suggesting people name stuff more usefully when submitting here, I have absolutely zero problems with that suggestion, which should be obvious by the above. I interpreted your original comment to mean "CVE's should have more context in their names", which is what I disagree with if we're talking about the name as identifier.
"Hey, Kentrak! I'm concerned about 2600:1401:d000:38a::1aca."
versus
"Hey, Kentrak! I'm concerned about the Akamai node that's answering for www.apple.com!"
If you are staring at the same one for hours upon hours, you might remember the number. I'm saying that any time someone is referencing a CVE in any other context, they should use a memorable, informative, searchable, non-clickbaity name.
Previously I have expressed negative feelings about people claiming Heartbleed, Shellshock, and so forth -- they are unnecessarily dramatic. Now I feel that we need a middle course.
What OP wanted to stress is that just the CVE number on its own is not very helpful as a title. It would be helpful to at least mention the type of vulnerability and the affected product according to the CVE database entry.
I have a secondary reservation which is that people don't really browse for bugs by name in the way that this argument suggests.
Also, both of them could be solved just by replacing Antelope with a serial number.
I don't think so. The difference is when you arbitrarily constrain data your introduce errors and edge cases. Either the name is standardized in which case what can go in portions of it needs to be constrained, or it's not. If it's constrained, someone will need to make a decision on what's appropriate and inappropriate to add. If the list of items that can and should be put in that field is large, you're likely so see some or (most) omitted.
The real question is whether that omission will be viewed as people to imply something is unaffected before they look more closely, and then ignore what might be something important. An argument could also be made that people might see a CVE name without a product and decide that it doesn't affect them, or ignore it when they might have looked closer because something in the name caught their attention, but I think that's a slightly different problem. I think my stance can mostly be boiled down to not wanting to unintentionally train people to rely on something that is unreliable.
I'll freely admit there are cases for both sides of this and differing opinions. It's similar to Postel's law in that it deals to a degree with human nature and people's propensity to take shortcuts (in both actions and thinking), so what we're actually talking about is how we perceive human nature and how it interacts with systems we create.