Common Weakness Enumeration

CWE-1333

Allowed

Inefficient Regular Expression Complexity

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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-QXMR-QXH6-2CC9

Vulnerability from github – Published: 2021-12-07 22:01 – Updated: 2021-12-08 19:29
VLAI
Summary
ReDos vulnerability on guest checkout email validation
Details

Impact

Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like a.a..

Before the patch, it can be reproduced in the console like this:

irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the type attribute for that field from email to text. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.

Patches

Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

bin/rails solidus:check_orders_with_invalid_email

The above will print information for every affected order if any.

Workarounds

If a prompt upgrade is not an option, please, add the following to config/application.rb:

config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end

References

  • https://en.wikipedia.org/wiki/ReDoS
  • https://snyk.io/blog/redos-and-catastrophic-backtracking/

For more information

If you have any questions or comments about this advisory: * Open an issue or a discussion in Solidus. * Email us at security@solidus.io * Contact the core team on Slack

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-12-07T20:58:37Z",
    "nvd_published_at": "2021-12-07T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nDenial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order\u0027s email was subject to exponential backtracking through a fragment like `a.a.`.\n\nBefore the patch, it can be reproduced in the console like this:\n\n```ruby\nirb(main)\u003e Spree::EmailValidator::EMAIL_REGEXP.match \"a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@\"\nprocessing time: 54.293660s\n=\u003e nil\n```\n\nTo reproduce in the browser, fill in the \"Customer Email\" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the `type` attribute for that field from `email` to `text`. After entering a fake address and pressing the \"Save \u0026 Continue\" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.\n\n\n### Patches\nVersions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.\n\nThere\u0027s an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We\u0027ve added a task to check precisely that:\n\n```bash\nbin/rails solidus:check_orders_with_invalid_email\n```\n\nThe above will print information for every affected order if any.\n\n### Workarounds\n\nIf a prompt upgrade is not an option, please, add the following to `config/application.rb`:\n\n```ruby\nconfig.after_initialize do\n  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)\n  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP\nend\n```\n\n### References\n\n- https://en.wikipedia.org/wiki/ReDoS\n- https://snyk.io/blog/redos-and-catastrophic-backtracking/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.\n* Email us at [security@solidus.io](mailto:security@soliidus.io)\n* Contact the core team on [Slack](http://slack.solidus.io/)\n",
  "id": "GHSA-qxmr-qxh6-2cc9",
  "modified": "2021-12-08T19:29:13Z",
  "published": "2021-12-07T22:01:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-qxmr-qxh6-2cc9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43805"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/commit/6be174c955fad84017ca67589c676526bc5ade71"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/commit/9867153e01e3c3b898cdbcedd7b43375ea922401"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/solidus_core/CVE-2021-43805.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/solidusio/solidus"
    }
  ],
  "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": "ReDos vulnerability on guest checkout email validation"
}

GHSA-R5Q6-3GGJ-5G3C

Vulnerability from github – Published: 2024-12-04 12:31 – Updated: 2024-12-04 12:31
VLAI
Details

In JetBrains YouTrack before 2024.3.52635 potential ReDoS was possible due to vulnerable RegExp in Ruby syntax detector

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-54157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T12:15:20Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains YouTrack before 2024.3.52635 potential ReDoS was possible due to vulnerable RegExp in Ruby syntax detector",
  "id": "GHSA-r5q6-3ggj-5g3c",
  "modified": "2024-12-04T12:31:45Z",
  "published": "2024-12-04T12:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54157"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R67W-F99W-MGXJ

Vulnerability from github – Published: 2024-01-21 18:30 – Updated: 2024-01-22 21:29
VLAI
Summary
ReDoS in Embedchain
Details

The JSON loader in Embedchain before 0.1.57 allows a ReDoS (regular expression denial of service) via a long string to json.py.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "embedchain"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.57"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-23732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-22T21:29:14Z",
    "nvd_published_at": "2024-01-21T17:15:44Z",
    "severity": "MODERATE"
  },
  "details": "The JSON loader in Embedchain before 0.1.57 allows a ReDoS (regular expression denial of service) via a long string to json.py.",
  "id": "GHSA-r67w-f99w-mgxj",
  "modified": "2024-01-22T21:29:14Z",
  "published": "2024-01-21T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23732"
    },
    {
      "type": "WEB",
      "url": "https://github.com/embedchain/embedchain/pull/1122"
    },
    {
      "type": "WEB",
      "url": "https://github.com/embedchain/embedchain/compare/0.1.56...0.1.57"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/embedchain/PYSEC-2024-8.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "ReDoS in Embedchain"
}

