Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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

5412 vulnerabilities reference this CWE, most recent first.

GHSA-WPHV-VFRH-23Q5

Vulnerability from github – Published: 2026-06-26 20:59 – Updated: 2026-06-26 20:59
VLAI
Summary
joserfc: b64=false RFC7797 JWS payloads bypass JWSRegistry payload-size limits during deserialization
Details

RFC7797 b64=false JWS payloads bypass JWSRegistry payload-size limits during deserialization

Summary

Testing revealed that joserfc accepts oversized RFC7797 b64=false JWS payloads without applying JWSRegistry.max_payload_length.

The normal JWS compact and flattened JSON paths reject payloads above the configured payload-size limit with ExceededSizeError. The RFC7797 unencoded payload paths do not make the same check. A valid b64=false compact or flattened JSON JWS can therefore deserialize successfully with a payload larger than JWSRegistry.max_payload_length.

This creates a moderate availability/resource-exhaustion risk for applications that accept lower-trust JWS values and rely on joserfc to reject oversized token content during verification.

Affected Product

  • Package: joserfc
  • Ecosystem: pip
  • Audited release: 1.6.5
  • Audit tag: 1.6.5
  • Audit commit: 881712980934fb601bed26fe3ae1ec0b7780e6f7
  • Tested affected releases: 1.3.4, 1.3.5, 1.4.2, 1.6.2, 1.6.3, 1.6.4, 1.6.5
  • Fixed release: none known

Vulnerability Details

In joserfc 1.6.5, the default JWS registry has max_payload_length = 128000 and exposes validate_payload_size().

The normal compact extraction path calls that check before base64url-decoding the payload. The RFC7797 compact path validates the header and signature segment sizes, then assigns the unencoded payload directly:

if is_rfc7797_enabled(protected):
    if not payload_segment and payload:
        payload_segment = to_bytes(payload)
    payload = payload_segment

The flattened JSON RFC7797 path has the same pattern:

payload_segment = value["payload"].encode("utf-8")
if is_rfc7797_enabled(member.headers()):
    payload = payload_segment

Neither branch calls registry.validate_payload_size(payload_segment) before accepting the unencoded payload.

Reproduction

The proof below uses only local Python APIs. It signs a payload one byte over the default limit and then compares normal JWS behavior with RFC7797 b64=false behavior.

Requirements:

python -m pip install "joserfc==1.6.5"

Run:

python joserfc_rfc7797_size_bypass_poc.py

Self-contained proof script:

#!/usr/bin/env python3
import json

import joserfc
from joserfc import jws
from joserfc.jwk import OctKey


def check_compact(name, header, payload, key):
    token = jws.serialize_compact(header, payload, key)
    try:
        obj = jws.deserialize_compact(token, key)
        return {
            "case": name,
            "accepted": True,
            "exception": None,
            "payload_len_after_deserialize": len(obj.payload),
        }
    except Exception as exc:
        return {
            "case": name,
            "accepted": False,
            "exception": type(exc).__name__,
            "error": str(exc),
        }


def check_json(name, protected, payload, key):
    data = jws.serialize_json({"protected": protected}, payload, key)
    try:
        obj = jws.deserialize_json(data, key)
        return {
            "case": name,
            "accepted": True,
            "exception": None,
            "payload_len_after_deserialize": len(obj.payload),
        }
    except Exception as exc:
        return {
            "case": name,
            "accepted": False,
            "exception": type(exc).__name__,
            "error": str(exc),
        }


key = OctKey.import_key("secret-secret-secret")
limit = jws.default_registry.max_payload_length
payload = "A" * (limit + 1)

results = {
    "joserfc_version": joserfc.__version__,
    "default_max_payload_length": limit,
    "payload_len": len(payload),
    "compact": [
        check_compact("normal_b64_true", {"alg": "HS256"}, payload, key),
        check_compact(
            "rfc7797_b64_false",
            {"alg": "HS256", "b64": False, "crit": ["b64"]},
            payload,
            key,
        ),
    ],
    "json": [
        check_json("normal_b64_true_json", {"alg": "HS256"}, payload, key),
        check_json(
            "rfc7797_b64_false_json",
            {"alg": "HS256", "b64": False, "crit": ["b64"]},
            payload,
            key,
        ),
    ],
}
print(json.dumps(results, indent=2, sort_keys=True))

Expected output on 1.6.5 includes:

