CVE-2026-4893: Medium severity Dnsmasq Dnsmasq vulnerability
An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet with RFC 7871 client subnet information.
Other sources
In forward.c:724, processreply() calls checksource(header, plen, pheader, querysource) but plen at this point holds the OPT record length (~23 bytes), not the packet length n. With the wrong length, all bounds checks inside checksource() fail and the function unconditionally returns 1, bypassing RFC 7871 Section 9.2 ECS source validation entirely. Fix: change plen to n in the function call.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/dnsmasqto a version that resolves this vulnerability.Fixed in 2.90-4~deb12u2Fixed in 2.91-1+deb13u1Fixed in 2.92-5 - Configuration
In forward.c (process_reply at line 724), change the function call so check_source(header, plen, pheader, query_source) uses plen set to n (the packet length), not the OPT record length (~23 bytes), i.e., change plen to n in the function call.
dnsmasq (forward.c: process_reply / check_source) ECS length argument (plen) = set plen to n - Operational
Rebuild and redeploy dnsmasq after applying the forward.c change (plen to n) so that check_source() bounds checks and RFC 7871 Section 9.2 ECS source validation are no longer bypassed for crafted packets.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-4893?
CVE-2026-4893 is rated as a moderate severity vulnerability due to its potential for information disclosure.
How do I fix CVE-2026-4893?
You can mitigate CVE-2026-4893 by upgrading dnsmasq to versions 2.90-4~deb12u2, 2.91-1+deb13u1, or 2.92-5.
What type of attacks can exploit CVE-2026-4893?
CVE-2026-4893 can be exploited by remote attackers using crafted DNS packets with manipulated client subnet information.
Which versions of dnsmasq are affected by CVE-2026-4893?
Affected versions of dnsmasq include versions prior to 2.90-4~deb12u2, 2.91-1+deb13u1, and 2.92-5.
Is there a way to prevent CVE-2026-4893 from being exploited?
Preventing CVE-2026-4893 can involve implementing network-level protections and ensuring dnsmasq is updated to a secure version.