GHSA-R6CH-MQF9-QC9W

Vulnerability from github – Published: 2023-02-16 20:46 – Updated: 2023-02-16 20:46
VLAI
Summary
Regular Expression Denial of Service in Headers
Details

Impact

The Headers.set() and Headers.append() methods are vulnerable to Regular Expression Denial of Service (ReDoS) attacks when untrusted values are passed into the functions. This is due to the inefficient regular expression used to normalize the values in the headerValueNormalize() utility function.

Patches

This vulnerability was patched in v5.19.1.

Workarounds

There is no workaround. Please update to an unaffected version.

References

  • https://hackerone.com/bugs?report_id=1784449

Credits

Carter Snook reported this vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.19.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-24807"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-16T20:46:10Z",
    "nvd_published_at": "2023-02-16T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe `Headers.set()` and `Headers.append()` methods are vulnerable to Regular Expression Denial of Service (ReDoS) attacks when untrusted values are passed into the functions. This is due to the inefficient regular expression used to normalize the values in the `headerValueNormalize()` utility function.\n\n### Patches\n\nThis vulnerability was patched in v5.19.1.\n\n### Workarounds\nThere is no workaround. Please update to an unaffected version.\n\n### References\n\n* https://hackerone.com/bugs?report_id=1784449\n\n### Credits\n\nCarter Snook reported this vulnerability.\n",
  "id": "GHSA-r6ch-mqf9-qc9w",
  "modified": "2023-02-16T20:46:10Z",
  "published": "2023-02-16T20:46:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-r6ch-mqf9-qc9w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24807"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/commit/f2324e549943f0b0937b09fb1c0c16cc7c93abdf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/releases/tag/v5.19.1"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/bugs?report_id=1784449"
    }
  ],
  "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": "Regular Expression Denial of Service in Headers"
}

GHSA-R6H4-MM7H-8PMQ

Vulnerability from github – Published: 2025-12-16 20:46 – Updated: 2025-12-16 20:46
VLAI
Summary
PyMdown Extensions has a ReDOS bug in its Figure Capture extension
Details

Impact

This issue describes a ReDOS bug found within the figure caption extension (pymdownx.blocks.caption ).

In systems that take unchecked user content, this could cause long hangs when processing the data if a malicious payload was crafted.

Patches

This issue is patched in Release 10.16.1.

Workarounds

Some possible workarounds

If users are concerned about this vulnerability and process unknown user content without timeouts or other safeguards in place to prevent really large, malicious content being aimed at systems, the use of pymdownx.blocks.caption could be avoided until the library is updated to 10.16.1+.

References

The original issue https://github.com/facelessuser/pymdown-extensions/issues/2716.

Description

The original issue came through PyMdown Extensions' normal issue tracker instead of the typical security flow: https://github.com/facelessuser/pymdown-extensions/issues/2716. Because this came through the normal issue flow, it was handled as a normal issue. In the future, PyMdown Extensions will ensure such issues, even if prematurely made public through the normal issue flow, are redirected through the typical security process.

The regular expression pattern in question is as follows:

RE_FIG_NUM = re.compile(r'^(\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)')

The POC was provided by @ShangzhiXu

import re
import time

regex_pattern = re.compile(r'^(\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)')

for i in range(50, 500, 50):
    long_string = '1' * i + 'a'
    start_time = time.time()
    match = re.match(regex_pattern, long_string)
    end_time = time.time()
    print(f"long_string execution time: {end_time - start_time:.6f} s")

The issue with the above pattern is that . was used, which accepts any character when we meant to use \.. The fix was to update the pattern to:

RE_FIG_NUM = re.compile(r'^(\^)?([1-9][0-9]*(?:\.[1-9][0-9]*)*)(?= |$)')

Relevant PR with fix: https://github.com/facelessuser/pymdown-extensions/pull/2717

Version(s) & System Info

  • Operating System: Any
  • Python Version: Any
