CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6238 vulnerabilities reference this CWE, most recent first.
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-73JC-5MRQ-PRW7
Vulnerability from github – Published: 2026-05-19 20:10 – Updated: 2026-07-06 22:53Impact
In deployments where untrusted users can provide SQL queries to be linted, an untrusted user can submit a malicious long query to any application using the parser to trigger a Denial of Service through resource exhaustion.
Patches
Versions 4.2.0 and up contain a configurable parse node limit, which is enabled by default, to prevent this manner of exploit.
Credit
Ori Nakar from Imperva Threat Research Team.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "sqlfluff"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46374"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:10:53Z",
"nvd_published_at": "2026-06-09T23:16:59Z",
"severity": "HIGH"
},
"details": "### Impact\n\nIn deployments where untrusted users can provide SQL queries to be linted, an untrusted user can submit a malicious long query to any application using the parser to trigger a Denial of Service through resource exhaustion.\n\n### Patches\n\nVersions 4.2.0 and up contain a configurable parse node limit, which is enabled by default, to prevent this manner of exploit.\n\n### Credit\n\nOri Nakar from Imperva Threat Research Team.",
"id": "GHSA-73jc-5mrq-prw7",
"modified": "2026-07-06T22:53:28Z",
"published": "2026-05-19T20:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sqlfluff/sqlfluff/security/advisories/GHSA-73jc-5mrq-prw7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46374"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/sqlfluff/PYSEC-2026-210.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/sqlfluff/sqlfluff"
}
],
"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": "SQLFluff: Uncontrolled Resource Consumption in SQLFluff Parser"
}
GHSA-73M2-3PWG-5FGC
Vulnerability from github – Published: 2020-02-04 03:07 – Updated: 2024-11-19 15:34Impact
When waitress receives a header that contains invalid characters it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions.
This would allow an attacker to send a single request with an invalid header and take the service offline.
Invalid header example:
Bad-header: xxxxxxxxxxxxxxx\x10
Increasing the number of x's in the header will increase the amount of time Waitress spends in the regular expression engine.
This issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230.
Patches
The regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible.
Workarounds
If you have deployed a reverse proxy in front of Waitress it may already be rejecting requests that include invalid headers.
Thanks
The Pylons Project would like to thank Fil Zembowicz for reaching out and disclosing this vulnerability!
References
Catastrophic backtracking explained: https://www.regular-expressions.info/catastrophic.html
For more information
If you have any questions or comments about this advisory:
- open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)
- email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "waitress"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.2"
},
{
"fixed": "1.4.3"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.4.2"
]
}
],
"aliases": [
"CVE-2020-5236"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-02-04T03:06:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nWhen waitress receives a header that contains invalid characters it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions.\n\nThis would allow an attacker to send a single request with an invalid header and take the service offline.\n\nInvalid header example:\n\n```\nBad-header: xxxxxxxxxxxxxxx\\x10\n```\n\nIncreasing the number of `x`\u0027s in the header will increase the amount of time Waitress spends in the regular expression engine.\n\nThis issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230.\n\n### Patches\n\nThe regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible.\n\n### Workarounds\n\nIf you have deployed a reverse proxy in front of Waitress it may already be rejecting requests that include invalid headers.\n\n### Thanks\n\nThe Pylons Project would like to thank [Fil Zembowicz](https://github.com/fzembow) for reaching out and disclosing this vulnerability!\n\n### References\n\nCatastrophic backtracking explained: https://www.regular-expressions.info/catastrophic.html\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related)\n- email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)",
"id": "GHSA-73m2-3pwg-5fgc",
"modified": "2024-11-19T15:34:34Z",
"published": "2020-02-04T03:07:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/security/advisories/GHSA-73m2-3pwg-5fgc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5236"
},
{
"type": "WEB",
"url": "https://github.com/Pylons/waitress/commit/6e46f9e3f014d64dd7d1e258eaf626e39870ee1f"
},
{
"type": "PACKAGE",
"url": "https://github.com/Pylons/waitress"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/waitress/PYSEC-2020-155.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Catastrophic backtracking in regex allows Denial of Service in Waitress"
}
GHSA-73PF-MVFQ-RGHP
Vulnerability from github – Published: 2022-05-02 03:43 – Updated: 2025-04-09 04:14Microsoft Internet Explorer 7 through 7.0.6000.16711 allows remote attackers to cause a denial of service (unusable browser) by calling the window.print function in a loop, aka a "printing DoS attack," possibly a related issue to CVE-2009-0821.
{
"affected": [],
"aliases": [
"CVE-2009-3270"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-09-18T22:30:00Z",
"severity": "MODERATE"
},
"details": "Microsoft Internet Explorer 7 through 7.0.6000.16711 allows remote attackers to cause a denial of service (unusable browser) by calling the window.print function in a loop, aka a \"printing DoS attack,\" possibly a related issue to CVE-2009-0821.",
"id": "GHSA-73pf-mvfq-rghp",
"modified": "2025-04-09T04:14:37Z",
"published": "2022-05-02T03:43:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3270"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6281"
},
{
"type": "WEB",
"url": "http://websecurity.com.ua/2872"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/506328/100/100/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/79354"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-73PJ-G97W-QP62
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02A vulnerability has been identified in SIMATIC NET CP 343-1 Advanced (incl. SIPLUS variants) (All versions), SIMATIC NET CP 343-1 Lean (incl. SIPLUS variants) (All versions), SIMATIC NET CP 343-1 Standard (incl. SIPLUS variants) (All versions). Specially crafted packets sent to TCP port 102 could cause a Denial-of-Service condition on the affected devices. A cold restart might be necessary in order to recover.
{
"affected": [],
"aliases": [
"CVE-2020-25242"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-12T14:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SIMATIC NET CP 343-1 Advanced (incl. SIPLUS variants) (All versions), SIMATIC NET CP 343-1 Lean (incl. SIPLUS variants) (All versions), SIMATIC NET CP 343-1 Standard (incl. SIPLUS variants) (All versions). Specially crafted packets sent to TCP port 102 could cause a Denial-of-Service condition on the affected devices. A cold restart might be necessary in order to recover.",
"id": "GHSA-73pj-g97w-qp62",
"modified": "2022-05-24T19:02:15Z",
"published": "2022-05-24T19:02:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25242"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-676775.pdf"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-131-07"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-73QC-88CX-HQMH
Vulnerability from github – Published: 2022-05-13 01:09 – Updated: 2022-05-13 01:09The mxmlDelete function in mxml-node.c in mxml 2.9, 2.7, and possibly earlier allows remote attackers to cause a denial of service (stack consumption) via crafted xml file.
{
"affected": [],
"aliases": [
"CVE-2016-4570"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-03T15:59:00Z",
"severity": "HIGH"
},
"details": "The mxmlDelete function in mxml-node.c in mxml 2.9, 2.7, and possibly earlier allows remote attackers to cause a denial of service (stack consumption) via crafted xml file.",
"id": "GHSA-73qc-88cx-hqmh",
"modified": "2022-05-13T01:09:17Z",
"published": "2022-05-13T01:09:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-4570"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1334648"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/01/msg00018.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/05/09/16"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/05/11/14"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/90315"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-73QC-G3PC-J338
Vulnerability from github – Published: 2025-02-13 00:33 – Updated: 2025-02-14 18:30An issue was discovered in Samsung Mobile Processor Exynos 2200, 1480, and 2400. The absence of a null check leads to a Denial of Service at amdgpu_cs_ib_fill in the Xclipse Driver.
{
"affected": [],
"aliases": [
"CVE-2024-46923"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-12T22:15:39Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Samsung Mobile Processor Exynos 2200, 1480, and 2400. The absence of a null check leads to a Denial of Service at amdgpu_cs_ib_fill in the Xclipse Driver.",
"id": "GHSA-73qc-g3pc-j338",
"modified": "2025-02-14T18:30:49Z",
"published": "2025-02-13T00:33:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46923"
},
{
"type": "WEB",
"url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
}
],
"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-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"
}
GHSA-73W2-5F6G-JX42
Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.3 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. A Regular Expression Denial of Service was possible via sending crafted payloads to the preview_markdown endpoint.
{
"affected": [],
"aliases": [
"CVE-2023-3424"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-13T03:15:10Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 10.3 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. A Regular Expression Denial of Service was possible via sending crafted payloads to the preview_markdown endpoint.",
"id": "GHSA-73w2-5f6g-jx42",
"modified": "2024-04-04T06:06:32Z",
"published": "2023-07-13T03:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3424"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1960970"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/409802"
}
],
"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-7443-RX53-4V58
Vulnerability from github – Published: 2022-10-15 12:01 – Updated: 2022-10-18 19:00In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.
{
"affected": [],
"aliases": [
"CVE-2022-39123"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-14T19:15:00Z",
"severity": "MODERATE"
},
"details": "In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.",
"id": "GHSA-7443-rx53-4v58",
"modified": "2022-10-18T19:00:30Z",
"published": "2022-10-15T12:01:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39123"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1575654905820020738"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.