CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq (opens in new tab)

They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable.

The thing to complain about is if the version in testing is ancient.

You don't have to use Debian stable, if you'd prefer Ubuntu every 6 months, or Fedora (6 months? 9 months?), or even Arch Linux updated daily ...

I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.

I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.

But if you don't want Debian stable, that's fine. Just let others enjoy it.

    https://security-tracker.debian.org/tracker/CVE-2026-2291
    https://security-tracker.debian.org/tracker/CVE-2026-4890
    https://security-tracker.debian.org/tracker/CVE-2026-4891
    https://security-tracker.debian.org/tracker/CVE-2026-4892
    https://security-tracker.debian.org/tracker/CVE-2026-4893
    https://security-tracker.debian.org/tracker/CVE-2026-5172

fixed, fixed, fixed, fixed, fixed and fixed

I dunno, 2.92 seems to bring in some new features and changes that would not typically be brought into a stable release: https://thekelleys.org.uk/dnsmasq/CHANGELOG

You can always ask the Debian project for your money back.

For what it's worth, Debian had a security update for dnsmasq yesterday, presumably to address this.

About a decade ago I switched to Ubuntu LTS because of Debian’s “policy?” of having pretty old packages in “stable” and a long release cycles.

Nowadays, even with Ubuntu’s two year or so release cycle I have to use 3rd party packages to have up to date software (PHP being one) and not some version from three years ago.

We no longer live in a world (with few exceptions) where running a 3-5 year old distribution (still supported) makes sense.

It depends on how you look at it. I use Debian stable in the smallet possible configuration because it is, well, stable. A rock on which I put docker to run actually useful services, which are upaded the way I want.

If I was to run dnsmasq on Debian, it would be in a container. Since I run Pihole (in a container), it kinda is.

What if the new release which contains the fixes has new dependencies and those also have new dependencies? I assume they have to Frankenstein packages sometimes to maintain the borders of the target app while still having major vulns patched right in stable.

Nice troll fake account :)

And no "good faith" assumption here, since you literally claim debian stable ships broken kernels, according to you nobody should be able to even boot a computer.

That's what stable is for though. Like, sure, stable's policy is ludicrous and you would have to be insane to run stable. But the remedy for that isn't to try to change Debian policy, it's to get people to stop running stable. Maybe once no-one uses it Debian will see sense.

whatever you're on, stop, it's not making your brain any better

> they have literally shipped straight-up broken packages before

And did you open a high severity bug or you just kept it to yourself until you came here to complain years after the fact?

> ...they have literally shipped straight-up broken packages before, because fixing it would somehow make it not "stable"

Irrelevant strawman, since you're not accusing the dnsmasq package in Debian stable of being straight-up broken.

Well, as you bundle Lua 5.1 (as Lunacy), instead of making a library and loading it, and you bundled the 2012 version, you're probably affected by CVE-2014-5461 and others. Lua hasn't been security fix free.

MaraDNS is much less popular than dnsmasq though.

I have several libraries that I've written. Not one single serious security bug in them has been found since 1991. Granted, nobody uses my libraries...

Not to diminish your team's achievement! :D But it's important to contextualize claims like this with information about what your userbase looks like

I remember being delighted finding maradns as an alternative to the “do everything” of dnsmasq way back when I set up a dns server, and more importantly, I haven't had to think about it since then.

> Shameless plug time: My own MaraDNS has been extensively audited now that we’re in the age of AI-assisted security audits.

Out of curiosty: what is the point you’re trying to make? That there are alternatives to dnsmasq? That somehow your software is “better”?

This plug provides zero value to the dnsmasq discussion.

As others have pointed out: the more used a software is, the more scrutiny it gets and more bugs or edge cases are found.

good job. but it is amazing we are still writing core networking tools in vulnerable language such as c in 2026.

Flagged because this discussion about dnsmasq and another dns resolver implementation that has relatively no rollout worldwide by comparison is pointless.

That's a bit shameless, indeed.

dnsmasq has served me well for like an eternity in multiple setups for different use cases. As all software it has bugs. And once located those get fixed. Its author is also easy to communicate with.

Why should I switch over to something way less proven? I'm quite sure your software also has bugs, many still not located. Maybe because it's less popular/ less well known nobody cares to hunt for those bugs? Which means even if the numbers of found bugs is less in your software at the moment, and it may look more audited for this reason, it may actually be way less secure.

https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.

Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.

The problem is the lack of talent that is willing to work on this, not the language.

AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.

I tell you why that is. Working on these things doesn't give you stars on github.

I disagree -- we're clearly getting better safeguards by way of AI agents to spot potential vulnerabilities!

Who said it can't? https://news.ycombinator.com/item?id=47759709 appears to be a nearly flawless (per spec) zip implementation.

Because the problem is asymmetric: the attacker only needs to find one hole at one time. The defender has to be flawless forever.

It’s easier to break something than it is to make something that cannot be broken.

LLMs certainly make it more feasible to rewrite a product in a memory-safe language, eliminating a whole class of bugs.

Flawless software is hard for an LLM to write, because all the programs they have been trained on are flawed as well.