Severity
2.7 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pymdown-extensions"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.16.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68142"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-16T20:46:05Z",
    "nvd_published_at": "2025-12-16T18:16:16Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nThis issue describes a ReDOS bug found within the figure caption extension (`pymdownx.blocks.caption` ).\n\nIn systems that take unchecked user content, this could cause long hangs when processing the data if a malicious payload was crafted.\n\n### Patches\n\nThis issue is patched in Release [10.16.1](https://pypi.org/project/pymdown-extensions/10.16.1/).\n\n### Workarounds\n\nSome possible workarounds\n\nIf users are concerned about this vulnerability and process unknown user content without timeouts or other safeguards in place to prevent really large, malicious content being aimed at systems, the use of `pymdownx.blocks.caption` could be avoided until the library is updated to 10.16.1+.\n\n### References\n\nThe original issue https://github.com/facelessuser/pymdown-extensions/issues/2716.\n\n### Description\n\nThe original issue came through PyMdown Extensions\u0027 normal issue tracker instead of the typical security flow: https://github.com/facelessuser/pymdown-extensions/issues/2716. Because this came through the normal issue flow, it was handled as a normal issue. In the future, PyMdown Extensions will ensure such issues, even if prematurely made public through the normal issue flow, are redirected through the typical security process.\n\nThe regular expression pattern in question is as follows:\n\n```py\nRE_FIG_NUM = re.compile(r\u0027^(\\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)\u0027)\n```\n\nThe POC was provided by @ShangzhiXu\n\n```py\nimport re\nimport time\n\nregex_pattern = re.compile(r\u0027^(\\^)?([1-9][0-9]*(?:.[1-9][0-9]*)*)(?= |$)\u0027)\n\nfor i in range(50, 500, 50):\n    long_string = \u00271\u0027 * i + \u0027a\u0027\n    start_time = time.time()\n    match = re.match(regex_pattern, long_string)\n    end_time = time.time()\n    print(f\"long_string execution time: {end_time - start_time:.6f} s\")\n```\n\nThe issue with the above pattern is that `.` was used, which accepts any character when we meant to use `\\.`. The fix was to update the pattern to:\n\n```py\nRE_FIG_NUM = re.compile(r\u0027^(\\^)?([1-9][0-9]*(?:\\.[1-9][0-9]*)*)(?= |$)\u0027)\n```\n\nRelevant PR with fix: https://github.com/facelessuser/pymdown-extensions/pull/2717\n\n### Version(s) \u0026 System Info\n\n- Operating System: Any\n- Python Version: Any",
  "id": "GHSA-r6h4-mm7h-8pmq",
  "modified": "2025-12-16T20:46:05Z",
  "published": "2025-12-16T20:46:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/facelessuser/pymdown-extensions/security/advisories/GHSA-r6h4-mm7h-8pmq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68142"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facelessuser/pymdown-extensions/commit/b50d15a56850ed1408a284bba81cc019c6bd72e8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/facelessuser/pymdown-extensions"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/pymdown-extensions/10.16.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PyMdown Extensions has a ReDOS bug in its Figure Capture extension"
}

GHSA-R7G9-XPMJ-5FCQ

Vulnerability from github – Published: 2026-05-27 18:08 – Updated: 2026-07-09 21:06
VLAI
Summary
LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex
Details

Summary

The built-in strip_html filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many <script, <style, or <!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('<script'.repeat(50000)) stalls the process for ~10 seconds; cost grows quadratically with input size. The default memoryLimit: Infinity does not bound regex CPU, and even when configured strip_html only charges str.length to the limit — the regex itself runs unbounded.

Details

The vulnerable filter is at src/filters/html.ts:45-49:

export function strip_html (this: FilterImpl, v: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)
  return str.replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<.*?>|<!--[\s\S]*?-->/g, '')
}

The regex contains four lazy patterns: 1. <script[\s\S]*?<\/script> 2. <style[\s\S]*?<\/style> 3. <.*?> 4. <!--[\s\S]*?-->

For an input like '<script'.repeat(N), the engine encounters N starting < positions. At each one it must lazily expand [\s\S]*? (and .*?) all the way to end-of-input searching for a closer that never appears, then fail and backtrack. Because each of the O(N) starts performs O(N) lazy-expansion work, total work is O(N²).