{
  "default_max_payload_length": 128000,
  "payload_len": 128001,
  "compact": [
    {
      "case": "normal_b64_true",
      "accepted": false,
      "exception": "ExceededSizeError"
    },
    {
      "case": "rfc7797_b64_false",
      "accepted": true,
      "exception": null,
      "payload_len_after_deserialize": 128001
    }
  ],
  "json": [
    {
      "case": "normal_b64_true_json",
      "accepted": false,
      "exception": "ExceededSizeError"
    },
    {
      "case": "rfc7797_b64_false_json",
      "accepted": true,
      "exception": null,
      "payload_len_after_deserialize": 128001
    }
  ]
}

Version Checks

I reproduced the same differential behavior on these releases:

Version Normal JWS over limit RFC7797 b64=false over limit
1.3.4 ExceededSizeError accepted
1.3.5 ExceededSizeError accepted
1.4.2 ExceededSizeError accepted
1.6.2 ExceededSizeError accepted
1.6.3 ExceededSizeError accepted
1.6.4 ExceededSizeError accepted
1.6.5 ExceededSizeError accepted

The exact earliest affected release may be broader. The versions above are the releases I directly tested where the JWS size-limit boundary exists and the RFC7797 path bypasses it.

Relationship to Existing Advisories

I found two related public advisories for joserfc, but neither appears to cover this root cause.

GHSA-frfh-8v73-gjg4 / CVE-2025-65015 describes oversized token parts being included in ExceededSizeError messages in older release ranges. The issue described here reproduces in 1.6.5 and is not about exception message content. The oversized RFC7797 payload is accepted instead of raising ExceededSizeError.

GHSA-w5r5-m38g-f9f9 / CVE-2026-27932 describes unbounded PBES2 p2c iteration counts during JWE decryption. The issue described here is in JWS RFC7797 payload extraction and does not involve PBES2 or JWE decryption.

Workarounds

Before a fixed release is available, affected applications can reduce exposure by rejecting oversized serialized JWS inputs before passing them to joserfc, disabling or disallowing RFC7797 b64=false tokens if not needed, and enforcing strict request/header/body size limits at the application or reverse-proxy layer.

Suggested Remediation

