Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

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

6465 vulnerabilities reference this CWE, most recent first.

GHSA-3PPH-FPJX-JG34

Vulnerability from github – Published: 2026-09-28 21:34 – Updated: 2026-09-28 21:34
VLAI
Summary
multer vulnerable to Denial of Service via orphaned disk writes on aborted uploads
Details

Impact

Multer's diskStorage can leave complete, orphaned files on disk when a multipart upload is aborted in the brief window before the storage engine assigns the file path. This is an incomplete fix of CVE-2026-5038: the earlier cleanup removes only in-flight uploads that already have a path, so an upload aborted inside that window is written to disk with nothing left to remove it, and the application is not given a handle to clean it up. An unauthenticated attacker sending aborted requests to any route backed by disk storage can accumulate orphaned files until the upload directory or the shared system temporary directory is exhausted. An asynchronous destination or filename widens the window.

Patches

Users should upgrade to 2.4.0 or higher.

Workarounds

None.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "multer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-459"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-28T21:34:58Z",
    "nvd_published_at": "2026-09-14T09:17:01Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nMulter\u0027s `diskStorage` can leave complete, orphaned files on disk when a multipart upload is aborted in the brief window before the storage engine assigns the file path. This is an incomplete fix of CVE-2026-5038: the earlier cleanup removes only in-flight uploads that already have a path, so an upload aborted inside that window is written to disk with nothing left to remove it, and the application is not given a handle to clean it up. An unauthenticated attacker sending aborted requests to any route backed by disk storage can accumulate orphaned files until the upload directory or the shared system temporary directory is exhausted. An asynchronous `destination` or `filename` widens the window.\n\n### Patches\n\nUsers should upgrade to `2.4.0` or higher.\n\n### Workarounds\n\nNone.",
  "id": "GHSA-3pph-fpjx-jg34",
  "modified": "2026-09-28T21:34:58Z",
  "published": "2026-09-28T21:34:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/security/advisories/GHSA-3pph-fpjx-jg34"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/commit/53337f9713619ef3381ee6b4e541f926dbaac305"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/expressjs/multer"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/releases/tag/v2.4.0"
    }
  ],
  "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": "multer vulnerable to Denial of Service via orphaned disk writes on aborted uploads"
}

GHSA-3PRJ-6HQW-CM82

Vulnerability from github – Published: 2026-06-18 21:09 – Updated: 2026-07-15 21:51
VLAI
Summary
PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
Details

Impact

When a JWE uses a password-based key-encryption algorithm (PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW), PBES2AESKW::unwrapKey() reads the p2c (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header and passes it to hash_pbkdf2() with no upper bound. The only validation performed (checkHeaderAdditionalParameters()) was is_int($p2c) && $p2c > 0.

An unauthenticated attacker can craft a single JWE whose protected header sets a very large p2c (e.g. 100_000_000 ≈ 87 s of CPU, or PHP_INT_MAX), forcing a worker to spend an arbitrary amount of CPU inside PBKDF2 before the key unwrap can even fail. The decrypter swallows the eventual exception, so the attacker pays almost nothing while the server burns CPU. JSON General serialization (multiple recipients) and multi-key JWKSets multiply the cost. This is a classic uncontrolled-resource-consumption (CWE-400) denial of service.

Affected configurations

Applications that register any PBES2-HS*+A*KW algorithm in their decryption AlgorithmManager.

Patches

PBES2AESKW now enforces a configurable maximum iteration count (DEFAULT_MAX_COUNT = 1_000_000, well above realistic legitimate values which are a few thousand) in checkHeaderAdditionalParameters(), before any PBKDF2 computation. The bound is exposed as a constructor argument so operators can tune it.

Workarounds

Before upgrading: validate/limit the p2c header with a custom header checker, or do not enable PBES2 algorithms for untrusted tokens.

References

  • RFC 7518 §4.8 (PBES2)
  • CWE-400: Uncontrolled Resource Consumption

Résolution

Un correctif a été préparé sur une branche dédiée basée sur 3.4.x, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).

PBES2 — PBES2AESKW::unwrapKey() borne désormais le paramètre p2c (constante DEFAULT_MAX_COUNT = 1_000_000, configurable via le constructeur) avant tout appel à hash_pbkdf2(), empêchant l'amplification CPU (DoS).

