Kamailio is an open source implementation of a SIP Signaling Server. Prior to 6.0.5 and 5.8.7, an out-of-bounds read in the auth module of Kamailio (formerly OpenSER and SER) allows remote attackers to cause a denial of service (process crash) via a specially crafted SIP packet if a successful user authentication without a database backend is followed by additional user identity checks. This vulnerability is fixed in 6.0.5 and 5.8.7.

Kamailio is an open source implementation of a SIP Signaling Server. Prior to 6.1.1, 6.0.6, and 5.8.8, an out-of-bounds access in the core of Kamailio (formerly OpenSER and SER) allows remote attackers to cause a denial of service (process crash) via a specially crafted data packet sent over TCP. The issue impacts Kamailio instances having TCP or TLS listeners. This vulnerability is fixed in 5.1.1, 6.0.6, and 5.8.8.

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

On Wed, Nov 5, 2025 at 12:13 PM Olle E. Johansson <oej () edvina net> wrote:

On 4 Nov 2025, at 18:59, Art Manion <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> 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 server but from 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.

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.

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?

-- Pedro Sampaio | Red Hat Product Security 851525C5A98E9DEB7E650ABDFAC8296FBC674B8F

On 4 Nov 2025, at 18:59, Art Manion <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> 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 server but from 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

On 2025-11-04 04:03, Olle E. Johansson wrote: On 3 Nov 2025, at 19:07, Art Manion <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 server but from 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

- Art

On 2025-11-02 03:30, Olle E. Johansson wrote:

On 1 Nov 2025, at 04:00, Solar Designer <solar () openwall 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. 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.

If you have access to edit the config files, there are much more simple ways to cause damage than to provoke a problem in the config file parser.

We will have an internal discussion but that will likely lead to the project disputing these CVEs. Hello Olle! I was going to do o the same for the Kamailio CVE IDs but defer to the project's decision. If you do decide to dispute, the first request should go to VulDB:

https://www.cve.org/PartnerInformation/ListofPartners/partner/VulDB

(I accidentally asked the MITRE CNA-LR first.)

Regards,

- Art

On 1 Nov 2025, at 04:00, Solar Designer <solar () openwall 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. 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.

If you have access to edit the config files, there are much more simple ways to cause damage than to provoke a problem in the config file parser.

We will have an internal discussion but that will likely lead to the project disputing these CVEs.

Best regards, /Olle

On Mon, Oct 27, 2025 at 05:15:09PM -0600, Hank Leininger wrote: On 2025-10-27, Michael Orlitzky wrote: On 2025-10-27 19:21:54, Moritz Mühlenhoff wrote: On Mon, Oct 27, 2025 at 09:34:03AM -0700, Alan Coopersmith wrote:

and if you can replace the server's configuration file you don't need to play games with putting invalid contents in to break the parser, but can simply change the configuration directly.

The same nonsense also happened for the Kamailio SIP server (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206 and CVE-2025-12207). Config parser exploits are not necessarily bogus. The admin might allow group/ACL edits to the configuration files knowing that it allows group members to torch the service in question, while, at the same time, not trusting those group members to execute arbitrary commands as root. For a particular package/system/deployment, sure. For the dnsmasq package? I don't think the project claims it's safe to make dnsmasq.conf editable by non-root-equivalent users. Heck just use the dhcp-script=... hook along with user=root to keep privs. Or in the case of kamailio, it looks like it has exec, app, etc.

Somebody could, on a per-package basis, investigate config options/syntax, decide if it's safe / try to create a safe wrapper around config-editing, which knows how to lint edits and which parameters are dangerous, or something.

Which works fine until it doesn't. It's like the #2 way to break out of appliances' locked-down custom CLIs or web UI, after simple command injection.

However, in that case it'd be CVEs in the appliance/wrapper thing, "XYZ CLI privilege escalation via malicious dnsmasq.conf edits", great. A CVE in OpenSSH that requires writing to sshdconfig would be bonkers. A CVE for an appliance whose CLI allows you to set an arbitrary "banner" string and write it to /etc/ssh/sshdconfig.d/pwned? Sure! Right. "Config parser exploits are not necessarily bogus", but that doesn't mean the parsers or the immediate programs they're part of are the vulnerable components. Perhaps not as robust as we'd have liked, but generally not vulnerable as far as CVE is concerned.

What's common about the CVEs mentioned in this thread, including those against GNU Bison (so not config file parsing, but just bogus CVEs), is that all of them were assigned by VulDB as the CNA. VulDB even went to the effort (or automation?) to generate CVSS 2.0, 3.0, 3.1, and 4.0 vectors for all of these. It's pretty ridiculous for a CNA not only to assign bogus CVEs, but also have CVSS vectors and scores for them without realizing the error. This suggests a lack of proper process and/or expertise.