Apply registry.validate_payload_size(payload_segment) to RFC7797 unencoded payloads before assigning them to the JWS object in both compact and flattened JSON extraction paths. Detached RFC7797 compact payloads supplied through the payload argument should be checked in the same way.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "joserfc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.4"
            },
            {
              "fixed": "1.6.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48990"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T20:59:38Z",
    "nvd_published_at": "2026-06-17T22:16:23Z",
    "severity": "MODERATE"
  },
  "details": "# RFC7797 b64=false JWS payloads bypass JWSRegistry payload-size limits during deserialization\n\n## Summary\n\nTesting revealed that `joserfc` accepts oversized RFC7797 `b64=false` JWS payloads without applying `JWSRegistry.max_payload_length`.\n\nThe normal JWS compact and flattened JSON paths reject payloads above the configured payload-size limit with `ExceededSizeError`. The RFC7797 unencoded payload paths do not make the same check. A valid `b64=false` compact or flattened JSON JWS can therefore deserialize successfully with a payload larger than `JWSRegistry.max_payload_length`.\n\nThis creates a moderate availability/resource-exhaustion risk for applications that accept lower-trust JWS values and rely on `joserfc` to reject oversized token content during verification.\n\n## Affected Product\n\n- Package: `joserfc`\n- Ecosystem: `pip`\n- Audited release: `1.6.5`\n- Audit tag: `1.6.5`\n- Audit commit: `881712980934fb601bed26fe3ae1ec0b7780e6f7`\n- Tested affected releases: `1.3.4`, `1.3.5`, `1.4.2`, `1.6.2`, `1.6.3`, `1.6.4`, `1.6.5`\n- Fixed release: none known\n\n## Vulnerability Details\n\nIn `joserfc` 1.6.5, the default JWS registry has `max_payload_length = 128000` and exposes `validate_payload_size()`.\n\nThe normal compact extraction path calls that check before base64url-decoding the payload. The RFC7797 compact path validates the header and signature segment sizes, then assigns the unencoded payload directly:\n\n```text\nif is_rfc7797_enabled(protected):\n    if not payload_segment and payload:\n        payload_segment = to_bytes(payload)\n    payload = payload_segment\n```\n\nThe flattened JSON RFC7797 path has the same pattern:\n\n```text\npayload_segment = value[\"payload\"].encode(\"utf-8\")\nif is_rfc7797_enabled(member.headers()):\n    payload = payload_segment\n```\n\nNeither branch calls `registry.validate_payload_size(payload_segment)` before accepting the unencoded payload.\n\n## Reproduction\n\nThe proof below uses only local Python APIs. It signs a payload one byte over the default limit and then compares normal JWS behavior with RFC7797 `b64=false` behavior.\n\nRequirements:\n\n```bash\npython -m pip install \"joserfc==1.6.5\"\n```\n\nRun:\n\n```bash\npython joserfc_rfc7797_size_bypass_poc.py\n```\n\nSelf-contained proof script:\n\n```python\n#!/usr/bin/env python3\nimport json\n\nimport joserfc\nfrom joserfc import jws\nfrom joserfc.jwk import OctKey\n\n\ndef check_compact(name, header, payload, key):\n    token = jws.serialize_compact(header, payload, key)\n    try:\n        obj = jws.deserialize_compact(token, key)\n        return {\n            \"case\": name,\n            \"accepted\": True,\n            \"exception\": None,\n            \"payload_len_after_deserialize\": len(obj.payload),\n        }\n    except Exception as exc:\n        return {\n            \"case\": name,\n            \"accepted\": False,\n            \"exception\": type(exc).__name__,\n            \"error\": str(exc),\n        }\n\n\ndef check_json(name, protected, payload, key):\n    data = jws.serialize_json({\"protected\": protected}, payload, key)\n    try:\n        obj = jws.deserialize_json(data, key)\n        return {\n            \"case\": name,\n            \"accepted\": True,\n            \"exception\": None,\n            \"payload_len_after_deserialize\": len(obj.payload),\n        }\n    except Exception as exc:\n        return {\n            \"case\": name,\n            \"accepted\": False,\n            \"exception\": type(exc).__name__,\n            \"error\": str(exc),\n        }\n\n\nkey = OctKey.import_key(\"secret-secret-secret\")\nlimit = jws.default_registry.max_payload_length\npayload = \"A\" * (limit + 1)\n\nresults = {\n    \"joserfc_version\": joserfc.__version__,\n    \"default_max_payload_length\": limit,\n    \"payload_len\": len(payload),\n    \"compact\": [\n        check_compact(\"normal_b64_true\", {\"alg\": \"HS256\"}, payload, key),\n        check_compact(\n            \"rfc7797_b64_false\",\n            {\"alg\": \"HS256\", \"b64\": False, \"crit\": [\"b64\"]},\n            payload,\n            key,\n        ),\n    ],\n    \"json\": [\n        check_json(\"normal_b64_true_json\", {\"alg\": \"HS256\"}, payload, key),\n        check_json(\n            \"rfc7797_b64_false_json\",\n            {\"alg\": \"HS256\", \"b64\": False, \"crit\": [\"b64\"]},\n            payload,\n            key,\n        ),\n    ],\n}\nprint(json.dumps(results, indent=2, sort_keys=True))\n```\n\nExpected output on `1.6.5` includes:\n\n```json\n{\n  \"default_max_payload_length\": 128000,\n  \"payload_len\": 128001,\n  \"compact\": [\n    {\n      \"case\": \"normal_b64_true\",\n      \"accepted\": false,\n      \"exception\": \"ExceededSizeError\"\n    },\n    {\n      \"case\": \"rfc7797_b64_false\",\n      \"accepted\": true,\n      \"exception\": null,\n      \"payload_len_after_deserialize\": 128001\n    }\n  ],\n  \"json\": [\n    {\n      \"case\": \"normal_b64_true_json\",\n      \"accepted\": false,\n      \"exception\": \"ExceededSizeError\"\n    },\n    {\n      \"case\": \"rfc7797_b64_false_json\",\n      \"accepted\": true,\n      \"exception\": null,\n      \"payload_len_after_deserialize\": 128001\n    }\n  ]\n}\n```\n\n## Version Checks\n\nI reproduced the same differential behavior on these releases:\n\n| Version | Normal JWS over limit | RFC7797 `b64=false` over limit |\n| --- | --- | --- |\n| 1.3.4 | `ExceededSizeError` | accepted |\n| 1.3.5 | `ExceededSizeError` | accepted |\n| 1.4.2 | `ExceededSizeError` | accepted |\n| 1.6.2 | `ExceededSizeError` | accepted |\n| 1.6.3 | `ExceededSizeError` | accepted |\n| 1.6.4 | `ExceededSizeError` | accepted |\n| 1.6.5 | `ExceededSizeError` | accepted |\n\nThe exact earliest affected release may be broader. The versions above are the releases I directly tested where the JWS size-limit boundary exists and the RFC7797 path bypasses it.\n\n## Relationship to Existing Advisories\n\nI found two related public advisories for `joserfc`, but neither appears to cover this root cause.\n\n`GHSA-frfh-8v73-gjg4` / `CVE-2025-65015` describes oversized token parts being included in `ExceededSizeError` messages in older release ranges. The issue described here reproduces in `1.6.5` and is not about exception message content. The oversized RFC7797 payload is accepted instead of raising `ExceededSizeError`.\n\n`GHSA-w5r5-m38g-f9f9` / `CVE-2026-27932` describes unbounded PBES2 `p2c` iteration counts during JWE decryption. The issue described here is in JWS RFC7797 payload extraction and does not involve PBES2 or JWE decryption.\n\n## Workarounds\n\nBefore a fixed release is available, affected applications can reduce exposure by rejecting oversized serialized JWS inputs before passing them to `joserfc`, disabling or disallowing RFC7797 `b64=false` tokens if not needed, and enforcing strict request/header/body size limits at the application or reverse-proxy layer.\n\n## Suggested Remediation\n\nApply `registry.validate_payload_size(payload_segment)` to RFC7797 unencoded payloads before assigning them to the JWS object in both compact and flattened JSON extraction paths. Detached RFC7797 compact payloads supplied through the `payload` argument should be checked in the same way.",
  "id": "GHSA-wphv-vfrh-23q5",
  "modified": "2026-06-26T20:59:38Z",
  "published": "2026-06-26T20:59:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/joserfc/security/advisories/GHSA-wphv-vfrh-23q5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48990"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/joserfc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/joserfc/releases/tag/1.6.7"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "joserfc: b64=false RFC7797 JWS payloads bypass JWSRegistry payload-size limits during deserialization"
}

