LiquidJS: Memory and render limit bypass via unbounded width padding in `date` filter (strftime)
LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the date filter's strftime implementation parses width specifiers like %9999999d and forwards the captured width unchecked into pad()/padStart(), leading to memory and render limit bypass. In src/util/underscore.ts, the pad loop performs unbounded string concatenation without consulting the Context's memoryLimit or renderLimit, so a single small template ({{ x | date: '%5000000d' }}) produces megabytes of output and unbounded CPU. The memoryLimit and renderLimit options the docs (src/liquid-options.ts:87-92) advertise as DoS controls — and which the docstring explicitly mentions for strftime — are entirely bypassed. Exploitation can cause large memory allocations, high CPU usage, or OOM crashes per render. This issue has been fixed in version 10.26.0.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-45357
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 10:57 UTC · Revision 1
Source evidence
LiquidJS: Memory and render limit bypass via unbounded width padding in `date` filter (strftime)
core-osv · Original sourcePublished 17 Jun 2026, 22:32 UTC
LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the date filter's strftime implementation parses width specifiers like %9999999d and forwards the captured width unchecked into pad()/padStart(), leading to memory and render limit bypass. In src/util/underscore.ts, the pad loop performs unbounded string concatenation without consulting the Context's memoryLimit or renderLimit, so a single small template ({{ x | date: '%5000000d' }}) produces megabytes of output and unbounded CPU. The memoryLimit and renderLimit options the docs (src/liquid-options.ts:87-92) advertise as DoS controls — and which the docstring explicitly mentions for strftime — are entirely bypassed. Exploitation can cause large memory allocations, high CPU usage, or OOM crashes per render. This issue has been fixed in version 10.26.0.
osv:CVE-2026-45357
Complete source record
{
"id": "bf459bad22c21f0bbb903f9cedd0458e1f14e3174f839c3b686d14cc703c766f",
"url": "https://osv.dev/vulnerability/CVE-2026-45357",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "LiquidJS: Memory and render limit bypass via unbounded width padding in `date` filter (strftime)",
"summary": "LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the date filter's strftime implementation parses width specifiers like %9999999d and forwards the captured width unchecked into pad()/padStart(), leading to memory and render limit bypass. In src/util/underscore.ts, the pad loop performs unbounded string concatenation without consulting the Context's memoryLimit or renderLimit, so a single small template ({{ x | date: '%5000000d' }}) produces megabytes of output and unbounded CPU. The memoryLimit and renderLimit options the docs (src/liquid-options.ts:87-92) advertise as DoS controls — and which the docstring explicitly mentions for strftime — are entirely bypassed. Exploitation can cause large memory allocations, high CPU usage, or OOM crashes per render. This issue has been fixed in version 10.26.0.",
"evidence": "osv:CVE-2026-45357",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-45357",
"aliases": [
"CVE-2026-45357",
"GHSA-hh27-hf48-9f5q"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/harttle/liquidjs",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "c20c0af02d33e8d2ca6b08925eadca8755257c39"
},
{
"fixed": "3129d46dc95efa357b00e5a57ee1af80a13d72ed"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "10.26.0"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"fixed": "3129d46dc95efa357b00e5a57ee1af80a13d72ed"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "c20c0af02d33e8d2ca6b08925eadca8755257c39"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v10.26.0"
}
]
}
}
],
"versions": [
"v10.25.7",
"v10.25.6",
"v10.25.5",
"v10.25.4",
"v10.25.3",
"v10.25.2",
"v10.25.1",
"v10.25.0",
"v10.24.0",
"v10.23.0",
"v10.22.0",
"v10.21.1",
"v10.21.0",
"v10.20.3",
"v10.20.2",
"v10.20.1",
"v10.20.0",
"v10.19.1",
"v10.19.0",
"v10.18.0",
"v10.17.0",
"v10.16.7",
"v10.16.6",
"v10.16.5",
"v10.16.4",
"v10.16.3",
"v10.16.2",
"v10.16.1",
"v10.16.0",
"v10.15.0",
"v10.14.0",
"v10.13.1",
"v10.13.0",
"v10.12.0",
"v10.11.1",
"v10.11.0",
"v10.10.2",
"v10.10.1",
"v10.10.0",
"v10.9.4",
"v10.9.3",
"v10.9.2",
"v10.9.1",
"v10.9.0",
"v10.8.4",
"v10.8.3",
"v10.8.2",
"v10.8.1",
"v10.8.0",
"v10.7.1",
"v10.7.0",
"v10.6.2",
"v10.6.1",
"v10.6.0",
"v10.5.0",
"v10.4.0",
"v10.3.3",
"v10.3.2",
"v10.3.1",
"v10.3.0",
"v10.2.0",
"v10.1.0",
"v10.0.0",
"v9.43.0",
"v9.42.1",
"v9.42.0",
"v9.41.0",
"v9.40.0",
"v9.39.2",
"v9.39.1",
"v9.39.0",
"v9.38.0",
"v9.37.0",
"v9.36.2",
"v9.36.1",
"v9.36.0",
"v9.35.2",
"v9.35.1",
"v9.35.0",
"v9.34.1",
"v9.34.0",
"v9.33.1",
"v9.33.0",
"v9.32.1",
"v9.32.0",
"v9.31.0",
"v9.30.0",
"v9.29.0",
"v9.28.6",
"v9.28.5",
"v9.28.4",
"v9.28.3",
"v9.28.2",
"v9.28.1",
"v9.28.0",
"v9.27.1",
"v9.27.0",
"v9.26.0",
"v9.25.1",
"v9.25.0",
"v9.24.2",
"v9.24.1",
"v9.24.0",
"v9.23.4",
"v9.23.3",
"v9.23.2",
"v9.23.1",
"v9.23.0",
"v9.22.1",
"v9.22.0",
"v9.21.0",
"v9.20.1",
"v9.20.0",
"v9.19.0",
"v9.18.0",
"v9.17.0",
"v9.16.1",
"v9.16.0",
"v9.15.1",
"v9.15.0",
"v9.14.1",
"v9.14.0",
"v9.13.0",
"v9.12.0",
"v9.11.11",
"v9.11.10",
"v9.11.9",
"v9.11.8",
"v9.11.7",
"v9.11.6",
"v9.11.5",
"v9.11.4",
"v9.11.3",
"v9.11.2",
"v9.11.1",
"v9.11.0",
"v9.10.0",
"v9.9.0",
"v9.8.0",
"v9.7.2",
"v9.7.1",
"v9.7.0",
"v9.6.2",
"v9.6.1",
"v9.6.0",
"v9.5.0",
"v9.4.2",
"v9.4.1",
"v9.4.0",
"v9.3.1",
"v9.3.0",
"v9.2.0",
"v9.1.1",
"v9.1.0",
"v9.0.1",
"v9.0.0",
"v8.5.3",
"v8.5.2",
"v8.5.1",
"v8.5.0",
"v8.4.1",
"v8.4.0",
"v8.3.0",
"v8.2.4",
"v8.2.3",
"v8.2.2",
"v8.2.1",
"v8.2.0",
"v8.1.0",
"v8.0.3",
"v8.0.2",
"v8.0.1",
"v8.0.0",
"v7.5.1",
"v7.5.0",
"v7.4.0",
"v7.3.1",
"v7.3.0",
"v7.2.2",
"v7.2.1",
"v7.2.0",
"v7.1.0",
"v7.0.2",
"v7.0.1",
"v7.0.0",
"v6.4.3",
"v6.4.2",
"v6.4.1",
"v6.4.0",
"v6.3.1",
"v6.3.0",
"v6.2.1",
"v6.2.0",
"v6.1.1",
"v6.0.1",
"v6.0.0",
"v5.3.0-0",
"v5.2.0",
"v5.1.1",
"v5.1.0",
"v5.0.2",
"v5.0.1",
"v5.0.0",
"v4.0.0",
"v3.1.3",
"v3.1.2",
"v3.1.1",
"v3.1.0",
"v3.0.0",
"v2.2.1",
"v2.2.0",
"v2.1.4",
"v2.1.3",
"v2.1.2",
"v2.1.1",
"v2.1.0",
"v2.0.3",
"v2.0.2",
"v2.0.1",
"v2.0.0",
"v1.9.7",
"v1.9.6",
"v1.9.5",
"v1.9.4",
"v1.9.3",
"v1.9.2",
"v1.9.1",
"v1.9.0",
"v1.8.0",
"v1.7.9",
"v1.7.8",
"v1.7.7",
"v1.7.6",
"v1.7.5",
"v1.7.4",
"v1.7.3",
"v1.7.2",
"v1.7.1",
"v1.7.0",
"v1.6.2",
"v1.6.1",
"v1.6.0",
"v1.5.4",
"v1.5.3",
"v1.5.2",
"v1.5.1",
"v1.5.0",
"v1.4.3",
"v1.4.2",
"v1.4.1",
"v1.3.3",
"v1.2.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-45357.json"
}
}
],
"modified": "2026-10-28T02:30:27.994837921Z",
"provider": "osv",
"references": [
"https://github.com/harttle/liquidjs/releases/tag/v10.26.0",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45357.json",
"https://github.com/harttle/liquidjs/security/advisories/GHSA-hh27-hf48-9f5q",
"https://nvd.nist.gov/vuln/detail/CVE-2026-45357",
"https://github.com/harttle/liquidjs/commit/3129d46dc95efa357b00e5a57ee1af80a13d72ed"
],
"provider_metadata": {
"cwe_ids": [
"CWE-400"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45357.json"
}
},
"related_cves": [
{
"value": "CVE-2026-45357",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 494782,
"published_at": "2026-06-17T22:32:20.643+00:00"
}