Validation : php -l OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs 3.4.x), aucun commentaire ajouté dans le code source. Après merge, cascade prévue 3.4.x → 4.0.x → 4.1.x.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-library"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "web-token/jwt-framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T21:09:01Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen a JWE uses a password-based key-encryption algorithm (`PBES2-HS256+A128KW`, `PBES2-HS384+A192KW`, `PBES2-HS512+A256KW`), `PBES2AESKW::unwrapKey()` reads the `p2c` (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header and passes it to `hash_pbkdf2()` with **no upper bound**. The only validation performed (`checkHeaderAdditionalParameters()`) was `is_int($p2c) \u0026\u0026 $p2c \u003e 0`.\n\nAn unauthenticated attacker can craft a single JWE whose protected header sets a very large `p2c` (e.g. `100_000_000` \u2248 87 s of CPU, or `PHP_INT_MAX`), forcing a worker to spend an arbitrary amount of CPU inside PBKDF2 **before** the key unwrap can even fail. The decrypter swallows the eventual exception, so the attacker pays almost nothing while the server burns CPU. JSON General serialization (multiple recipients) and multi-key JWKSets multiply the cost. This is a classic uncontrolled-resource-consumption (CWE-400) denial of service.\n\n### Affected configurations\n\nApplications that register any `PBES2-HS*+A*KW` algorithm in their decryption `AlgorithmManager`.\n\n### Patches\n\n`PBES2AESKW` now enforces a configurable maximum iteration count (`DEFAULT_MAX_COUNT = 1_000_000`, well above realistic legitimate values which are a few thousand) in `checkHeaderAdditionalParameters()`, before any PBKDF2 computation. The bound is exposed as a constructor argument so operators can tune it.\n\n### Workarounds\n\nBefore upgrading: validate/limit the `p2c` header with a custom header checker, or do not enable PBES2 algorithms for untrusted tokens.\n\n### References\n\n- RFC 7518 \u00a74.8 (PBES2)\n- CWE-400: Uncontrolled Resource Consumption\n\n## R\u00e9solution\n\nUn correctif a \u00e9t\u00e9 pr\u00e9par\u00e9 sur une branche d\u00e9di\u00e9e bas\u00e9e sur `3.4.x`, avec des tests anti-r\u00e9gression d\u00e9di\u00e9s (fork priv\u00e9 temporaire de cette advisory, PR #1).\n\n**PBES2** \u2014 `PBES2AESKW::unwrapKey()` borne d\u00e9sormais le param\u00e8tre `p2c` (constante `DEFAULT_MAX_COUNT = 1_000_000`, configurable via le constructeur) avant tout appel \u00e0 `hash_pbkdf2()`, emp\u00eachant l\u0027amplification CPU (DoS).\n\n**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (diff\u00e9rentiel nul vs `3.4.x`), aucun commentaire ajout\u00e9 dans le code source. Apr\u00e8s merge, cascade pr\u00e9vue `3.4.x \u2192 4.0.x \u2192 4.1.x`.",
  "id": "GHSA-3prj-6hqw-cm82",
  "modified": "2026-07-15T21:51:04Z",
  "published": "2026-06-18T21:09:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/web-token/jwt-framework/security/advisories/GHSA-3prj-6hqw-cm82"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/web-token/jwt-library/GHSA-3prj-6hqw-cm82.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/web-token/jwt-framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/web-token/jwt-framework/releases/tag/3.4.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/web-token/jwt-framework/releases/tag/4.0.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/web-token/jwt-framework/releases/tag/4.1.7"
    }
  ],
  "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": "PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service"
}

GHSA-3PWH-5MMC-MWRX

Vulnerability from github – Published: 2018-07-24 20:06 – Updated: 2020-08-31 18:19
VLAI
Summary
Denial of Service in nes
Details

Affected versions of nes are vulnerable to denial of service when given an invalid cookie header, and websocket authentication is set to cookie. Submitting an invalid cookie on the websocket upgrade request will cause the node process to throw and exit.

Recommendation

Update to version 6.4.1 or later.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.4.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nes"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-16025"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:55:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Affected versions of `nes` are vulnerable to denial of service when given an invalid `cookie` header, and websocket authentication is set to `cookie`. Submitting an invalid cookie on the websocket upgrade request will cause the node process to throw and exit.\n\n\n## Recommendation\n\nUpdate to version 6.4.1 or later.",
  "id": "GHSA-3pwh-5mmc-mwrx",
  "modified": "2020-08-31T18:19:35Z",
  "published": "2018-07-24T20:06:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16025"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/nes/issues/171"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/nes/commit/249ba1755ed6977fbc208463c87364bf884ad655"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-3pwh-5mmc-mwrx"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/331"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Denial of Service in nes"
}

GHSA-3PX7-JM2P-6H2C

Vulnerability from github – Published: 2023-10-24 02:00 – Updated: 2025-11-19 14:25
VLAI
Summary
encoded_id-rails potential DOS vulnerability due to URIs with extremely long encoded IDs
Details

Impact

The length of URIs and the various parts (eg path segments, query parameters) is usually limited by the webserver processing the incoming request. In the case of Puma the defaults are :

  • path segment length: 8192
  • Max URI length: 1024 * 12
  • Max query length: 1024 * 10

See https://github.com/puma/puma/blob/master/docs/compile_options.md