GHSA-WPP8-MVVG-33RX

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

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript. In Rocket.Chat before versions 3.11.3, 3.12.2, and 3.13 an issue with certain regular expressions could lead potentially to Denial of Service. This was fixed in versions 3.11.3, 3.12.2, and 3.13.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-32832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-30T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript. In Rocket.Chat before versions 3.11.3, 3.12.2, and 3.13 an issue with certain regular expressions could lead potentially to Denial of Service. This was fixed in versions 3.11.3, 3.12.2, and 3.13.",
  "id": "GHSA-wpp8-mvvg-33rx",
  "modified": "2022-05-24T19:12:25Z",
  "published": "2022-05-24T19:12:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32832"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RocketChat/Rocket.Chat/commit/4a0dce973e37ec3f56ca2231d6030511dbdd094c"
    },
    {
      "type": "WEB",
      "url": "https://docs.rocket.chat/guides/security/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RocketChat/Rocket.Chat/releases/tag/3.11.3"
    },
    {
      "type": "ADVISORY",
      "url": "https://securitylab.github.com/advisories/GHSL-2020-310-redos-Rocket.Chat"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WPV5-97WM-HP9C

Vulnerability from github – Published: 2025-10-07 17:28 – Updated: 2025-10-13 15:30
VLAI
Summary
Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
Details

Summary

Rack::Multipart::Parser can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (CRLFCRLF). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).

Details

While reading multipart headers, the parser waits for CRLFCRLF using:

@sbuf.scan_until(/(.*?\r\n)\r\n/m)

If the terminator never appears, it continues appending data (@sbuf.concat(content)) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size.

Impact

Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected.

Mitigation

  • Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB).
  • Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx client_max_body_size).
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1"
            },
            {
              "fixed": "3.1.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-07T17:28:06Z",
    "nvd_published_at": "2025-10-07T15:16:03Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`Rack::Multipart::Parser` can accumulate unbounded data when a multipart part\u2019s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).\n\n## Details\n\nWhile reading multipart headers, the parser waits for `CRLFCRLF` using:\n\n```ruby\n@sbuf.scan_until(/(.*?\\r\\n)\\r\\n/m)\n```\n\nIf the terminator never appears, it continues appending data (`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size.\n\n## Impact\n\nAttackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected.\n\n## Mitigation\n\n* Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB).\n* Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx `client_max_body_size`).",
  "id": "GHSA-wpv5-97wm-hp9c",
  "modified": "2025-10-13T15:30:01Z",
  "published": "2025-10-07T17:28:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61772"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2025-61772.yml"
    }
  ],
  "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": "Rack\u0027s multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)"
}

GHSA-WPX5-PXJJ-77QQ

