@reaction359 - that’s only true if you also control the router’s upstream resolver (or have managed to MiTM their resolver). That vuln is from a malicious response packet, not a request.
To summarize:
CVE-2026-2291 (extract_name heap overflow - cache poisoning / DoS): Requires an attacker's malicious DNS response to a LAN initiated request (MiTM or attacker controlled DNS).
CVE-2026-4890 (DNSSEC validation infinite-loop DoS) - requires DNSSEC, not enabled on GL routers by default. Also requires a malicious response packet to a LAN initiated request.
CVE-2026-4891 (DNSSEC heap OOB read, info leak). Same conditions as above.
CVE-2026-4892 (DHCPv6 heap OOB write. Priv escalation). LAN attacker on a link where dnsmasq is the DHCPv6 server. On GL, DHCPv6 is handled by odhcpd, not dnsmasq. Does not apply even if you’ve enabled IPv6 (which is also off by default).
CVE-2026-4893 (RFC 7871 client-subnet source-check bypass, info disclosure) - Bypass of dnsmasq's source-IP check on EDNS Client Subnet. LAN side initiated malformed packet required.
CVE-2026-5172 (extract_addresses heap OOB read, DoS via malformed DNS response). Triggered by malformed response to a LAN request. (again requires MiTM or attacker controlled DNS).
The only one that even has a priv escalation vuln would require you to both enable IPv6 and have replaced/disabled GL’s odchpd for DHCPv6 on your own.
Essentially.. a whole lot of nothingburger for 99.9% of practical use-cases.
If dnssec is involved, it is a high risk, maybe not for the average person, but definitely for the persons they are looking for: programmers, build servers, anything automated what can be predicted.
I also don't agree you can trust the isp that they claim to have their security done top notch that would be extremely naive, it would be a much better idea to just be stubborn about it, and go out of the worst that there is a chance there can be a evil middle person present at the isp side, that is a really good security practice, but not necessary for average people traffic most of these hackers have zero interest in.
They are interested in supply chains and predictfull patterns, as example an developer building a java application with hundreds of maven dependencies and unit scripts without a scope provided environment everyday that is for them very interesting to poison.
It is the predictfullness where they can leverage automated attacks, normal people traffic not, therefor not easy to automate on.
So to me I would be glad it would be patched, I really don't want to see a evil person craft something malicious with dnssec from the isp side as a dev (now retired with Java, but still building OpenWrt).
I’m not arguing against patching it. That we absolutely agree on. I’m simply saying it’s not a practically urgent issue or exposure for 99+% of users. Most non-tech users do not even know what DNSSEC is, nor have they enabled it for dnsmsasq on the router (it’s a not a main GUI option - and neither have most “tech” users).
I do also agree it’s not a great idea to trust your ISP infra, which is easily fixed in this case by setting the router’s DNS to encrypted DNS to CF, Quad9, Google, etc.
Right now, the one exploit that has a priv escalation isn’t relevant, and if you haven’t manually enabled DNSSEC, then another 2 are irrelevant.
The rest require an attacker controlled DNS or MiTM DNS, which you can easily mitigate using encrypted upstream DNS. Even on the rare chance someone at your ISP managed to MiTM your DNS, the worst impact is a DoS or cache poison (< this includes the dnssec ones).
Basically - just keep DNSSEC off and set your router to DNS mode “Encypted DNS over TLS > Cloudflare”, and you’re now protected against all of the above without a single update (CF does not support EDNS so this becomes irrelevant as well).
the standard GL.inet repository for Flint2 op24 only contains 2.90-r5.
quick and “dirty” trick: see the link from second screenshot from above posting by Bruce.
write it down to a text file and then remove the filename. after this add it with some declaration “src/gz test https:// …” to opkg update list (maybe in the customfeeds section in LuCi)
do opkg update and you will find 2.92-16 for install, it will also install new dependency. after this, i recommend to out comment the repo afterwards.
I went through the GUI and hit up the Plug-ins, searching for dnsmasq as you suggested.
Worked great for most of my models: Flint 2 (MT6000), Spitz AX (X3000), Brume 2 (MT2500), Opal(SFT1200), and even the Spitz (X750).
What's interesting is that on the new models, it does show the latest 2.92 version on the page after the update, but the Opal and Spitz doesn't. For the Opal, if I click on the dnsmasq-full name, it does pop up showing 2.92, but the Spitz doesn't. I still think it got the update because the page no longer shows the "update" option like it did prior. On a whim, I decided to connect via SSH and run the command. It took a while, but confirmed that I was on the latest version. When I logged back into the GUI, it does show that the latest v2.92 as expected.
However, I'm having issues with the Marble (B3000). I clicked the update option (via Plug-ins) and it looked like it went through, but then it went offline, and has been offline since (even in Goodcloud). Tried power cycling, but no luck. I had to connect to the Marble directly (via Ethernet) and then perform a factory reset. After setting it up and validating it’s online, I then performed the update again, this time via SSH. It went through, but after that, it goes offline again, like before.
I’ve now factory reset the Marble again, but considering both update options (via Plug-ins and SSH) do not work, can you suggest a workaround? Thank you!
The v4.8.4 beta firmware for Spitz AX is mainly for previewing the new AstraWarp and obfuscated VPN. If you don't need these features, you don't need to upgrade; staying on your current version is perfectly fine.
Sorry for any confusion. We haven't pushed this to stable because it only includes these two preview features. And we have already started rolling out v4.9.0 preview firmware for other models, and the Spitz AX will follow suit moving to v4.9.0, beta first, then stable.
If you prefer stability, please wait for the upcoming v4.9.0 stable release.
, I was a little triggered about the nothing burger, but with this response I completely agree on.