If too long Puma raises:

Puma caught this error: HTTP element REQUEST_PATH is longer than the (8192) allowed length (was 12503) (Puma::HttpParserError)

However due to the performance of hashids extremely long encoded IDs will consume a large amount of CPU and allocate a huge number of intermediate objects.

For example:

curl -vvv https://localhost.ssl:3000//dos?id=abcd-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

This causes the application to spend a huge amount of time decoding the ID and the allocation of > 200MB of objects.

Patches

Upgrade to 1.0.0.beta2

This introduces a new option to limit the length of IDs that can be decoded. A future release will also improve the performance and hugely reduce allocations in the underlying hashids implementation.

References

Are there any links users can visit to find out more?

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "encoded_id-rails"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0.beta2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-0241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-24T02:00:50Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe length of URIs and the various parts (eg path segments, query parameters) is usually limited by the webserver processing the incoming request. In the case of Puma the defaults are :\n\n- path segment length: 8192\n- Max URI length: 1024 * 12\n- Max query length: 1024 * 10\n\nSee https://github.com/puma/puma/blob/master/docs/compile_options.md\n\nIf too long Puma raises:\n\u003e Puma caught this error: HTTP element REQUEST_PATH is longer than the (8192) allowed length (was 12503) (Puma::HttpParserError)\n\nHowever due to the performance of `hashids` extremely long encoded IDs will consume a large amount of CPU and allocate a huge number of intermediate objects.\n\nFor example:\n\n```\ncurl -vvv https://localhost.ssl:3000//dos?id=abcd-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n```\n\nThis causes the application to spend a huge amount of time decoding the ID and the allocation of \u003e 200MB of objects.\n\n### Patches\n\nUpgrade to `1.0.0.beta2`\n\nThis introduces a new option to limit the length of IDs that can be decoded. A future release will also improve the performance and  hugely reduce allocations in the underlying hashids implementation.\n\n### References\n_Are there any links users can visit to find out more?_",
  "id": "GHSA-3px7-jm2p-6h2c",
  "modified": "2025-11-19T14:25:55Z",
  "published": "2023-10-24T02:00:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stevegeek/encoded_id-rails/security/advisories/GHSA-3px7-jm2p-6h2c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stevegeek/encoded_id-rails/commit/afa495a77b8a21ad582611f9cdc2081dc4018b91"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/encoded_id-rails/CVE-2024-0241.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stevegeek/encoded_id-rails"
    }
  ],
  "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": "encoded_id-rails potential DOS vulnerability due to URIs with extremely long encoded IDs"
}

GHSA-3PXH-H8HW-MJ8W

Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2023-08-28 12:50
VLAI
Summary
Rack rubygems receiving excessively long lines triggers out-of-memory error
Details

multipart/parser.rb in Rack 1.3.x before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to cause a denial of service (memory consumption and out-of-memory error) via a long string in a Multipart HTTP packet.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-0183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:55:49Z",
    "nvd_published_at": "2013-03-01T05:40:00Z",
    "severity": "MODERATE"
  },
  "details": "multipart/parser.rb in Rack 1.3.x before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to cause a denial of service (memory consumption and out-of-memory error) via a long string in a Multipart HTTP packet.",
  "id": "GHSA-3pxh-h8hw-mj8w",
  "modified": "2023-08-28T12:50:30Z",
  "published": "2017-10-24T18:33:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-0183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/548b9af2dc0059f4c0c19728624448d84de450ff"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/f95113402b7239f225282806673e1b6424522b18"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2013:0544"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2013-0183"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=895282"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2013-0183.yml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/rack-devel/-MWPHDeGWtI"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/rack-devel/7ZKPNAjgRSs"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#%21topic/rack-devel/-MWPHDeGWtI"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#%21topic/rack-devel/7ZKPNAjgRSs"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2013-03/msg00048.html"
    },
    {
      "type": "WEB",
      "url": "http://rack.github.com"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0544.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0548.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2013/dsa-2783"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Rack rubygems receiving excessively long lines triggers out-of-memory error"
}

GHSA-3Q32-6VJH-9HFQ

Vulnerability from github – Published: 2022-09-07 00:01 – Updated: 2022-09-13 00:00
VLAI
Details

Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23687"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-06T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple vulnerabilities exist in the processing of packet data by the LLDP service of AOS-CX. Successful exploitation of these vulnerabilities may allow an attacker to impact the availability of the AOS-CX LLDP service and/or the management plane of the switch in ArubaOS-CX Switches version(s): AOS-CX 10.09.xxxx: 10.09.1010 and below, AOS-CX 10.08.xxxx: 10.08.1050 and below, AOS-CX 10.06.xxxx: 10.06.0190 and below. Aruba has released upgrades for ArubaOS-CX Switch Devices that address these security vulnerabilities.",
  "id": "GHSA-3q32-6vjh-9hfq",
  "modified": "2022-09-13T00:00:39Z",
  "published": "2022-09-07T00:01:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23687"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-012.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3Q6G-VF58-7M4G