Vulnerability from github – Published: 2026-05-12 21:31 – Updated: 2026-05-12 21:31
VLAI
Details

CAI Content Credentials versions 0.78.2, 0.7.0 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-34677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T20:16:38Z",
    "severity": "MODERATE"
  },
  "details": "CAI Content Credentials versions 0.78.2, 0.7.0 and earlier are affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-wpx5-pxjj-77qq",
  "modified": "2026-05-12T21:31:34Z",
  "published": "2026-05-12T21:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34677"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/content-authenticity-sdk/apsb26-53.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQ2P-Q66W-Q8GP

Vulnerability from github – Published: 2022-05-14 01:10 – Updated: 2024-02-22 16:11
VLAI
Summary
Apache Tomcat Denial of Service vulnerability
Details

Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 processes chunked transfer coding without properly handling (1) a large total amount of chunked data or (2) whitespace characters in an HTTP header value within a trailer field, which allows remote attackers to cause a denial of service by streaming data. NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3544.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0-RC1"
            },
            {
              "fixed": "8.0.0-RC10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-4322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-17T23:32:20Z",
    "nvd_published_at": "2014-02-26T14:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Apache Tomcat before 6.0.39, 7.x before 7.0.50, and 8.x before 8.0.0-RC10 processes chunked transfer coding without properly handling (1) a large total amount of chunked data or (2) whitespace characters in an HTTP header value within a trailer field, which allows remote attackers to cause a denial of service by streaming data.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2012-3544.",
  "id": "GHSA-wq2p-q66w-q8gp",
  "modified": "2024-02-22T16:11:25Z",
  "published": "2022-05-14T01:10:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4322"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/70dc3b279f7c99136c2c51bce8812508b4893c8b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/72613a0e2f88af789c2acc7093c82ff02b95b6d1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/a91516b80deaf1d0c6e04a7931765fdac34c4ccd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/b8cb9f5f91e9210ca107fd80f3e6acd47531daa7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/bed3a1a0d06a3c787183c6e90f326bbe17e49dd4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/tomcat/commit/d6a9898125f34e593de426e8c7dabb0f224fc00f"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20161024220018/http://secunia.com/advisories/59724"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20161024215804/http://secunia.com/advisories/59675"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20161024215639/http://secunia.com/advisories/59722"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20161024215620/http://secunia.com/advisories/59036"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20151023203543/http://secunia.com/advisories/59873"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20150503090027/http://www.securityfocus.com/archive/1/534161/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20140315211337/http://www.securityfocus.com/bid/65767"
    },
    {
      "type": "WEB",
      "url": "https://rhn.redhat.com/errata/RHSA-2014-0686.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r587e50b86c1a96ee301f751d50294072d142fd6dc08a8987ae9f3a9b@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r03c597a64de790ba42c167efacfa23300c3d6c9fe589ab87fe02859c@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b8a1bf18155b552dcf9a928ba808cbadad84c236d85eab3033662cfb@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/b84ad1258a89de5c9c853c7f2d3ad77e5b8b2930be9e132d5cef6b95@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/39ae1f0bd5867c15755a6f959b271ade1aea04ccdc3b2e639dcd903b@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/37220405a377c0182d2afdbc36461c4783b2930fbeae3a17f1333113@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://h20564.www2.hpe.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c04851013"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/tomcat"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1069905"
    },
    {
      "type": "WEB",
      "url": "http://advisories.mageia.org/MGASA-2014-0148.html"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=144498216801440\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2014/Dec/23"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1521834"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1521864"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1549522"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1549523"
    },
    {
      "type": "WEB",
      "url": "http://svn.apache.org/viewvc?view=revision\u0026revision=1556540"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-6.html"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-7.html"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-8.html"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21667883"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21675886"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21677147"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21678113"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21678231"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2016/dsa-3530"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:052"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:084"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2130-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2014-0008.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2014-0012.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Apache Tomcat Denial of Service vulnerability"
}

GHSA-WQ3V-5978-56CH

Vulnerability from github – Published: 2022-05-17 04:52 – Updated: 2025-04-11 04:19
VLAI
Details

