Hello,
Given the recent very critical CVEs on the linux Kernel and dnsmasq (meaning it’s becoming quite trivial to completely gain access to our routers), when can we expect firmware updates addressing these issues? I’m particularly interested in the gl-be9300, but what about older models, like the a1300, are they going to become a liability?
Thank you for your timely response.
The kernel CVEs released lately are local attacks, not network based attacks. Additionally, they have to take advantage of a user account to perpetrate a privilege escalation. Meaning they are not a primary compromise vector, access must be gained through other means. I would not classify these are trivial. Plus, when you access the router you are doing so as root - if someone else can do that they don’t need privesc, right?
The dnsmasq cves are a little different in some cases. However, it should only be listening on local lan, not wan, so it also would require access through an already allowed means or compromise of another vulnerability in order to gain initial access to your lan.
In either case, however, it would be good to hear from GL on their official position and roadmap for addressing these. @bruce ?
Yes, I know, that’s why I’m talking about the combination of both.
Plus, that’s not how security works, you don’t wait patiently for all the pile of security problems to lead to a disaster, you patch early. Not doing is is just pure negligence.
*how security is supposed to work
Sadly that is how alot of companies work... you should be happy they atleast want to backport some of the security fixes, but personally I won't expect a 100% fail safe product, and if so... you likely set yourself as bussiness to failure because it will mean you need to constantly pull from bleeding-edge branches for the most recent changes which are for production not always the best choice, but as a single one person it is a better choice because it is in your control.
I think that they have not a big problem with backporting latest dnsmasq since it isn't really kernel like, and I think it still can work with iptables regardless, there is atleast one CVE i read from this commit dnsmasq: apply six CVE-fix upstream patches to 2.92 by hauke · Pull Request #23330 · openwrt/openwrt · GitHub that might be good to add because you don't want any sort of name (big name) tampering with domains or responses.
Hello,
Thank you for reporting the security information!
We are currently verifying and assessing the impact of this vulnerability on our product firmware. We are gathering relevant materials and codes.
Please bear with us for a short while. We will provide a result once our assessment is complete.
If the issue is confirmed, we will provide a resolution and a timeline for the fix.
Thanks again!
Openwrt 25.12.4 now out:
dnsmasq: backport six upstream CVE-fix patches to dnsmasq 2.91:
CVE-2026-2291: heap buffer overflow in DNS domain-name handling.CVE-2026-4890 / CVE-2026-4891: DNSSEC crashes via crafted NSEC bitmaps / RRSIG packets.CVE-2026-4892: buffer overflow on large DHCPv6 CLIDs (only with --dhcp-script).CVE-2026-4893: broken EDNS Client Subnet validation.CVE-2026-5172: buffer overflow in extract_addresses() on crafted resource records.
Linux kernel: CVE-2026-43284 ("Dirty Frag") — local privilege escalation via the IPsec ESP path. Only relevant on devices with kmod-ipsec / esp4/esp6 loaded. Fixed via the 6.12.87 kernel update.
These were considered critical enough for a new point update from OpenWRT
The dnsmasq fix was completed on 2.92rel2. Since the developers also mentioned that 2.93 is the full release and 2.92rel2 is a pre-release, a 2.93 release may follow.
The kernel Dirty Frag local privilege escalation, the exploitability and required conditions are very restrictive, it does not need to be addressed at this time.
Hi Bruce.
Is GL-inet’s Openwrt 24 4.8.3 (Nov 2025) for Flint 2 prone to any of the CVE’s that OpenWRT 25.12.3 and 25.12.4 fixed?
You may be able to update dnsmasq as plugin 
Dnsmasq doesn't have much other core dependencies.
Hello all,
Thanks again for everyone’s feedback!
We have confirmed that the dnsmasq component in the current version of the GL firmware contains the following vulnerabilities:
CVE-2026-2291
CVE-2026-5172
CVE-2026-4893
CVE-2026-4892
CVE-2026-4891
CVE-2026-4890
We have urgently built dnsmasq 2.92 for all router models and uploaded it to the GL repo.
Now you can get the dnsmasq 2.92 update in the following two ways:
opkg update && opkg install dnsmasq-full
For our next steps, we will roll out firmware updates (beta) for all models to include the latest dnsmasq component (depends on the dnsmasq author releases latest update).
Thank you all for your attention to security. Please continue to report any vulnerabilities or security-related information to us as soon as you discover.
It related to the dnsmasq version, the op24-4.8.3 firmware is affected.
Updated my GL-X3000 with no issues through the CLI
How long till those come out of beta to stable? 4.8.4 beta hasnt moved an inch for:
GL-AXT1800 Slate AX since 2026-04-09
GL-X3000 Spitz AX since 2026-03-26
And I dont make it a habit to run beta software on my devices.
Though im not even sure I want 4.8.4 with all the wireless discussions around it.
Awesome, thank you. I just posted in Reddit about this. I wrote into GL.iNet earlier this week about this, so I really appreciate the turnaround time on this.
Reddit is blocking my post for unclear reasons, though. In the email reply from the Security Team, they didn’t explicitly mention what you mentioned re: next steps for firmware updates, but I figured that was coming next and said as much in my post. If my Reddit post is unblocked, I can add a note to the post specifying you’ve also explicitly confirmed patched firmware is up next.
Thanks @bruce ! And thanks to the rest of the GL.iNet crew as well!
Hi Bruce.
I can’t see an updated dnsmasq component plugin - I’m runing openwrt24 4.8.3.
Pasting the reply I posted on reddit here so there's some context for these
These CVE's are all local side exploits. Unless you're worried about someone already *inside your own home* trying to cache poison or DoS your DNS stack, then it's a non-issue.
None of these are exploitable externally, and several of them require DNSSEC, which is disabled by default on GL anyway.
The most serious one that actually involves privilege escalation requires LAN access & DHCPv6, so if you use your GL router to run a coffee shop or other public wifi & have manually enabled IPv6 it would be concerning. (edit.. correction, even this isn’t relevant as GL ipv6 usese odhcpd, not dnsmasq)
Good on GL for patching regardless. As of right now there are no PoC exploits published for these, so it would take significant time with an advanced red team actor on your LAN to actually exploit.
I don’t think they are local side exploits, a specially crafter dns response can trigger an oob write to the stack. So an attacker can make a client resolve hostname they control (can even be a pixel in a page or email) and the exploit is triggered “remotely”.
Thank you @bruce but that doesn’t work for me on BE9300
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency libubus20251202 for dnsmasq-full
Same, Flint3 running 4.8.4 release version. Oddly, in the GUI, it doesn’t show dnsmasq-full as installed. The only entry I see is for 2.92-1 and it shows only the install option.
Same on my Flint 3/BE9300. Can’t do the upgrade of dnsmasq-full. It’s missing a depency “libubus20251202“ which it can’t find in the repo.