Vulnerability from github – Published: 2021-09-08 15:41 – Updated: 2024-09-20 17:57
VLAI
Summary
Regular Expression Denial of Service in flask-restx
Details

Flask RESTX contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service) in email_regex.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "flask-restx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32838"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-07T14:24:52Z",
    "nvd_published_at": "2021-09-20T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Flask RESTX contains a regular expression that is vulnerable to [ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (Regular Expression Denial of Service) in `email_regex`.\n",
  "id": "GHSA-3q6g-vf58-7m4g",
  "modified": "2024-09-20T17:57:56Z",
  "published": "2021-09-08T15:41:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-restx/flask-restx/security/advisories/GHSA-3q6g-vf58-7m4g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32838"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-restx/flask-restx/issues/372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-restx/flask-restx/commit/bab31e085f355dd73858fd3715f7ed71849656da"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-3q6g-vf58-7m4g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/flask-restx/PYSEC-2021-325.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-restx/flask-restx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-restx/flask-restx/blob/fd99fe11a88531f5f3441a278f7020589f9d2cc0/flask_restx/inputs.py#L51"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5UCTFVDU3677B5OBGK4EF5NMUPJLL6SQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QUD6SWZLX52AAZUHDETJ2CDMQGEPGFL3"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/flask-restx"
    }
  ],
  "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": "Regular Expression Denial of Service in flask-restx"
}

GHSA-3Q6R-GHXH-24G9

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

A denial of service vulnerability exists in the cgiserver.cgi session creation functionality of reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to prevent users from logging in. An attacker can send an HTTP request to trigger this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-40406"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-28T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A denial of service vulnerability exists in the cgiserver.cgi session creation functionality of reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to prevent users from logging in. An attacker can send an HTTP request to trigger this vulnerability.",
  "id": "GHSA-3q6r-ghxh-24g9",
  "modified": "2022-04-20T00:01:46Z",
  "published": "2022-01-29T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40406"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1423"
    }
  ],
  "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-3Q6V-R5MR-HXV8

Vulnerability from github – Published: 2026-09-30 15:36 – Updated: 2026-09-30 15:36
VLAI
Summary
league/commonmark: Quadratic-time denial of service in the GitHub Flavored Markdown Table extension block-start scan
Details

Summary

league/commonmark's GitHub Flavored Markdown Table extension registers TableStartParser as a block-start parser. While a paragraph is the active block, the core block parser calls TableStartParser::tryStart() on every non-blank line. Its first action fetches the entire growing paragraph buffer via getParagraphContent() and runs strpos($paragraph, '|') across all of it. For a paragraph of M pipe-free lines, line k rescans about k lines of buffer, so total work is 1+2+...+M, which is O(M^2). An unauthenticated user who submits a single large paragraph of pipe-free lines that do not begin with a letter (see Attack Chain) to any service that converts untrusted Markdown with GithubFlavoredMarkdownConverter (or any environment that enables TableExtension) drives seconds to tens of seconds of single-core CPU that grows quadratically with body size, enough to exhaust worker processes and deny service.

Root Cause

The GFM table detector performs a per-line "quick check" against the whole accumulated paragraph rather than only the portion that could form a table header. A paragraph never closes while non-blank lines keep arriving, so its buffer grows without bound, and the quick check rescans the entire buffer on each line. Only the paragraph's last line can ever be a table header (it is extracted separately via strrpos/substr), so scanning the full multi-line buffer for a pipe on every line is unnecessary work and creates quadratic time complexity. There is no input-size cap and the default nesting limit is not reached, so nothing bounds the scan.

Affected function: League\CommonMark\Extension\Table\TableStartParser::tryStart
Location: src/Extension/Table/TableStartParser.php:35-38
  $paragraph = $parserState->getParagraphContent();       // returns the FULL growing buffer
  if ($paragraph === null || \strpos($paragraph, '|') === false) {
      return BlockStart::none();                           // strpos scans whole buffer each line
  }
Buffer growth: src/Reference/ReferenceParser.php:89-95 ($this->paragraph .= "\n"; $this->paragraph .= $line;)
Per-line dispatch: src/Parser/MarkdownParser.php:135-147 and :224-236

Impact

An unauthenticated, remote attacker with no user interaction can cause denial of service against any application that renders untrusted Markdown with the GitHub Flavored Markdown converter or any configuration that enables the Table extension (the default GFM bundle enables it). A single request carrying a large paragraph of pipe-free, blank-line-free lines that do not begin with a letter consumes CPU proportional to the square of the input size: measured runs show roughly 4x CPU growth per input doubling. A body of a few megabytes ties up a worker for seconds to tens of seconds; repeated or concurrent requests exhaust all available PHP worker processes, denying service to legitimate users. Impact is limited to availability; there is no confidentiality or integrity impact.