The tcp_rcv_state_process function in net/ipv4/tcp_input.c in the Linux kernel before 3.2.24 allows remote attackers to cause a denial of service (kernel resource consumption) via a flood of SYN+FIN TCP packets, a different vulnerability than CVE-2012-2663.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-6638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-02-15T14:57:00Z",
    "severity": "HIGH"
  },
  "details": "The tcp_rcv_state_process function in net/ipv4/tcp_input.c in the Linux kernel before 3.2.24 allows remote attackers to cause a denial of service (kernel resource consumption) via a flood of SYN+FIN TCP packets, a different vulnerability than CVE-2012-2663.",
  "id": "GHSA-wq3v-5978-56ch",
  "modified": "2025-04-11T04:19:11Z",
  "published": "2022-05-17T04:52:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-6638"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/fdf5af0daf8019cec2396cdef8fb042d80fe71fa"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=826702"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=fdf5af0daf8019cec2396cdef8fb042d80fe71fa"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fdf5af0daf8019cec2396cdef8fb042d80fe71fa"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WQ8H-Q5G7-J5PR

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

ise smart connect KNX Vaillant 1.2.839 contain a Denial of Service.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-19643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-14T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "ise smart connect KNX Vaillant 1.2.839 contain a Denial of Service.",
  "id": "GHSA-wq8h-q5g7-j5pr",
  "modified": "2022-05-24T17:25:42Z",
  "published": "2022-05-24T17:25:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19643"
    },
    {
      "type": "WEB",
      "url": "https://psytester.github.io/CVE-2019-19643"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-WQCH-XFXH-VRR4

Vulnerability from github – Published: 2025-11-25 14:20 – Updated: 2025-11-25 18:09
VLAI
Summary
body-parser is vulnerable to denial of service when url encoding is used
Details

Impact

body-parser 2.2.0 is vulnerable to denial of service due to inefficient handling of URL-encoded bodies with very large numbers of parameters. An attacker can send payloads containing thousands of parameters within the default 100KB request size limit, causing elevated CPU and memory usage. This can lead to service slowdown or partial outages under sustained malicious traffic.

Patches

This issue is addressed in version 2.2.1.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
5.5 (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:L/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "body-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-13466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-25T14:20:21Z",
    "nvd_published_at": "2025-11-24T19:15:46Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nbody-parser 2.2.0 is vulnerable to denial of service due to inefficient handling of URL-encoded bodies with very large numbers of parameters. An attacker can send payloads containing thousands of parameters within the default 100KB request size limit, causing elevated CPU and memory usage. This can lead to service slowdown or partial outages under sustained malicious traffic.\n\n### Patches\n\nThis issue is addressed in version 2.2.1.",
  "id": "GHSA-wqch-xfxh-vrr4",
  "modified": "2025-11-25T18:09:52Z",
  "published": "2025-11-25T14:20:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/body-parser/security/advisories/GHSA-wqch-xfxh-vrr4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13466"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/body-parser/commit/b204886a6744b0b6d297cd0e849d75de836f3b63"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/expressjs/body-parser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/body-parser/releases/tag/v2.2.1"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "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:L/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "body-parser is vulnerable to denial of service when url encoding is used"
}

GHSA-WQFR-R3Q7-6HMM

Vulnerability from github – Published: 2022-02-12 00:01 – Updated: 2022-09-02 00:01
VLAI
Details

StarWind iSCSI SAN before 3.5 build 2007-08-09 allows socket exhaustion.

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-2007-20001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-06T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "StarWind iSCSI SAN before 3.5 build 2007-08-09 allows socket exhaustion.",
  "id": "GHSA-wqfr-r3q7-6hmm",
  "modified": "2022-09-02T00:01:11Z",
  "published": "2022-02-12T00:01:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-20001"
    },
    {
      "type": "WEB",
      "url": "https://www.starwindsoftware.com/security/sw-20070601-0001"
    }
  ],
  "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"
    }
  ]
}

GHSA-WQH8-3GRF-J8JP

Vulnerability from github – Published: 2023-05-26 18:30 – Updated: 2024-04-04 04:20
VLAI
Details

mp4v2 v2.1.2 was discovered to contain a memory leak via the class MP4BytesProperty.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-33720"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-26T16:15:10Z",
    "severity": "MODERATE"
  },
  "details": "mp4v2 v2.1.2 was discovered to contain a memory leak via the class MP4BytesProperty.",
  "id": "GHSA-wqh8-3grf-j8jp",
  "modified": "2024-04-04T04:20:46Z",
  "published": "2023-05-26T18:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33720"
    },
    {
      "type": "WEB",
      "url": "https://github.com/enzo1982/mp4v2/issues/36"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

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

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

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

Mitigation
Implementation

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

CAPEC-147: XML Ping of the Death

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

CAPEC-227: Sustained Client Engagement

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

CAPEC-492: Regular Expression Exponential Blowup

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

← Back to the CWE list