As a fun exercise, you could give a coding agent a hunk of non-trivial software (such as the Linux kernel, or postgresql, or whatever), and tell it over and over again: find a flaw in this, fix it. I'm pretty sure it won't ever tell you "now it's perfect" (and do this reproducibly).

If humans can find bugs, why can't humans write flawless code?

Whatever the answer to that conundrum might be, LLMs are trained on these patterns and replicate them pretty faithfully.

Have you ever met a security engineer? I’ve never met one who was also a good engineer (not saying they don’t exist, I just haven’t met one). Do they find vulnerabilities? Sure. Could they write the tools they use to find vulnerabilities, most probably not.

How do you define flawless though?

The CVEs here have their fair share of silly C problems, but also more rigid input validation and handling. These more rigid validations exclude stuff which may even be valid by the spec, but entirely problematic in practice.

As examples, take a look how many valid XML documents are practically considered unsafe and not parsed, for example due to recursive entity expansion. This renders the parsers not flawless and in fact not in spec.

Or, my favorite bait - there should be a maximum length limit on passwords. Why would you ever need a kilobyte sized password?

Just because something is good at finding bugs, it may not find all the bugs. Finding a bug only tells you there was one bug you found, it doesn't tell if the rest is solid.

You could argue the answer to this question depends on if you believe P=NP

That's kinda the point. It is "i run a small router" app in a box.

DHCP and DNS are connected, PXE requires DHCP entries, so to do a simple setup you'd need to glue together at least 3 daemons otherwise, all with different config syntax

That line of thinking is exactly why I ended up using maradns for my dns hosting way back.

10/10, no regrets, would recommend.

There are few dnsmasq (only?) features that are indispensable to some. Examples: sending query of *.example.com to certain upstream servers, or returning NXDOMAIN for phishing sites, or adding all resolved IPs for *.example.org to an ipset for policy routing. The last one works on FreeBSD as well although BSD does not have ipset. The list of *.example_xyz.com can be huge and it is said recent dnsmasq can handle them efficiently.

I agree, it also goes against the Linux "way of doing things". For example, Opnsense uses the dhcp portions of dnsmasq only (and unbound for the dns parts) which just feels 'wrong'.

Well, it is a good thing to get control of your own hardware, when the vendor decides that no you won't do what you want with it.

It's more of a good thing that, in most cases, it's on devices that won't send it any packets unless a client first authenticates to a Wi-Fi station or physically plugs into an Ethernet port.

Y2K26?

They can block traffic to update servers so the computers behind the router aren't all patched up, then exploit them. They also get access to all the IoT devices on the internal network. They can also use your router as a proxy so their scraping/attack traffic comes from your IP address instead of theirs.

It's definitely bad.

If you blindly TOFU ssh sessions, those can be pwned easily in many common use cases. Legacy software configurations like NFS with IP authentication will be bypassed. Realistically the most likely scenario is using your home as a VPN, or a DDOS node.

they could try and exploit any device on your network, and since they see which servers you connect to and how often you communicate with one they can write phishing mails which are tailored just for you.

The initial release of dnsmasq was in 2001. The list of viable languages for a high-performance network server at the time was still not all that long. Erlang wasn't on it. Too big a performance hit, too much opaque runtime that may not have been stable at the time, too few contributors, big dependency footprint of stuff most things wouldn't have installed. (When I used Erlang for a production system in more like the 2015 time frame it still had rough corners if you weren't using it exactly for the use case it was meant for.) This isn't specially a criticism of Erlang, it would have been like this across many languages and runtimes.

A lot of these systems that are getting hit, and will probably continue to be hit over the next few weeks or months, have a similar story. The Linux kernel's only other potentially viable choice was C++ at the time. OpenSSL, a perennial security offender, was started in 1998. You can look up your own favorite major system library with major security issues and it's probably the same story.

I'm as aggressive as anyone about saying "don't write a new project in C for network access", but cast me back to 1998 and I couldn't tell you what other viable choices there are either. There are safer languages, but they were much, much smaller than the C community, and I couldn't promise you how stable they were either. Java was out, and I don't know when to draw the exact line as to when it became a serious contender for a network server, but late 200Xs would be my guess; certainly what I saw in 1999 wasn't yet.

Example: I ran a Haskell network server in 2011 for something relatively unimportant and it fell over under conditions that would not have been very extreme for a production network; I know it was Haskell and not my code because I reused the same code base in 2013 with no changes in the core run loop and it did about 90% better; still not enough that I would have put that system into a real production use case but enough to show it wasn't my code failing. So while Haskell may have existed in the 200Xs, it wouldn't have qualified as a viable choice for a network server at the time.

There's a lot more viable choices today than there used to be.

In C you can normally directly map struct to network packets so that's quite easy. In other languages it's not often as simple.

Plus of course they are slower and bigger.

Are you saying this is Arthur Dent's fault? (again)

For a number of reasons, I feel that the only way we got here was via some kind of infinite improbability drive.

(mostly unrelated to topic at hand though)

> The AI bug report tsunami is not in all projects.

It's in popular projects.

Thanks, Claude ! :)

DD-WRT is also on point...

https://github.com/mirror/dd-wrt/issues/465

https://svn.dd-wrt.com/changeset/64944

https://svn.dd-wrt.com/changeset/64905

The release is "coming soon".