Proof of Concept

Requires PHP with league/commonmark 2.x installed. The harness parses pipe-free paragraphs of increasing size with the real MarkdownParser and the real block-start parsers, comparing a GFM-plus-Table configuration against a core-only configuration to isolate the Table parser's contribution.

  1. Install league/commonmark (2.10.1 or any 2.x release).
  2. Convert a single large paragraph of pipe-free, blank-line-free lines that do not begin with a letter, with GithubFlavoredMarkdownConverter.
  3. Measure wall-clock time as the paragraph size doubles.
<?php
require 'vendor/autoload.php';
use League\CommonMark\GithubFlavoredMarkdownConverter;

$converter = new GithubFlavoredMarkdownConverter();
foreach ([25000, 50000, 100000, 200000] as $lines) {
    $md = str_repeat("12345678\n", $lines); // one paragraph, no blank lines, no '|', lines not starting with a letter
    $t = microtime(true);
    $converter->convert($md);
    printf("%7d lines  %6.3fs\n", $lines, microtime(true) - $t);
}
   lines    input    letter-leading    non-letter-leading
                     ("aaaaaaaa")          ("12345678")
   25000   0.23MB        0.27s               0.75s
   50000   0.45MB        0.50s               2.36s
  100000   0.90MB        1.07s               7.70s
  200000   1.80MB        2.26s              27.81s

Letter-leading input scales linearly (doubles per input doubling) because SkipLinesStartingWithLettersParser aborts before the Table parser is reached. Non-letter-leading input quadruples per doubling (0.75, 2.36, 7.70, 27.81), confirming O(M^2) behavior attributable to the Table start parser.

Attack Chain

  1. Exposure: The attacker submits a Markdown body to any endpoint that converts untrusted Markdown with GithubFlavoredMarkdownConverter, or any environment that adds TableExtension. The default GFM bundle registers the Table extension: GithubFlavoredMarkdownExtension adds TableExtension (src/Extension/GithubFlavoredMarkdownExtension.php:30), which registers TableStartParser (src/Extension/Table/TableExtension.php:56).
  2. Control: The attacker fully controls the Markdown body. The exploit input is one paragraph with no blank lines, no | character, and lines that do not begin with a letter (for example str_repeat("12345678\n", 200000)).
  3. Path: MarkdownParser::parseLine() loops over block-start parsers for every non-blank line while a paragraph is active (src/Parser/MarkdownParser.php:135-147). ParagraphParser::tryContinue() keeps the paragraph open for every non-blank line, so the buffer keeps growing (src/Parser/Block/ParagraphParser.php:46-53), appended line by line in ReferenceParser::parse() (src/Reference/ReferenceParser.php:89-95). Since 2.0.2, the highest-priority SkipLinesStartingWithLettersParser returns BlockStart::abort() for any line whose first non-space character is a letter, short-circuiting findBlockStart() before TableStartParser. When lines begin with a non-letter (e.g. a digit), that parser returns none and every remaining core parser returns null, so control reaches TableStartParser on every line (src/Parser/MarkdownParser.php:224-236).
  4. Guard: There is no input-size cap in MarkdownInput, and max_nesting_level defaults to PHP_INT_MAX, which the depth-1 paragraph never approaches. No guard bounds the whole-buffer scan.
  5. Primitive: TableStartParser::tryStart() runs strpos($paragraph, '|') over the entire buffer returned by getParagraphContent() (src/Extension/Table/TableStartParser.php:35-38). With no pipe present, strpos scans to the end of the buffer on every line.
  6. Result: Cumulative scanning work is O(M^2). A single small request drives disproportionate, quadratically growing CPU, exhausting worker processes and denying service.

Bypass Evidence

No prior fix exists for this code path, so this is not an incomplete-fix or regression case; it is a distinct, previously undisclosed quadratic path. The strongest disproof attempts were made and all failed:

  • Attempt: the observed quadratic is core-parser or PHP string overhead, not the Table parser. Refuted: the only difference between the two measured configurations is TableStartParser; the core-only baseline is linear while the isolated Table contribution quadruples per input doubling.
  • Attempt: strpos short-circuits or the buffer does not actually grow. Refuted by source trace: ReferenceParser::parse() appends every line unconditionally before its state switch, and for pipe-free text strpos finds no | and scans the full buffer each line.
  • Attempt: another parser short-circuits before TableStartParser. Partially correct: since 2.0.2 SkipLinesStartingWithLettersParser aborts block-start scanning for lines beginning with a letter, so letter-leading input (including the original aaaaaaaa PoC) never reaches the Table parser and runs in linear time. Input whose lines begin with a non-letter (e.g. a digit) passes every core parser and reaches TableStartParser on every line, exhibiting the quadratic behavior.
  • Attempt: an input-size or nesting guard neutralizes it. Refuted: there is no size cap and the default nesting limit is never reached.
  • Attempt: this duplicates an existing quadratic-DoS advisory or was already fixed. Refuted: published quadratic advisories address per-line position translation and other distinct mechanisms in other files; git log on src/Extension/Table/TableStartParser.php shows no security fix ever touched this rescan, and the code is present unchanged in the latest release.

