CVE-2026-46600

What it actually does

The flaw is a denial-of-service vulnerability in DNS resource-record parsing. When software parses a malformed SVCB or HTTPS DNS resource record, an invalid parameter length can overflow the bounds of the DNS message buffer and trigger a panic or crash. The expected result is process termination or service instability in software that performs vulnerable parsing of SVCB/HTTPS records, such as DNS resolvers, DNS clients, service-discovery components, or applications that directly consume DNS responses.

Why it matters to the business

Successful exploitation can interrupt name resolution or application connectivity, causing service outages, degraded user experience, failed outbound connections, and operational instability. Because SVCB and HTTPS records are increasingly used for modern service discovery and connection optimization, exposed resolvers or applications that parse untrusted DNS responses may be affected even without direct user interaction. The current EPSS score is low and there is no known KEV listing or mature public exploit indicated, so urgency is primarily driven by whether affected DNS parsing code is internet-facing, recursive, or used in high-availability production paths.

How an attack unfolds

An attacker needs a way to cause vulnerable software to parse a crafted DNS response containing an invalid SVCB or HTTPS resource record. This may be done by operating an attacker-controlled authoritative DNS zone and causing the target to resolve a name in that zone, by influencing application lookups, or by injecting/spoofing DNS traffic where network position allows. The malicious response contains a parameter whose encoded value length causes the parser to read beyond or overflow the DNS message buffer. Instead of safely rejecting the malformed record, the vulnerable parser panics, causing the process or service to crash. Repeated queries can be used to produce recurring denial of service until the software is patched, restarted with mitigations, or prevented from processing the malformed records.

How to fix it

Upgrade affected software to a vendor-fixed version once identified by the relevant DNS library, resolver, operating system, or application vendor. No product-specific fixed versions were provided in the input, so organizations should inventory software that parses DNS SVCB/HTTPS records and follow vendor advisories for exact package versions. Where immediate patching is not possible, consider temporary mitigations such as disabling SVCB/HTTPS record processing if supported, filtering malformed SVCB/HTTPS responses at DNS security gateways, restricting which systems can receive recursive DNS responses from untrusted networks, enforcing DNSSEC validation where applicable, and ensuring affected services are supervised with restart limits and monitoring to avoid restart loops.

How to confirm the fix worked

Confirm exposure by identifying DNS resolvers, applications, libraries, and OS components that support or parse SVCB or HTTPS resource records, then compare installed versions against vendor advisories. Validate remediation by upgrading to the vendor-fixed release and testing that malformed SVCB/HTTPS records are rejected without a panic, crash, or service restart. Operationally, verify that DNS services remain stable under malformed-record test cases in a non-production environment, that crash counters do not increase, and that service logs no longer show parser panics related to SVCB, HTTPS, or DNS message-buffer bounds.

Typical attack path

1. Identify software that parses DNS SVCB or HTTPS resource records using the vulnerable implementation.
2. Prepare an authoritative DNS response or DNS zone containing a malformed SVCB or HTTPS record with an invalid parameter length.
3. Cause the target resolver, client, or application to query the attacker-controlled name or otherwise receive the crafted DNS response.
4. Trigger the vulnerable parser to process the malformed record.
5. Crash the affected process or service, causing name-resolution failure or application disruption.
6. Repeat the trigger to sustain service instability if automatic restart or retry mechanisms are present.

How to detect it

To determine whether this was already exploited, review DNS resolver logs, application logs, system journals, crash dumps, and service supervisor logs for crashes or panics occurring immediately after SVCB or HTTPS record lookups. Focus on repeated crashes of DNS-related processes, application components that perform outbound name resolution, or libraries that log DNS parsing errors. Correlate timestamps of crashes with DNS query logs for type SVCB, type HTTPS, RR type 64, or RR type 65, especially queries to unusual, newly registered, low-reputation, or attacker-controlled domains. Look for repeated resolver restarts, core dumps, panic stack traces mentioning DNS record parsing, parameter length handling, message buffer bounds, or malformed SVCB/HTTPS records. Network telemetry may show DNS responses containing SVCB/HTTPS records shortly before the crash; packet captures can be inspected for abnormal parameter lengths or truncated/oversized RDATA fields.

• SVCB
• HTTPS RR
• type 64
• type 65
• RR type 64
• RR type 65
• panic
• core dumped
• segmentation fault
• message buffer
• overflows the message buffer
• invalid SVCB
• invalid HTTPS RR
• malformed SVCB
• malformed HTTPS
• DNS parser panic
• SVCB parameter
• HTTPS parameter
• parameter value overflows
• resolver restart
• named restarted
• unbound restarted
• systemd-coredump

What your security team should do

• Inventory DNS resolvers, DNS forwarders, client libraries, service meshes, proxies, browsers, and applications that parse SVCB or HTTPS DNS records.
• Monitor vendor advisories for the affected DNS parsing implementation and apply fixed versions as soon as available.
• Prioritize patching internet-facing recursive resolvers, shared DNS infrastructure, and high-availability application components that process untrusted DNS responses.
• If patching is delayed, disable SVCB/HTTPS record handling where feasible or filter malformed responses using DNS security controls.
• Add monitoring for process crashes, panic messages, resolver restarts, and spikes in SERVFAIL/timeouts correlated with SVCB or HTTPS lookups.
• Review DNS logs for queries to newly observed or suspicious domains immediately before resolver or application crashes.
• Ensure critical DNS services have safe restart policies, alerting, and capacity controls to prevent repeated crash loops from amplifying outages.