Reachability: 1. strip_html is a default-registered filter (exported from src/filters/html.ts, wired up via src/filters/index.ts), invocable from any template via {{ x | strip_html }}. 2. The filter calls String.prototype.replace with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout. 3. The default memoryLimit is Infinity (src/liquid-options.ts:198); the filter only charges str.length against memory (line 47), which does not bound CPU work for regex backtracking.

This is distinct from GHSA-45rm-2893-5f49 (prototype property leak, CWE-200) and from any prior replace/strip_html issues — the mechanism here is regex backtracking CPU consumption on a different filter.

PoC

Empirical scaling confirmed against a freshly built liquidjs@10.25.7 bundle on Node 22 / Linux:

node -e "
const { Liquid } = require('liquidjs');
const e = new Liquid();
(async () => {
  for (const n of [1000, 2000, 4000, 8000, 16000]) {
    const payload = '<script'.repeat(n);
    const t0 = Date.now();
    await e.parseAndRender('{{ x | strip_html }}', { x: payload });
    console.log('n=' + n + ' inputLen=' + payload.length + ' ms=' + (Date.now() - t0));
  }
})();
"

Verified output:

n=1000  inputLen=7000   ms=5
n=2000  inputLen=14000  ms=12     (2.4x for 2x size)
n=4000  inputLen=28000  ms=46     (3.8x for 2x size)
n=8000  inputLen=56000  ms=187    (4.0x for 2x size)
n=16000 inputLen=112000 ms=737    (3.9x for 2x size)

A larger payload extrapolates straightforwardly:

node -e "
const { Liquid } = require('liquidjs');
const e = new Liquid();
(async () => {
  const payload = '<script'.repeat(50000);  // 350 KB
  const t0 = Date.now();
  await e.parseAndRender('{{ x | strip_html }}', { x: payload });
  console.log('elapsed ms:', Date.now() - t0);
})();
"
# elapsed ms: ~10000+ (Node single-threaded event loop fully blocked)

The same pathology applies to <style and <!-- openers.

Impact

  • Single-request DoS: A 350 KB request body stalls the Node.js event loop for ~10 seconds; 700 KB takes ~40 s; 1.4 MB takes ~160 s. All other requests on the process queue behind the regex.
  • Trivial amplification: Quadratic scaling means small attacker bandwidth produces large server CPU consumption. A handful of concurrent requests fully saturates the worker.
  • No authentication required: The typical use case for strip_html is sanitizing untrusted input (comments, posts, profile bios, product descriptions). Any endpoint that renders user content through strip_html is exposed.
  • memoryLimit doesn't help: Even applications that opt into memoryLimit are not protected, because (a) the regex CPU runs to completion before any output is produced, and (b) only str.length is charged, not the cost of the regex traversal.

Recommended Fix

Replace the backtracking regex with an atomic / non-overlapping pattern, and/or perform a single linear pass.

Option 1 — anchor each alternative so lazy expansion fails fast on chunked content (no [\s\S]*? over the full tail):

return str.replace(
  /<script\b[^<]*(?:<(?!\/script>)[^<]*)*<\/script>|<style\b[^<]*(?:<(?!\/style>)[^<]*)*<\/style>|<!--[^-]*(?:-(?!->)[^-]*)*-->|<[^>]*>/g,
  ''
)

This unrolls each lazy quantifier so each < is visited at most a constant number of times overall — linear total work.

Option 2 — single-pass tokenizer in plain code; iterate over the string once, tracking whether you are inside <script>, <style>, comment, or generic tag, and emit nothing for those ranges.

Either fix should be combined with charging the regex output cost honestly to memoryLimit and (defensively) capping input length up front:

export function strip_html (this: FilterImpl, v: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)
  // ... linear-time strip implementation here
}
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T18:08:19Z",
    "nvd_published_at": "2026-06-17T23:17:04Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `\u003cscript`, `\u003cstyle`, or `\u003c!--` opener tokens without matching closers, the V8 regex engine performs O(N\u00b2) backtracking, blocking the Node.js event loop. A single ~350 KB request (`\u0027\u003cscript\u0027.repeat(50000)`) stalls the process for ~10 seconds; cost grows quadratically with input size. The default `memoryLimit: Infinity` does not bound regex CPU, and even when configured `strip_html` only charges `str.length` to the limit \u2014 the regex itself runs unbounded.\n\n## Details\n\nThe vulnerable filter is at `src/filters/html.ts:45-49`:\n\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  return str.replace(/\u003cscript[\\s\\S]*?\u003c\\/script\u003e|\u003cstyle[\\s\\S]*?\u003c\\/style\u003e|\u003c.*?\u003e|\u003c!--[\\s\\S]*?--\u003e/g, \u0027\u0027)\n}\n```\n\nThe regex contains four lazy patterns:\n1. `\u003cscript[\\s\\S]*?\u003c\\/script\u003e`\n2. `\u003cstyle[\\s\\S]*?\u003c\\/style\u003e`\n3. `\u003c.*?\u003e`\n4. `\u003c!--[\\s\\S]*?--\u003e`\n\nFor an input like `\u0027\u003cscript\u0027.repeat(N)`, the engine encounters N starting `\u003c` positions. At each one it must lazily expand `[\\s\\S]*?` (and `.*?`) all the way to end-of-input searching for a closer that never appears, then fail and backtrack. Because each of the O(N) starts performs O(N) lazy-expansion work, total work is O(N\u00b2).\n\nReachability:\n1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/filters/index.ts`), invocable from any template via `{{ x | strip_html }}`.\n2. The filter calls `String.prototype.replace` with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout.\n3. The default `memoryLimit` is `Infinity` (`src/liquid-options.ts:198`); the filter only charges `str.length` against memory (line 47), which does not bound CPU work for regex backtracking.\n\nThis is distinct from `GHSA-45rm-2893-5f49` (prototype property leak, CWE-200) and from any prior `replace`/`strip_html` issues \u2014 the mechanism here is regex backtracking CPU consumption on a different filter.\n\n## PoC\n\nEmpirical scaling confirmed against a freshly built `liquidjs@10.25.7` bundle on Node 22 / Linux:\n\n```bash\nnode -e \"\nconst { Liquid } = require(\u0027liquidjs\u0027);\nconst e = new Liquid();\n(async () =\u003e {\n  for (const n of [1000, 2000, 4000, 8000, 16000]) {\n    const payload = \u0027\u003cscript\u0027.repeat(n);\n    const t0 = Date.now();\n    await e.parseAndRender(\u0027{{ x | strip_html }}\u0027, { x: payload });\n    console.log(\u0027n=\u0027 + n + \u0027 inputLen=\u0027 + payload.length + \u0027 ms=\u0027 + (Date.now() - t0));\n  }\n})();\n\"\n```\n\nVerified output:\n```\nn=1000  inputLen=7000   ms=5\nn=2000  inputLen=14000  ms=12     (2.4x for 2x size)\nn=4000  inputLen=28000  ms=46     (3.8x for 2x size)\nn=8000  inputLen=56000  ms=187    (4.0x for 2x size)\nn=16000 inputLen=112000 ms=737    (3.9x for 2x size)\n```\n\nA larger payload extrapolates straightforwardly:\n```bash\nnode -e \"\nconst { Liquid } = require(\u0027liquidjs\u0027);\nconst e = new Liquid();\n(async () =\u003e {\n  const payload = \u0027\u003cscript\u0027.repeat(50000);  // 350 KB\n  const t0 = Date.now();\n  await e.parseAndRender(\u0027{{ x | strip_html }}\u0027, { x: payload });\n  console.log(\u0027elapsed ms:\u0027, Date.now() - t0);\n})();\n\"\n# elapsed ms: ~10000+ (Node single-threaded event loop fully blocked)\n```\n\nThe same pathology applies to `\u003cstyle` and `\u003c!--` openers.\n\n## Impact\n\n- **Single-request DoS:** A 350 KB request body stalls the Node.js event loop for ~10 seconds; 700 KB takes ~40 s; 1.4 MB takes ~160 s. All other requests on the process queue behind the regex.\n- **Trivial amplification:** Quadratic scaling means small attacker bandwidth produces large server CPU consumption. A handful of concurrent requests fully saturates the worker.\n- **No authentication required:** The typical use case for `strip_html` is sanitizing untrusted input (comments, posts, profile bios, product descriptions). Any endpoint that renders user content through `strip_html` is exposed.\n- **memoryLimit doesn\u0027t help:** Even applications that opt into `memoryLimit` are not protected, because (a) the regex CPU runs to completion before any output is produced, and (b) only `str.length` is charged, not the cost of the regex traversal.\n\n## Recommended Fix\n\nReplace the backtracking regex with an atomic / non-overlapping pattern, and/or perform a single linear pass.\n\nOption 1 \u2014 anchor each alternative so lazy expansion fails fast on chunked content (no `[\\s\\S]*?` over the full tail):\n```ts\nreturn str.replace(\n  /\u003cscript\\b[^\u003c]*(?:\u003c(?!\\/script\u003e)[^\u003c]*)*\u003c\\/script\u003e|\u003cstyle\\b[^\u003c]*(?:\u003c(?!\\/style\u003e)[^\u003c]*)*\u003c\\/style\u003e|\u003c!--[^-]*(?:-(?!-\u003e)[^-]*)*--\u003e|\u003c[^\u003e]*\u003e/g,\n  \u0027\u0027\n)\n```\nThis unrolls each lazy quantifier so each `\u003c` is visited at most a constant number of times overall \u2014 linear total work.\n\nOption 2 \u2014 single-pass tokenizer in plain code; iterate over the string once, tracking whether you are inside `\u003cscript\u003e`, `\u003cstyle\u003e`, comment, or generic tag, and emit nothing for those ranges.\n\nEither fix should be combined with charging the regex output cost honestly to `memoryLimit` and (defensively) capping input length up front:\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  // ... linear-time strip implementation here\n}\n```",
  "id": "GHSA-r7g9-xpmj-5fcq",
  "modified": "2026-07-09T21:06:36Z",
  "published": "2026-05-27T18:08:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-r7g9-xpmj-5fcq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/commit/3616a744b9abeb425c217b340a2397d46176afb8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.26.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex"
}