Affected Versions

  • Ecosystem: composer
  • Package: league/commonmark
  • Confirmed affected range: >= 2.0.0, <= 2.10.1
  • Latest release checked: 2.10.1 (Packagist, repo.packagist.org/p2/league/commonmark.json)
  • Fix status: not fixed

Note: SkipLinesStartingWithLettersParser was introduced in 2.0.2. On 2.0.0 and 2.0.1 the issue can also be triggered with letter-leading lines. Regardless, the underlying quadratic scan itself is present across the whole >= 2.0.0, <= 2.10.1 range.

The vulnerable rescan is artifact-verified present in tags 2.8.0 and 2.10.1 (the latest published release). The lower bound 2.0.0 is inferred from the 2.x block-parser rewrite that introduced the getParagraphContent()-based architecture this quick check depends on; the checkout contains only tags 2.8.0 through 2.10.1, so the path is not artifact-verified below 2.8.0. No published release removes or bounds the whole-buffer scan.

Suggested Fix

Enforce that the per-line quick check inspects only the paragraph's last line, which is the only line that can form a table header. Compute the last line break with strrpos($paragraph, "\n"), derive the last line, and test strpos($lastLine, '|') instead of scanning the whole buffer. This bounds the per-line check to the length of the last line and removes the quadratic behavior without changing table detection semantics. As an interim mitigation without a code change, operators can cap the size of untrusted Markdown accepted for conversion, or disable the Table extension for untrusted input, which reduces exposure but does not remove the underlying quadratic path.