At this point, I think we want to hear from VulDB on this, and from MITRE on their requirements for CNAs in general and VulDB in particular to review CVE requests before assignment. Maybe VulDB is in violation.

Alexander

On Mon, Oct 27, 2025 at 09:34:03AM -0700, Alan Coopersmith wrote: Among the new CVE's published this weekend were these from the VulDB CNA:

For all three bugs, the documented "exploit" requires "Replace the default configuration file (/etc/dnsmasq.conf) with the provided malicious file." and if you can replace the server's configuration file you don't need to play games with putting invalid contents in to break the parser, but can simply change the configuration directly. The same nonsense also happened for the Kamailio SIP server (CVE-2025-12204, CVE-2025-12205, CVE-2025-12206 and CVE-2025-12207).

Cheers, Moritz

A vulnerability has been found in Kamailio 5.5. This affects the function yyerrorat of the file src/core/cfg.y of the component Grammar Rule Handler. Such manipulation leads to null pointer dereference. The attack needs to be performed locally. The exploit has been disclosed to the public and may be used. The actual existence of this vulnerability is currently in question. This attack requires manipulating config files which might not be a realistic scenario in many cases. The vendor was contacted early about this disclosure but did not respond in any way.

A flaw has been found in Kamailio 5.5. The impacted element is the function rveisconstant of the file src/core/rvalue.c. This manipulation causes null pointer dereference. The attack needs to be launched locally. The exploit has been published and may be used. It is still unclear if this vulnerability genuinely exists. This attack requires manipulating config files which might not be a realistic scenario in many cases. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was detected in Kamailio 5.5. The affected element is the function srpushyystate of the file src/core/cfg.lex of the component Configuration File Handler. The manipulation results in use after free. The attack must be initiated from a local position. The exploit is now public and may be used. The real existence of this vulnerability is still doubted at the moment. This attack requires manipulating config files which might not be a realistic scenario in many cases. The vendor was contacted early about this disclosure but did not respond in any way.

A security vulnerability has been detected in Kamailio 5.5. Impacted is the function rvedestroy of the file src/core/rvalue.c of the component Configuration File Handler. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed publicly and may be used. There is ongoing doubt regarding the real existence of this vulnerability. This attack requires manipulating config files which might not be a realistic scenario in many cases. The vendor was contacted early about this disclosure but did not respond in any way.

The Kamailio SIP before 5.5.0 server mishandles INVITE requests with duplicated fields and overlength tag, leading to a buffer overflow that crashes the server or possibly have unspecified other impact.

Kamailio before 5.4.0, as used in Sip Express Router (SER) in Sippy Softswitch 4.5 through 5.2 and other products, allows a bypass of a header-removal protection mechanism via whitespace characters. This occurs in the removehf function in the Kamailio textops module. Particular use of removehf in Sippy Softswitch may allow skilled attacker having a valid credential in the system to disrupt internal call start/duration accounting mechanisms leading potentially to a loss of revenue.

In Kamailio before 5.0.7 and 5.1.x before 5.1.4, a crafted SIP message with an invalid Via header causes a segmentation fault and crashes Kamailio. The reason is missing input validation in the crcittstringarray core function for calculating a CRC hash for To tags. (An additional error is present in the checkviaaddress core function: this function also misses input validation.) This could result in denial of service and potentially the execution of arbitrary code.

In Kamailio before 5.0.7 and 5.1.x before 5.1.4, a crafted SIP message with a double "To" header and an empty "To" tag causes a segmentation fault and crash. The reason is missing input validation in the "buildresbuffromsipreq" core function. This could result in denial of service and potentially the execution of arbitrary code.

A Buffer Overflow issue was discovered in Kamailio before 4.4.7, 5.0.x before 5.0.6, and 5.1.x before 5.1.2. A specially crafted REGISTER message with a malformed branch or From tag triggers an off-by-one heap-based buffer overflow in the tmxcheckpretran function in modules/tmx/tmxpretran.c.

Last updated 25 August 2025

Heap-based buffer overflow in the encodemsg function in encodemsg.c in the SEAS module in Kamailio (formerly OpenSER and SER) before 4.3.5 allows remote attackers to cause a denial of service (memory corruption and process crash) or possibly execute arbitrary code via a large SIP packet.

The kamcmd administrative utility and default configuration in kamailio before 4.3.0 use /tmp/kamailioctl.

Insecure Temporary file vulnerability in /tmp/kamailiofifo in kamailio 4.0.1.