GHSA-R836-HH6V-RG5G

Vulnerability from github – Published: 2024-08-07 15:30 – Updated: 2025-11-04 19:51
VLAI
Summary
Django vulnerable to denial-of-service attack
Details

An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize and urlizetrunc template filters, and the AdminURLFieldWidget widget, are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0"
            },
            {
              "fixed": "5.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "Django"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2"
            },
            {
              "fixed": "4.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41991"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-130",
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-07T19:03:05Z",
    "nvd_published_at": "2024-08-07T15:15:56Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize and urlizetrunc template filters, and the AdminURLFieldWidget widget, are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.",
  "id": "GHSA-r836-hh6v-rg5g",
  "modified": "2025-11-04T19:51:04Z",
  "published": "2024-08-07T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41991"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/523da8771bce321023f490f70d71a9e973ddc927"
    },
    {
      "type": "WEB",
      "url": "https://github.com/django/django/commit/efea1ef7e2190e3f77ca0651b5458297bc0f6a9f"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/dev/releases/security"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/django/django"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-69.yaml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#%21forum/django-announce"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240905-0007"
    },
    {
      "type": "WEB",
      "url": "https://www.djangoproject.com/weblog/2024/aug/06/security-releases"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Django vulnerable to denial-of-service attack"
}

GHSA-R8WQ-QRXC-HMCM

Vulnerability from github – Published: 2021-11-29 17:58 – Updated: 2021-11-26 18:26
VLAI
Summary
ReDoS in LDAP schema parser
Details

https://github.com/python-ldap/python-ldap/issues/424

Impact

The LDAP schema parser of python-ldap 3.3.1 and earlier are vulnerable to a regular expression denial-of-service attack. The issue affects clients that use ldap.schema package to parse LDAP schema definitions from an untrusted source.

Patches

The upcoming release of python-ldap 3.4.0 will contain a workaround to prevent ReDoS attacks. The schema parser refuses schema definitions with an excessive amount of backslashes.

Workarounds

As a workaround, users can check input for excessive amount of backslashes in schemas. More than a dozen backslashes per line are atypical.

References

CWE-1333

For more information