Reported by zx (GitHub: @manus-pi).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.10.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "league/commonmark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:36:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`league/commonmark`\u0027s GitHub Flavored Markdown Table extension registers `TableStartParser` as a block-start parser. While a paragraph is the active block, the core block parser calls `TableStartParser::tryStart()` on every non-blank line. Its first action fetches the entire growing paragraph buffer via `getParagraphContent()` and runs `strpos($paragraph, \u0027|\u0027)` across all of it. For a paragraph of M pipe-free lines, line k rescans about k lines of buffer, so total work is 1+2+...+M, which is O(M^2). An unauthenticated user who submits a single large paragraph of pipe-free lines that do not begin with a letter (see Attack Chain) to any service that converts untrusted Markdown with `GithubFlavoredMarkdownConverter` (or any environment that enables `TableExtension`) drives seconds to tens of seconds of single-core CPU that grows quadratically with body size, enough to exhaust worker processes and deny service.\n\n## Root Cause\n\nThe GFM table detector performs a per-line \"quick check\" against the whole accumulated paragraph rather than only the portion that could form a table header. A paragraph never closes while non-blank lines keep arriving, so its buffer grows without bound, and the quick check rescans the entire buffer on each line. Only the paragraph\u0027s last line can ever be a table header (it is extracted separately via `strrpos`/`substr`), so scanning the full multi-line buffer for a pipe on every line is unnecessary work and creates quadratic time complexity. There is no input-size cap and the default nesting limit is not reached, so nothing bounds the scan.\n\n```text\nAffected function: League\\CommonMark\\Extension\\Table\\TableStartParser::tryStart\nLocation: src/Extension/Table/TableStartParser.php:35-38\n  $paragraph = $parserState-\u003egetParagraphContent();       // returns the FULL growing buffer\n  if ($paragraph === null || \\strpos($paragraph, \u0027|\u0027) === false) {\n      return BlockStart::none();                           // strpos scans whole buffer each line\n  }\nBuffer growth: src/Reference/ReferenceParser.php:89-95 ($this-\u003eparagraph .= \"\\n\"; $this-\u003eparagraph .= $line;)\nPer-line dispatch: src/Parser/MarkdownParser.php:135-147 and :224-236\n```\n\n## Impact\n\nAn unauthenticated, remote attacker with no user interaction can cause denial of service against any application that renders untrusted Markdown with the GitHub Flavored Markdown converter or any configuration that enables the Table extension (the default GFM bundle enables it). A single request carrying a large paragraph of pipe-free, blank-line-free lines that do not begin with a letter consumes CPU proportional to the square of the input size: measured runs show roughly 4x CPU growth per input doubling. A body of a few megabytes ties up a worker for seconds to tens of seconds; repeated or concurrent requests exhaust all available PHP worker processes, denying service to legitimate users. Impact is limited to availability; there is no confidentiality or integrity impact.\n\n## Proof of Concept\n\n`Requires PHP with league/commonmark 2.x installed. The harness parses pipe-free paragraphs of increasing size with the real MarkdownParser and the real block-start parsers, comparing a GFM-plus-Table configuration against a core-only configuration to isolate the Table parser\u0027s contribution.`\n\n1. Install `league/commonmark` (2.10.1 or any 2.x release).\n2. Convert a single large paragraph of pipe-free, blank-line-free lines that do not begin with a letter, with `GithubFlavoredMarkdownConverter`.\n3. Measure wall-clock time as the paragraph size doubles.\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\nuse League\\CommonMark\\GithubFlavoredMarkdownConverter;\n\n$converter = new GithubFlavoredMarkdownConverter();\nforeach ([25000, 50000, 100000, 200000] as $lines) {\n    $md = str_repeat(\"12345678\\n\", $lines); // one paragraph, no blank lines, no \u0027|\u0027, lines not starting with a letter\n    $t = microtime(true);\n    $converter-\u003econvert($md);\n    printf(\"%7d lines  %6.3fs\\n\", $lines, microtime(true) - $t);\n}\n```\n\n```text\n   lines    input    letter-leading    non-letter-leading\n                     (\"aaaaaaaa\")          (\"12345678\")\n   25000   0.23MB        0.27s               0.75s\n   50000   0.45MB        0.50s               2.36s\n  100000   0.90MB        1.07s               7.70s\n  200000   1.80MB        2.26s              27.81s\n```\n\nLetter-leading input scales linearly (doubles per input doubling) because `SkipLinesStartingWithLettersParser` aborts before the Table parser is reached. Non-letter-leading input quadruples per doubling (0.75, 2.36, 7.70, 27.81), confirming O(M^2) behavior attributable to the Table start parser.\n\n## Attack Chain\n\n1. **Exposure:** The attacker submits a Markdown body to any endpoint that converts untrusted Markdown with `GithubFlavoredMarkdownConverter`, or any environment that adds `TableExtension`. The default GFM bundle registers the Table extension: `GithubFlavoredMarkdownExtension` adds `TableExtension` (src/Extension/GithubFlavoredMarkdownExtension.php:30), which registers `TableStartParser` (src/Extension/Table/TableExtension.php:56).\n2. **Control:** The attacker fully controls the Markdown body. The exploit input is one paragraph with no blank lines, no `|` character, and lines that do not begin with a letter (for example `str_repeat(\"12345678\\n\", 200000)`).\n3. **Path:** `MarkdownParser::parseLine()` loops over block-start parsers for every non-blank line while a paragraph is active (src/Parser/MarkdownParser.php:135-147). `ParagraphParser::tryContinue()` keeps the paragraph open for every non-blank line, so the buffer keeps growing (src/Parser/Block/ParagraphParser.php:46-53), appended line by line in `ReferenceParser::parse()` (src/Reference/ReferenceParser.php:89-95). Since 2.0.2, the highest-priority `SkipLinesStartingWithLettersParser` returns `BlockStart::abort()` for any line whose first non-space character is a letter, short-circuiting `findBlockStart()` before `TableStartParser`. When lines begin with a non-letter (e.g. a digit), that parser returns none and every remaining core parser returns null, so control reaches `TableStartParser` on every line (src/Parser/MarkdownParser.php:224-236).\n5. **Guard:** There is no input-size cap in `MarkdownInput`, and `max_nesting_level` defaults to `PHP_INT_MAX`, which the depth-1 paragraph never approaches. No guard bounds the whole-buffer scan.\n6. **Primitive:** `TableStartParser::tryStart()` runs `strpos($paragraph, \u0027|\u0027)` over the entire buffer returned by `getParagraphContent()` (src/Extension/Table/TableStartParser.php:35-38). With no pipe present, `strpos` scans to the end of the buffer on every line.\n7. **Result:** Cumulative scanning work is O(M^2). A single small request drives disproportionate, quadratically growing CPU, exhausting worker processes and denying service.\n\n## Bypass Evidence\n\nNo prior fix exists for this code path, so this is not an incomplete-fix or regression case; it is a distinct, previously undisclosed quadratic path. The strongest disproof attempts were made and all failed:\n\n- Attempt: the observed quadratic is core-parser or PHP string overhead, not the Table parser. Refuted: the only difference between the two measured configurations is `TableStartParser`; the core-only baseline is linear while the isolated Table contribution quadruples per input doubling.\n- Attempt: `strpos` short-circuits or the buffer does not actually grow. Refuted by source trace: `ReferenceParser::parse()` appends every line unconditionally before its state switch, and for pipe-free text `strpos` finds no `|` and scans the full buffer each line.\n- Attempt: another parser short-circuits before `TableStartParser`. Partially correct: since 2.0.2 `SkipLinesStartingWithLettersParser` aborts block-start scanning for lines beginning with a letter, so letter-leading input (including the original `aaaaaaaa` PoC) never reaches the Table parser and runs in linear time. Input whose lines begin with a non-letter (e.g. a digit) passes every core parser and reaches `TableStartParser` on every line, exhibiting the quadratic behavior.\n- Attempt: an input-size or nesting guard neutralizes it. Refuted: there is no size cap and the default nesting limit is never reached.\n- Attempt: this duplicates an existing quadratic-DoS advisory or was already fixed. Refuted: published quadratic advisories address per-line position translation and other distinct mechanisms in other files; `git log` on `src/Extension/Table/TableStartParser.php` shows no security fix ever touched this rescan, and the code is present unchanged in the latest release.\n\n## Affected Versions\n\n- `Ecosystem: composer`\n- `Package: league/commonmark`\n- `Confirmed affected range: \u003e= 2.0.0, \u003c= 2.10.1`\n- `Latest release checked: 2.10.1 (Packagist, repo.packagist.org/p2/league/commonmark.json)`\n- `Fix status: not fixed`\n\nNote: `SkipLinesStartingWithLettersParser` was introduced in 2.0.2. On 2.0.0 and 2.0.1 the issue can also be triggered with letter-leading lines. Regardless, the underlying quadratic scan itself is present across the whole \u003e= 2.0.0, \u003c= 2.10.1 range.\n\nThe vulnerable rescan is artifact-verified present in tags 2.8.0 and 2.10.1 (the latest published release). The lower bound 2.0.0 is inferred from the 2.x block-parser rewrite that introduced the `getParagraphContent()`-based architecture this quick check depends on; the checkout contains only tags 2.8.0 through 2.10.1, so the path is not artifact-verified below 2.8.0. No published release removes or bounds the whole-buffer scan.\n\n## Suggested Fix\n\nEnforce that the per-line quick check inspects only the paragraph\u0027s last line, which is the only line that can form a table header. Compute the last line break with `strrpos($paragraph, \"\\n\")`, derive the last line, and test `strpos($lastLine, \u0027|\u0027)` instead of scanning the whole buffer. This bounds the per-line check to the length of the last line and removes the quadratic behavior without changing table detection semantics. As an interim mitigation without a code change, operators can cap the size of untrusted Markdown accepted for conversion, or disable the Table extension for untrusted input, which reduces exposure but does not remove the underlying quadratic path.\n\nReported by zx (GitHub: @manus-pi).",
  "id": "GHSA-3q6v-r5mr-hxv8",
  "modified": "2026-09-30T15:36:14Z",
  "published": "2026-09-30T15:36:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/security/advisories/GHSA-3q6v-r5mr-hxv8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/commit/5f63680a5e29dd57f9c6be9743b0e90493d3c2d0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thephpleague/commonmark"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thephpleague/commonmark/releases/tag/2.10.2"
    }
  ],
  "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": "league/commonmark: Quadratic-time denial of service in the GitHub Flavored Markdown Table extension block-start scan"
}

