> On 5 Nov 2025, at 19:02, Pedro Sampaio <[email protected]> wrote: > > On Wed, Nov 5, 2025 at 12:13 PM Olle E. Johansson <[email protected] > <mailto:[email protected]>> wrote: >> >> >> > On 4 Nov 2025, at 18:59, Art Manion <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On 2025-11-04 04:03, Olle E. Johansson wrote: >> > >> >>> On 3 Nov 2025, at 19:07, Art Manion <[email protected] >> >>> <mailto:[email protected]>> wrote: >> > >> >>>>> CVEs against dnsmasq (CVE-2025-12198, CVE-2025-12199, CVE-2025-12200) >> >>>>> and Kamailio (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206, and >> >>>>> CVE-2025-12207) mentioned in this thread are not yet disputed and have >> >>>>> no comments of this sort in their descriptions. >> >>> >> >>> I asked VulDB to mark the dnsmasq CVE IDs as disputed. >> > >> > The VulDB CNA decided to reject the dnsmasq CVE IDs. >> > >> >>>> As part of the Kamailio project I can say that we did just become aware >> >>>> of these CVEs in your email. They do not make sense. Trying to get to >> >>>> the report, the config files used to provoke the issue can’t be >> >>>> downloaded. >> > >> >> We’ve gone back and this was our core developer’s reaction to the mail we >> >> got earlier to our security address: >> >> >> >> "This is clearly spam, imo: vague/generic reporting, no explicit naming >> >> of Kamailio ... the email was not sent from the vuldb.com >> >> <http://vuldb.com/> server >> >> but from mc20a2201.dnh.net <http://mc20a2201.dnh.net/> ([185.46.57.114]) >> >> -- I would suggest to not >> >> clink on the links, they might lead to malware, etc... >> > >> > I understand both sides of this problem. Would it have helped if the VulDB >> > notification included details such as these (from CVE-2025-12207)? >> > >> > https://shimo.im/docs/vVqRMVMlrycMO63y/read >> > >> For us that site is not trustworthy. It could be language/cultural issues. >> One example is that the actual configuration files for some reason can’t be >> downloaded and the error message is >> in a language I have no understanding of. >> >> Trust is hard. We have to think about this. We get all kinds of strange >> emails to our >> security reporting email address so we’re very cautious unfortunately. >> >> How can we create some kind of trust system so that any open source >> developer - from one person projects to large projects with massive funding >> - know that a report is worth reacting to? >> >> /O >> > - Art >> > >> > >> > > > It seems to be that there is a hidden stage during the PSIRT function that > may require its own identification inside the CVE Program (which I assume is > the highest source of truth for us at this moment?). And that stage is when a > security issue is deemed not enough to become a full CVE, but it is still > relevant for awareness purposes. Assigning a CVE ID only to have it disputed > or rejected later seems like a process that is confusing and hard to manage. With bug bounties and other incentives to “file a CVE for your CV” normal bugs are reported as vulnerabilities, which cause a lot of work in all parts of the vulnerability management process. The amount of people spending time assessing these before finding out that they can be ignored will cost society a lot of money, resources and frustration.
In our case (Kamailio) getting a message directly from the CNA would have helped starting a dialogue, if we could somehow validate the CNAs messages. > > Disputes have no nuance and once the word is out, the possible damages are > hard to revert. Oftentimes they stay perpetually open, and resolutions seem > to not give any definitive answer, which adds to the confusion. Most CVE > record consumers do not have a way to clearly differentiate and correctly > prioritize them. Right. I haven’t looked into how various vulnerability management platforms handle this. Worth investigating. > > What if a new ID could be created for these cases, like a lower level CVE, > which can help raise awareness, maintain discussion history, and issues could > be elevated or degraded to it without them getting stuck at the never ending > vendor CVE grinder, but still benefiting from the current CVE infrastructure? My personal vision is that we need a set of related objects for each CVE, much like the ADPs. CVEs will in many cases continue to have different opinions - with some vendors disputing them just to protect their brand and others wanting to add a different severity. Anyway, I think this is an indication of a CNA that did not fully look into the issue. /O