If you have any questions or comments about this advisory: * Open an issue in python-ldap tracker

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-ldap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-26T18:26:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "https://github.com/python-ldap/python-ldap/issues/424\n\n### Impact\nThe LDAP schema parser of python-ldap 3.3.1 and earlier are vulnerable to a regular expression denial-of-service attack. The issue affects clients that use ``ldap.schema`` package to parse LDAP schema definitions from an untrusted source.\n\n### Patches\nThe upcoming release of python-ldap 3.4.0 will contain a workaround to prevent ReDoS attacks. The schema parser refuses schema definitions with an excessive amount of backslashes.\n\n### Workarounds\nAs a workaround, users can check input for excessive amount of backslashes in schemas. More than a dozen backslashes per line are atypical.\n\n### References\n[CWE-1333](https://cwe.mitre.org/data/definitions/1333.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [python-ldap](https://github.com/python-ldap/python-ldap) tracker\n",
  "id": "GHSA-r8wq-qrxc-hmcm",
  "modified": "2021-11-26T18:26:27Z",
  "published": "2021-11-29T17:58:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-ldap/python-ldap/security/advisories/GHSA-r8wq-qrxc-hmcm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-ldap/python-ldap/issues/424"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-ldap/python-ldap"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ReDoS in LDAP schema parser"
}

GHSA-R9HX-VWMV-Q579

Vulnerability from github – Published: 2022-12-23 00:30 – Updated: 2025-11-04 19:37
VLAI
Summary
pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)
Details

Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in package_index. This has been patched in version 65.5.1.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "setuptools"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "65.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-40897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-27T14:51:05Z",
    "nvd_published_at": "2022-12-23T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "Python Packaging Authority (PyPA)\u0027s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in `package_index`. This has been patched in version 65.5.1.",
  "id": "GHSA-r9hx-vwmv-q579",
  "modified": "2025-11-04T19:37:00Z",
  "published": "2022-12-23T00:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40897"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/setuptools/issues/3659"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/setuptools/commit/43a9c9bfa6aa626ec2a22540bea28d2ca77964be"
    },
    {
      "type": "WEB",
      "url": "https://setuptools.pypa.io/en/latest"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0006"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230214-0001"
    },
    {
      "type": "WEB",
      "url": "https://pyup.io/vulnerabilities/CVE-2022-40897/52495"
    },
    {
      "type": "WEB",
      "url": "https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YNA2BAH2ACBZ4TVJZKFLCR7L23BG5C3H"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ADES3NLOE5QJKBLGNZNI2RGVOSQXA37R"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YNA2BAH2ACBZ4TVJZKFLCR7L23BG5C3H"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ADES3NLOE5QJKBLGNZNI2RGVOSQXA37R"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00018.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/setuptools/compare/v65.5.0...v65.5.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/setuptools/blob/fe8a98e696241487ba6ac9f91faa38ade939ec5d/setuptools/package_index.py#L200"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pypa/setuptools"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/setuptools/PYSEC-2022-43012.yaml"
    }
  ],
  "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:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypa/setuptools vulnerable to Regular Expression Denial of Service (ReDoS)"
}

GHSA-RC47-6667-2J5J

Vulnerability from github – Published: 2023-01-31 06:30 – Updated: 2025-02-13 18:36
VLAI
Summary
http-cache-semantics vulnerable to Regular Expression Denial of Service
Details

http-cache semantics contains an Inefficient Regular Expression Complexity , leading to Denial of Service. This affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-cache-semantics"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.webjars.npm:http-cache-semantics"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-25881"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-01T23:48:07Z",
    "nvd_published_at": "2023-01-31T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "http-cache semantics contains an Inefficient Regular Expression Complexity , leading to Denial of Service. This affects versions of the package http-cache-semantics before 4.1.1. The issue can be exploited via malicious request header values sent to a server, when that server reads the cache policy from the request using this library.",
  "id": "GHSA-rc47-6667-2j5j",
  "modified": "2025-02-13T18:36:37Z",
  "published": "2023-01-31T06:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25881"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kornelski/http-cache-semantics/commit/560b2d8ef452bbba20ffed69dc155d63ac757b74"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kornelski/http-cache-semantics"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kornelski/http-cache-semantics/blob/master/index.js%23L83"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230622-0008"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-3253332"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-HTTPCACHESEMANTICS-3248783"
    }
  ],
  "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": "http-cache-semantics vulnerable to Regular Expression Denial of Service"
}
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.

← Back to the CWE list