GHSA-3QC2-V3HP-6CV8

Vulnerability from github – Published: 2023-09-14 06:30 – Updated: 2023-10-05 13:29
VLAI
Summary
sidekiq Denial of Service vulnerability
Details

Versions of the package sidekiq before 7.1.3 and 6.5.10 are vulnerable to Denial of Service (DoS) due to insufficient checks in the dashboard-charts.js file. An attacker can exploit this vulnerability by manipulating the localStorage value which will cause excessive polling requests.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "sidekiq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "sidekiq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26141"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-14T19:34:57Z",
    "nvd_published_at": "2023-09-14T05:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Versions of the package sidekiq before 7.1.3 and 6.5.10 are vulnerable to Denial of Service (DoS) due to insufficient checks in the dashboard-charts.js file. An attacker can exploit this vulnerability by manipulating the localStorage value which will cause excessive polling requests.",
  "id": "GHSA-3qc2-v3hp-6cv8",
  "modified": "2023-10-05T13:29:47Z",
  "published": "2023-09-14T06:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sidekiq/sidekiq/commit/62c90d7c5a7d8a378d79909859d87c2e0702bf89"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/keeganparr1/1dffd3c017339b7ed5371ed3d81e6b2a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/sidekiq/CVE-2023-26141.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sidekiq/sidekiq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sidekiq/sidekiq/blob/6-x/Changes.md#6510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sidekiq/sidekiq/blob/6-x/web/assets/javascripts/dashboard.js#L6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sidekiq/sidekiq/blob/6-x/web/assets/javascripts/dashboard.js%23L6"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-RUBY-SIDEKIQ-5885107"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sidekiq Denial of Service vulnerability"
}

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.