Re: Questionable CVE's reported against dnsmasq

["Olle E. Johansson" <oej () edvina net>]

> On 5 Nov 2025, at 19:02, Pedro Sampaio <psampaio () redhat com> wrote:
>
> On Wed, Nov 5, 2025 at 12:13 PM Olle E. Johansson <oej () edvina net <mailto:oej () edvina net>> wrote:
> > > On 4 Nov 2025, at 18:59, Art Manion <zmanion () protonmail com <mailto:zmanion () protonmail com>> wrote:
> > >
> > > On 2025-11-04 04:03, Olle E. Johansson wrote:
> > >
> > > > > On 3 Nov 2025, at 19:07, Art Manion <zmanion () protonmail com <mailto:zmanion () protonmail com>> 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