CWE-1333
AllowedInefficient 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.
792 vulnerabilities reference this CWE, most recent first.
GHSA-6RVG-6V2M-4J46
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 17:43A Regular Expression Denial of Service (ReDoS) vulnerability was identified in the huggingface/transformers library, specifically in the file tokenization_nougat_fast.py. The vulnerability occurs in the post_process_single() function, where a regular expression processes specially crafted input. The issue stems from the regex exhibiting exponential time complexity under certain conditions, leading to excessive backtracking. This can result in significantly high CPU usage and potential application downtime, effectively creating a Denial of Service (DoS) scenario. The affected version is v4.46.3.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "transformers"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.48.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12720"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T17:43:02Z",
"nvd_published_at": "2025-03-20T10:15:29Z",
"severity": "MODERATE"
},
"details": "A Regular Expression Denial of Service (ReDoS) vulnerability was identified in the huggingface/transformers library, specifically in the file tokenization_nougat_fast.py. The vulnerability occurs in the post_process_single() function, where a regular expression processes specially crafted input. The issue stems from the regex exhibiting exponential time complexity under certain conditions, leading to excessive backtracking. This can result in significantly high CPU usage and potential application downtime, effectively creating a Denial of Service (DoS) scenario. The affected version is v4.46.3.",
"id": "GHSA-6rvg-6v2m-4j46",
"modified": "2025-03-21T17:43:02Z",
"published": "2025-03-20T12:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12720"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/transformers/commit/deac971c469bcbb182c2e52da0b82fb3bf54cccf"
},
{
"type": "PACKAGE",
"url": "https://github.com/huggingface/transformers"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/4bed1214-7835-4252-a853-22bbad891f98"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Transformers Regular Expression Denial of Service (ReDoS) vulnerability"
}
GHSA-6VFC-QV3F-VR6C
Vulnerability from github – Published: 2022-01-12 22:20 – Updated: 2022-01-19 18:25Impact
Special patterns with length > 50K chars can slow down parser significantly.
const md = require('markdown-it')();
md.render(`x ${' '.repeat(150000)} x \nx`);
Patches
Upgrade to v12.3.2+
Workarounds
No.
References
Fix + test sample: https://github.com/markdown-it/markdown-it/commit/ffc49ab46b5b751cd2be0aabb146f2ef84986101
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "markdown-it"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-21670"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-10T21:50:05Z",
"nvd_published_at": "2022-01-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nSpecial patterns with length \u003e 50K chars can slow down parser significantly.\n\n```js\nconst md = require(\u0027markdown-it\u0027)();\n\nmd.render(`x ${\u0027 \u0027.repeat(150000)} x \\nx`);\n```\n\n\n### Patches\n\nUpgrade to v12.3.2+\n\n### Workarounds\n\nNo.\n\n### References\n\nFix + test sample: https://github.com/markdown-it/markdown-it/commit/ffc49ab46b5b751cd2be0aabb146f2ef84986101\n",
"id": "GHSA-6vfc-qv3f-vr6c",
"modified": "2022-01-19T18:25:52Z",
"published": "2022-01-12T22:20:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/markdown-it/markdown-it/security/advisories/GHSA-6vfc-qv3f-vr6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21670"
},
{
"type": "WEB",
"url": "https://github.com/markdown-it/markdown-it/commit/ffc49ab46b5b751cd2be0aabb146f2ef84986101"
},
{
"type": "PACKAGE",
"url": "https://github.com/markdown-it/markdown-it"
}
],
"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": "Uncontrolled Resource Consumption in markdown-it"
}
GHSA-6W53-65XX-MGJ9
Vulnerability from github – Published: 2025-06-20 21:32 – Updated: 2025-06-20 21:32A Denial of Service (DoS) condition has been discovered in GitLab CE/EE affecting all versions from 7.10 prior before 16.11.5, version 17.0 before 17.0.3, and 17.1 before 17.1.1. It is possible for an attacker to cause a denial of service using a crafted markdown page.
{
"affected": [],
"aliases": [
"CVE-2024-4025"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-20T19:15:35Z",
"severity": "MODERATE"
},
"details": "A Denial of Service (DoS) condition has been discovered in GitLab CE/EE affecting all versions from 7.10 prior before 16.11.5, version 17.0 before 17.0.3, and 17.1 before 17.1.1. It is possible for an attacker to cause a denial of service using a crafted markdown page.",
"id": "GHSA-6w53-65xx-mgj9",
"modified": "2025-06-20T21:32:07Z",
"published": "2025-06-20T21:32:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4025"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2024974"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/457474"
}
],
"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"
}
]
}
GHSA-6W57-8P2P-2R2X
Vulnerability from github – Published: 2024-06-27 21:32 – Updated: 2025-10-15 15:30A Regular Expression Denial of Service (ReDoS) vulnerability exists in the latest version of gaizhenbiao/chuanhuchatgpt. The vulnerability is located in the filter_history function within the utils.py module. This function takes a user-provided keyword and attempts to match it against chat history filenames using a regular expression search. Due to the lack of sanitization or validation of the keyword parameter, an attacker can inject a specially crafted regular expression, leading to a denial of service condition. This can cause severe degradation of service performance and potential system unavailability.
{
"affected": [],
"aliases": [
"CVE-2024-6038"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-625"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-27T19:15:19Z",
"severity": "HIGH"
},
"details": "A Regular Expression Denial of Service (ReDoS) vulnerability exists in the latest version of gaizhenbiao/chuanhuchatgpt. The vulnerability is located in the filter_history function within the utils.py module. This function takes a user-provided keyword and attempts to match it against chat history filenames using a regular expression search. Due to the lack of sanitization or validation of the keyword parameter, an attacker can inject a specially crafted regular expression, leading to a denial of service condition. This can cause severe degradation of service performance and potential system unavailability.",
"id": "GHSA-6w57-8p2p-2r2x",
"modified": "2025-10-15T15:30:19Z",
"published": "2024-06-27T21:32:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6038"
},
{
"type": "WEB",
"url": "https://github.com/gaizhenbiao/chuanhuchatgpt/commit/fcdd5fd6b05ef537a1db185ab115758d87e1ba3f"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/d41cca0a-82bc-4cbf-a52a-928d304fb42d"
}
],
"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"
}
]
}
GHSA-6W63-H3FJ-Q4VW
Vulnerability from github – Published: 2023-06-06 17:33 – Updated: 2026-03-09 15:58Impact
"fast-xml-parser" allows special characters in entity names, which are not escaped or sanitized. Since the entity name is used for creating a regex for searching and replacing entities in the XML body, an attacker can abuse it for DoS attacks. By crafting an entity name that results in an intentionally bad performing regex and utilizing it in the entity replacement step of the parser, this can cause the parser to stall for an indefinite amount of time.
Patches
The problem has been resolved in v4.2.4
Workarounds
Avoid using DOCTYPE parsing by processEntities: false option.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fast-xml-parser"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.3"
},
{
"fixed": "4.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34104"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-06T17:33:13Z",
"nvd_published_at": "2023-06-06T18:15:11Z",
"severity": "HIGH"
},
"details": "### Impact\n\"fast-xml-parser\" allows special characters in entity names, which are not escaped or sanitized. Since the entity name is used for creating a regex for searching and replacing entities in the XML body, an attacker can abuse it for DoS attacks. By crafting an entity name that results in an intentionally bad performing regex and utilizing it in the entity replacement step of the parser, this can cause the parser to stall for an indefinite amount of time.\n\n### Patches\nThe problem has been resolved in v4.2.4\n\n### Workarounds\nAvoid using DOCTYPE parsing by `processEntities: false` option.",
"id": "GHSA-6w63-h3fj-q4vw",
"modified": "2026-03-09T15:58:38Z",
"published": "2023-06-06T17:33:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/security/advisories/GHSA-6w63-h3fj-q4vw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34104"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/commit/39b0e050bb909e8499478657f84a3076e39ce76c"
},
{
"type": "WEB",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser/commit/a4bdced80369892ee413bf08e28b78795a2b0d5b"
},
{
"type": "PACKAGE",
"url": "https://github.com/NaturalIntelligence/fast-xml-parser"
}
],
"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": "fast-xml-parser vulnerable to Regex Injection via Doctype Entities"
}
GHSA-6W78-P685-P2F6
Vulnerability from github – Published: 2026-07-30 15:31 – Updated: 2026-08-21 09:32Date::Manip versions through 6.99 for Perl allow CPU exhaustion via quadratic backtracking in the unanchored time substitution in _parse_time.
_parse_time removes a time from anywhere in the string with the unanchored substitution s/$timerx/ /, where $timerx is an auto-generated alternation of time patterns reached through a leading (?:$atrx|^|\s+). The engine therefore retries the match at every position of an interior whitespace run: at each start position the leading \s+ consumes the rest of the run greedily, the time alternation fails because the run holds no digits, and the engine backtracks a space at a time across the run before advancing the start position, which is quadratic in the length of the run. No time need be present in the string for this to happen, only a long run of whitespace, and the parse time rises about fourfold for each doubling of the run: a few kilobytes of whitespace costs seconds of CPU per parse and tens of kilobytes costs minutes.
Any caller that passes an untrusted string of unbounded length to ParseDate(), Date::Manip::Date->parse() or ->parse_time() can be made to spend unbounded CPU in a single parse, a denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-60075"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T14:17:02Z",
"severity": "HIGH"
},
"details": "Date::Manip versions through 6.99 for Perl allow CPU exhaustion via quadratic backtracking in the unanchored time substitution in _parse_time.\n\n_parse_time removes a time from anywhere in the string with the unanchored substitution `s/$timerx/ /`, where $timerx is an auto-generated alternation of time patterns reached through a leading `(?:$atrx|^|\\s+)`. The engine therefore retries the match at every position of an interior whitespace run: at each start position the leading `\\s+` consumes the rest of the run greedily, the time alternation fails because the run holds no digits, and the engine backtracks a space at a time across the run before advancing the start position, which is quadratic in the length of the run. No time need be present in the string for this to happen, only a long run of whitespace, and the parse time rises about fourfold for each doubling of the run: a few kilobytes of whitespace costs seconds of CPU per parse and tens of kilobytes costs minutes.\n\nAny caller that passes an untrusted string of unbounded length to ParseDate(), Date::Manip::Date-\u003eparse() or -\u003eparse_time() can be made to spend unbounded CPU in a single parse, a denial of service.",
"id": "GHSA-6w78-p685-p2f6",
"modified": "2026-08-21T09:32:02Z",
"published": "2026-07-30T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60075"
},
{
"type": "WEB",
"url": "https://github.com/SBECK-github/Date-Manip/pull/55"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1526"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/SBECK/Date-Manip-6.99/source/lib/Date/Manip/Date.pm#L1811"
},
{
"type": "WEB",
"url": "https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60075-r1.patch"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/30/20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6X26-6R6F-M537
Vulnerability from github – Published: 2026-07-31 18:36 – Updated: 2026-07-31 18:36Summary
The ALLOWED_SOURCES configuration is meant to restrict which hosts Thumbor's HTTP loader may fetch images from. Plain-string entries in that list (the overwhelming majority of real-world and documented configurations) are passed directly to re.match() without escaping. Because . is a regex wildcard, every dot in a domain name becomes a bypass vector: s.glbimg.com silently matches sXglbimgYcom, sAglbimg.com, and any other hostname that differs only at a dot position. This undermines the primary SSRF defence that ALLOWED_SOURCES is intended to provide.
Affected component
thumbor/loaders/http_loader.py — validate()
Proof of concept
import re
from thumbor.config import Config
from thumbor.context import Context
from thumbor.loaders import http_loader as loader
config = Config()
config.ALLOWED_SOURCES = ["s.glbimg.com"] # typical user config
ctx = Context(None, config, None)
# These should be blocked — both return True due to the unescaped dot
print(loader.validate(ctx, "http://sXglbimgYcom/secret.jpg")) # True ← bypass
print(loader.validate(ctx, "http://sAglbimg.com/secret.jpg")) # True ← bypass
# Legitimate origin — correctly allowed
print(loader.validate(ctx, "http://s.glbimg.com/logo.jpg")) # True ← correct
Root cause
thumbor/loaders/http_loader.py (before fix):
for pattern in context.config.ALLOWED_SOURCES:
if isinstance(pattern, Pattern):
match = url
else:
pattern = f"^{pattern}$" # <-- dots not escaped, act as regex wildcard
match = res.hostname
if re.match(pattern, match):
return True
Impact
An attacker who can influence the image source URL passed to Thumbor can fetch images from arbitrary hosts, bypassing the ALLOWED_SOURCES allowlist.
Preconditions:
ALLOWED_SOURCEScontains at least one plain-string entry (the common case; all official documentation examples use plain strings).- The attacker can supply or influence the image URL — true whenever
ALLOW_UNSAFE_URL = True(the default), or when the application forwards user input to a signed URL endpoint.
Fix
Apply re.escape() to plain-string patterns before compiling them, so every
character is matched literally:
else:
pattern = f"^{re.escape(pattern)}$" # dots and other metacharacters are now literal
match = res.hostname
This is a one-call addition with no breaking change for correctly written configurations. Users who need real regular-expression behaviour should supply a compiled pattern (re.compile(r"s\.glbimg\.com")), which is already handled by the existing isinstance(pattern, Pattern) branch and is unaffected by this change.
The ALLOWED_SOURCES docstring in config.py was also updated to document the two-mode behaviour explicitly.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.7.7"
},
"package": {
"ecosystem": "PyPI",
"name": "thumbor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53500"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-31T18:36:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe `ALLOWED_SOURCES` configuration is meant to restrict which hosts Thumbor\u0027s HTTP loader may fetch images from. Plain-string entries in that list (the overwhelming majority of real-world and documented configurations) are passed directly to `re.match()` without escaping. Because `.` is a regex wildcard, every dot in a domain name becomes a bypass vector: `s.glbimg.com` silently matches `sXglbimgYcom`, `sAglbimg.com`, and any other hostname that differs only at a dot position. This undermines the primary SSRF defence that `ALLOWED_SOURCES` is intended to provide.\n\n## Affected component\n\n`thumbor/loaders/http_loader.py` \u2014 `validate()`\n\n## Proof of concept\n\n```python\nimport re\nfrom thumbor.config import Config\nfrom thumbor.context import Context\nfrom thumbor.loaders import http_loader as loader\n\nconfig = Config()\nconfig.ALLOWED_SOURCES = [\"s.glbimg.com\"] # typical user config\nctx = Context(None, config, None)\n\n# These should be blocked \u2014 both return True due to the unescaped dot\nprint(loader.validate(ctx, \"http://sXglbimgYcom/secret.jpg\")) # True \u2190 bypass\nprint(loader.validate(ctx, \"http://sAglbimg.com/secret.jpg\")) # True \u2190 bypass\n\n# Legitimate origin \u2014 correctly allowed\nprint(loader.validate(ctx, \"http://s.glbimg.com/logo.jpg\")) # True \u2190 correct\n```\n\n## Root cause\n\n`thumbor/loaders/http_loader.py` (before fix):\n\n```python\nfor pattern in context.config.ALLOWED_SOURCES:\n if isinstance(pattern, Pattern):\n match = url\n else:\n pattern = f\"^{pattern}$\" # \u003c-- dots not escaped, act as regex wildcard\n match = res.hostname\n\n if re.match(pattern, match):\n return True\n```\n\n## Impact\n\nAn attacker who can influence the image source URL passed to Thumbor can fetch images from arbitrary hosts, bypassing the `ALLOWED_SOURCES` allowlist.\n\n**Preconditions:**\n\n- `ALLOWED_SOURCES` contains at least one plain-string entry (the common case; all official documentation examples use plain strings).\n- The attacker can supply or influence the image URL \u2014 true whenever `ALLOW_UNSAFE_URL = True` (the default), or when the application forwards user input to a signed URL endpoint.\n\n## Fix\n\nApply `re.escape()` to plain-string patterns before compiling them, so every\ncharacter is matched literally:\n\n```python\nelse:\n pattern = f\"^{re.escape(pattern)}$\" # dots and other metacharacters are now literal\n match = res.hostname\n```\n\nThis is a one-call addition with no breaking change for correctly written configurations. Users who need real regular-expression behaviour should supply a compiled pattern (`re.compile(r\"s\\.glbimg\\.com\")`), which is already handled by the existing `isinstance(pattern, Pattern)` branch and is unaffected by this change.\n\nThe `ALLOWED_SOURCES` docstring in `config.py` was also updated to document the two-mode behaviour explicitly.",
"id": "GHSA-6x26-6r6f-m537",
"modified": "2026-07-31T18:36:03Z",
"published": "2026-07-31T18:36:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/thumbor/thumbor/security/advisories/GHSA-6x26-6r6f-m537"
},
{
"type": "WEB",
"url": "https://github.com/thumbor/thumbor/commit/68876715350c6c8f49c324e5515e64908830aed7"
},
{
"type": "PACKAGE",
"url": "https://github.com/thumbor/thumbor"
},
{
"type": "WEB",
"url": "https://github.com/thumbor/thumbor/releases/tag/7.8.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Thumbor treats ALLOWED_SOURCES string patterns as unescaped regex, allowing hostname bypass via wildcard dot"
}
GHSA-72QW-P7HH-M3FF
Vulnerability from github – Published: 2023-10-19 12:33 – Updated: 2023-10-19 12:33Summary
The torbot.modules.validators.validate_link function uses the python-validators URL validation regex. This particular regular expression has an exponential complexity which allows an attacker to cause an application crash using a well-crafted argument..
Details
https://github.com/DedSecInside/TorBot/blob/d2b89192379ad033ffc7044efff26e16ccc02d5a/torbot/modules/validators.py#L13
An attacker can use a well-crafted URL argument to exploit the vulnerability in the regular expression and cause a Denial of Service on the system.
PoC
I have uploaded a secret gist containing a PoC (https://gist.github.com/ikkebr/6041055314f1cfb8e65b2a1acbaae12c). By adding one special character at the end of the user argument of the URL, the regular expression will take exponentially longer to compute.
For a string of size 10k, the regex will take 0.01s without the well-crafted URL and 1.3s with the well-crafted URL exploit. For a string of size 50k, the regex will take 0.03s without the well-crafted URL and 35s with the well-crafted URL exploit. For a string of size 100k, the regex will take 0.05s without the well-crafted URL and over 200s with the well-crafted URL exploit.
The regular expression used in the validators library versions [0.20, 0.11] is vulnerable to this attack. Version 0.21 appears to be unaffected, but it no longer contains a single regular expression.
Impact
An attacker could exploit this vulnerability to cause a denial of service or increased resource usage.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "torbot"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-45813"
],
"database_specific": {
"cwe_ids": [
"CWE-1333"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-19T12:33:03Z",
"nvd_published_at": "2023-10-18T21:15:09Z",
"severity": "MODERATE"
},
"details": "### Summary\n_The torbot.modules.validators.validate_link function uses the python-validators URL validation regex. This particular regular expression has an exponential complexity which allows an attacker to cause an application crash using a well-crafted argument.._\n\n### Details\nhttps://github.com/DedSecInside/TorBot/blob/d2b89192379ad033ffc7044efff26e16ccc02d5a/torbot/modules/validators.py#L13\n\nAn attacker can use a well-crafted URL argument to exploit the vulnerability in the regular expression and cause a Denial of Service on the system.\n\n### PoC\nI have uploaded a secret gist containing a PoC (https://gist.github.com/ikkebr/6041055314f1cfb8e65b2a1acbaae12c). By adding one special character at the end of the user argument of the URL, the regular expression will take exponentially longer to compute.\n\nFor a string of size 10k, the regex will take 0.01s without the well-crafted URL and 1.3s with the well-crafted URL exploit.\nFor a string of size 50k, the regex will take 0.03s without the well-crafted URL and 35s with the well-crafted URL exploit.\nFor a string of size 100k, the regex will take 0.05s without the well-crafted URL and over 200s with the well-crafted URL exploit.\n\nThe regular expression used in the validators library versions [0.20, 0.11] is vulnerable to this attack. Version 0.21 appears to be unaffected, but it no longer contains a single regular expression.\n\n### Impact\nAn attacker could exploit this vulnerability to cause a denial of service or increased resource usage.\n",
"id": "GHSA-72qw-p7hh-m3ff",
"modified": "2023-10-19T12:33:03Z",
"published": "2023-10-19T12:33:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DedSecInside/TorBot/security/advisories/GHSA-72qw-p7hh-m3ff"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45813"
},
{
"type": "WEB",
"url": "https://github.com/DedSecInside/TorBot/commit/ef6e06bc7785355b1701d5524eb4550441086ac4"
},
{
"type": "WEB",
"url": "https://gist.github.com/ikkebr/6041055314f1cfb8e65b2a1acbaae12c"
},
{
"type": "PACKAGE",
"url": "https://github.com/DedSecInside/TorBot"
},
{
"type": "WEB",
"url": "https://github.com/DedSecInside/TorBot/blob/d2b89192379ad033ffc7044efff26e16ccc02d5a/torbot/modules/validators.py#L13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "TorBot vulnerable to Inefficient Regular Expression Complexity in validate_link"
}
GHSA-73CQ-MCGH-379C
Vulnerability from github – Published: 2026-08-04 20:42 – Updated: 2026-08-04 20:42Summary
In every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single FREQ=MINUTELY rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop.
Preconditions
Any user who can create an automation. USER_PERMISSIONS_FEATURES_AUTOMATIONS defaults to false, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. UVICORN_WORKERS defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: FREQ=MINUTELY with no DTSTART, or with a DTSTART set well in the past, is enough.
Impact
Availability, against every other user of the instance. One evaluation of RRULE:FREQ=MINUTELY takes 18.9 s of blocking CPU; adding a ten-value BYSECOND list multiplies the walk and takes 64.2 s. FREQ=HOURLY costs 0.34 s and is not materially exploitable on its own. The cost does not stop at creation: once the automation is stored, the scheduler recomputes the next run for every claimed row on each poll, so the same walk repeats on a default 10 s interval and the instance stays wedged rather than recovering. Instances that have not enabled the automations feature for non-admin users are exposed only to an admin doing this.
Fix
Fixed in 0.11.0. Sub-daily rules are now anchored to the current clock instead of the year-2000 date, so the walk starts at the next occurrence rather than a quarter-century behind it. A caller-supplied DTSTART is honoured only when the number of occurrences it implies stays under a fixed bound, and is otherwise replaced by the clock-aligned anchor. The same rules that cost 18.9 s and 64.2 s now cost under a millisecond. Upgrading fully resolves the issue, no configuration change is required.
Root cause
Affected component: backend/open_webui/utils/automations.py, _parse_rule, reached from the automation create, update and toggle handlers in backend/open_webui/routers/automations.py and from the scheduler's claim path in backend/open_webui/models/automations.py. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped.
The fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that "every 5 minutes" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread.
Proof of concept
Measured cost of a single next-run computation against the shipped 0.10.2 parser:
| rule | cost |
|---|---|
RRULE:FREQ=MINUTELY |
18,880 ms |
RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9 |
64,236 ms |
DTSTART:20000101T000000 + RRULE:FREQ=MINUTELY |
26,237 ms |
RRULE:FREQ=HOURLY |
339 ms |
Measured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance.
Credits
Reported by @Classic298.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70489"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-04T20:42:34Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nIn every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single `FREQ=MINUTELY` rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop.\n\n## Preconditions\nAny user who can create an automation. `USER_PERMISSIONS_FEATURES_AUTOMATIONS` defaults to `false`, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. `UVICORN_WORKERS` defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: `FREQ=MINUTELY` with no `DTSTART`, or with a `DTSTART` set well in the past, is enough.\n\n## Impact\nAvailability, against every other user of the instance. One evaluation of `RRULE:FREQ=MINUTELY` takes 18.9 s of blocking CPU; adding a ten-value `BYSECOND` list multiplies the walk and takes 64.2 s. `FREQ=HOURLY` costs 0.34 s and is not materially exploitable on its own. The cost does not stop at creation: once the automation is stored, the scheduler recomputes the next run for every claimed row on each poll, so the same walk repeats on a default 10 s interval and the instance stays wedged rather than recovering. Instances that have not enabled the automations feature for non-admin users are exposed only to an admin doing this.\n\n## Fix\nFixed in 0.11.0. Sub-daily rules are now anchored to the current clock instead of the year-2000 date, so the walk starts at the next occurrence rather than a quarter-century behind it. A caller-supplied `DTSTART` is honoured only when the number of occurrences it implies stays under a fixed bound, and is otherwise replaced by the clock-aligned anchor. The same rules that cost 18.9 s and 64.2 s now cost under a millisecond. Upgrading fully resolves the issue, no configuration change is required.\n\n## Root cause\nAffected component: `backend/open_webui/utils/automations.py`, `_parse_rule`, reached from the automation create, update and toggle handlers in `backend/open_webui/routers/automations.py` and from the scheduler\u0027s claim path in `backend/open_webui/models/automations.py`. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped.\n\nThe fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that \"every 5 minutes\" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread.\n\n## Proof of concept\nMeasured cost of a single next-run computation against the shipped 0.10.2 parser:\n\n| rule | cost |\n| --- | --- |\n| `RRULE:FREQ=MINUTELY` | 18,880 ms |\n| `RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9` | 64,236 ms |\n| `DTSTART:20000101T000000` + `RRULE:FREQ=MINUTELY` | 26,237 ms |\n| `RRULE:FREQ=HOURLY` | 339 ms |\n\nMeasured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance.\n\n## Credits\nReported by @Classic298.",
"id": "GHSA-73cq-mcgh-379c",
"modified": "2026-08-04T20:42:34Z",
"published": "2026-08-04T20:42:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-73cq-mcgh-379c"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/c4ae8c86786fed521960466f6d8eef8af22c2946"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.0"
}
],
"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": "Open WebUI: Instance-wide stall via automation recurrence rules that force multi-second parsing"
}
GHSA-73RR-HH4G-FPGX
Vulnerability from github – Published: 2026-01-14 21:34 – Updated: 2026-01-30 17:13Impact
Attempting to parse a patch whose filename headers contain the line break characters \r, \u2028, or \u2029 can cause the parsePatch method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory.
Applications are therefore likely to be vulnerable to a denial-of-service attack if they call parsePatch with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling parsePatch on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed).
The applyPatch method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using parsePatch. Other methods of the library are unaffected.
Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's patch header (also known as its "leading garbage"). A maliciously-crafted patch header of length n can take parsePatch O(n³) time to parse.
Patches
All vulnerabilities described are fixed in v8.0.3.
Workarounds
If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: \r, \u2028, or \u2029.
References
PR that fixed the bug: https://github.com/kpdecker/jsdiff/pull/649
CVE Notes
Note that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to parsePatch can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "diff"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "8.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "diff"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.2.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "diff"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "diff"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24001"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-14T21:34:12Z",
"nvd_published_at": "2026-01-22T03:15:47Z",
"severity": "LOW"
},
"details": "### Impact\n\nAttempting to parse a patch whose filename headers contain the line break characters `\\r`, `\\u2028`, or `\\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory.\n\nApplications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed).\n\nThe `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected.\n\nFinally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch\u0027s *patch* header (also known as its \"leading garbage\"). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*\u00b3) time to parse.\n\n### Patches\n\nAll vulnerabilities described are fixed in v8.0.3.\n\n### Workarounds\n\nIf using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: `\\r`, `\\u2028`, or `\\u2029`.\n\n### References\n\nPR that fixed the bug: https://github.com/kpdecker/jsdiff/pull/649\n\n\n### CVE Notes\n\nNote that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to `parsePatch` can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability.",
"id": "GHSA-73rr-hh4g-fpgx",
"modified": "2026-01-30T17:13:35Z",
"published": "2026-01-14T21:34:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kpdecker/jsdiff/security/advisories/GHSA-73rr-hh4g-fpgx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24001"
},
{
"type": "WEB",
"url": "https://github.com/kpdecker/jsdiff/issues/653"
},
{
"type": "WEB",
"url": "https://github.com/kpdecker/jsdiff/pull/649"
},
{
"type": "WEB",
"url": "https://github.com/kpdecker/jsdiff/commit/15a1585230748c8ae6f8274c202e0c87309142f5"
},
{
"type": "PACKAGE",
"url": "https://github.com/kpdecker/jsdiff"
}
],
"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": "jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch"
}
Mitigation
Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
Mitigation
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
Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
Mitigation
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.