CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5419 vulnerabilities reference this CWE, most recent first.
GHSA-HGPR-8P93-4GQM
Vulnerability from github – Published: 2026-02-04 03:30 – Updated: 2026-02-04 21:30A path traversal in Moo Chan Song v4.5.7 allows attackers to cause a Denial of Service (DoS) via writing files to the internal storage.
{
"affected": [],
"aliases": [
"CVE-2025-69620"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T02:16:10Z",
"severity": "HIGH"
},
"details": "A path traversal in Moo Chan Song v4.5.7 allows attackers to cause a Denial of Service (DoS) via writing files to the internal storage.",
"id": "GHSA-hgpr-8p93-4gqm",
"modified": "2026-02-04T21:30:32Z",
"published": "2026-02-04T03:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69620"
},
{
"type": "WEB",
"url": "https://github.com/Secsys-FDU/AF_CVEs/issues/11"
},
{
"type": "WEB",
"url": "https://secsys.fudan.edu.cn"
},
{
"type": "WEB",
"url": "http://office.com"
},
{
"type": "WEB",
"url": "http://www.ntoolslab.com"
}
],
"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-HGQ9-Q8G2-3JMG
Vulnerability from github – Published: 2022-05-13 01:22 – Updated: 2022-11-01 23:33SPARQL Injection in VIVO Vitro v1.10.0 allows a remote attacker to execute arbitrary SPARQL via the uri parameter, leading to a regular expression denial of service (ReDoS), as demonstrated by crafted use of FILTER%20regex in a /individual?uri= request.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.vivoweb:vitro-project"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-6986"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-77"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-01T23:33:34Z",
"nvd_published_at": "2019-01-28T15:29:00Z",
"severity": "HIGH"
},
"details": "SPARQL Injection in VIVO Vitro v1.10.0 allows a remote attacker to execute arbitrary SPARQL via the uri parameter, leading to a regular expression denial of service (ReDoS), as demonstrated by crafted use of FILTER%20regex in a /individual?uri= request.",
"id": "GHSA-hgq9-q8g2-3jmg",
"modified": "2022-11-01T23:33:34Z",
"published": "2022-05-13T01:22:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6986"
},
{
"type": "WEB",
"url": "https://github.com/vivo-project/Vitro/pull/111"
},
{
"type": "WEB",
"url": "https://github.com/vivo-project/Vitro/pull/111/commits/248ef19107a5ac6f86304fd8f3bc75f3787f8d49"
},
{
"type": "WEB",
"url": "https://github.com/kevinbackhouse/SecurityExploits/tree/0ec74459ac53685a7959ed58d580ef8abece3685/vivo-project"
},
{
"type": "PACKAGE",
"url": "https://github.com/vivo-project/Vitro"
},
{
"type": "WEB",
"url": "https://jira.duraspace.org/browse/VIVO-1697"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/172838/VIVO-SPARQL-Injection.html"
}
],
"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": "Command Injection in VIVO Vitro"
}
GHSA-HGR8-6H9X-F7Q9
Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2024-05-20 21:30Some HTTP/2 implementations are vulnerable to ping floods, potentially leading to a denial of service. The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.
Specific Go Packages Affected
golang.org/x/net/http2
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "golang.org/x/net"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20190813141303-74dc4d7220e7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-9512"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-08T00:30:13Z",
"nvd_published_at": "2019-08-13T21:15:00Z",
"severity": "HIGH"
},
"details": "Some HTTP/2 implementations are vulnerable to ping floods, potentially leading to a denial of service. The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.\n\n### Specific Go Packages Affected\ngolang.org/x/net/http2",
"id": "GHSA-hgr8-6h9x-f7q9",
"modified": "2024-05-20T21:30:32Z",
"published": "2022-05-24T16:53:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9512"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md"
},
{
"type": "WEB",
"url": "https://go.dev/cl/190137"
},
{
"type": "WEB",
"url": "https://go.dev/issue/33606"
},
{
"type": "WEB",
"url": "https://go.googlesource.com/go/+/145e193131eb486077b66009beb051aba07c52a5"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/65QixT3tcmg/m/DrFiG6vvCwAJ"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/605641"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10296"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/392108390cef48af647a2e47b7fd5380e050e35ae8d1aa2030254c04@%3Cusers.trafficserver.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ad3d01e767199c1aed8033bb6b3f5bf98c011c7c536f07a5d34b3c19@%3Cannounce.trafficserver.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/bde52309316ae798186d783a5e29f4ad1527f61c9219a289d0eee0a7@%3Cdev.trafficserver.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00011.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4BBP27PZGSY6OP6D26E5FW4GZKBFHNU7"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4ZQGHE3WTYLYAYJEIDJVF2FIGQTAYPMC"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CMNFX5MNYRWWIMO4BTKYQCGUDMHO3AXP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYO6E3H34C346D2E443GLXK7OK6KIYIQ"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0536"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Aug/24"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Aug/31"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Aug/43"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Sep/18"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190823-0001"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190823-0004"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190823-0005"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K98053339"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K98053339?utm_source=f5support\u0026amp;utm_medium=RSS"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4308-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4503"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4508"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4520"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_19_33"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2594"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2661"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2682"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2690"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2726"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2766"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2769"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2796"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2861"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2925"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2939"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2955"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2966"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3131"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3245"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3265"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3892"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3906"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4018"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4019"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4020"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4021"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4040"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4041"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4042"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4045"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4269"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4273"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:4352"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0406"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0727"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00076.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00002.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00011.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00031.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00032.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00038.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Aug/16"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/08/20/1"
}
],
"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": "golang.org/x/net/http vulnerable to ping floods"
}
GHSA-HGV5-W5QV-CPFG
Vulnerability from github – Published: 2022-01-20 00:00 – Updated: 2026-05-27 15:32Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 11.0.13, 17.01; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
{
"affected": [],
"aliases": [
"CVE-2022-21366"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-19T12:15:00Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 11.0.13, 17.01; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).",
"id": "GHSA-hgv5-w5qv-cpfg",
"modified": "2026-05-27T15:32:50Z",
"published": "2022-01-20T00:00:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21366"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202209-05"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220121-0007"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5057"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5058"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.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-HH27-HF48-9F5Q
Vulnerability from github – Published: 2026-05-27 17:33 – Updated: 2026-07-09 21:06Summary
The date filter's strftime implementation parses width specifiers like %9999999d and forwards the captured width unchecked into pad()/padStart() 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.
Details
date.ts:5-13 only charges memoryLimit for the lengths of the input value, format string, and timezone:
export function date (this: FilterImpl, v: string | Date, format?: string, timezoneOffset?: number | string) {
const size = ((v as string)?.length ?? 0) + (format?.length ?? 0) + ((timezoneOffset as string)?.length ?? 0)
this.context.memoryLimit.use(size)
...
return strftime(date, format)
}
strftime (src/util/strftime.ts:121) then walks the format with rFormat = /%([-_0^#:]+)?(\d+)?([EO])?(.)/. The captured width group is passed directly to padStart:
function format (d, match) {
const [input, flagStr = '', width, modifier, conversion] = match
...
let padWidth = width || padWidths[conversion] || 0
...
return padStart(ret, padWidth, padChar) // strftime.ts:147
}
padStart calls pad() in src/util/underscore.ts:153:
export function pad (str, length, ch, add) {
str = String(str)
let n = length - str.length
while (n-- > 0) str = add(str, ch) // unbounded loop
return str
}
The loop has no upper bound and never consults this.context.memoryLimit or renderLimit. The pad is also implemented as repeated ch + str string concatenation, which makes the per-byte cost grow with output length and amplifies CPU consumption.
Filter arguments accept context-evaluated values (src/template/filter.ts:30-31, evalToken(arg, context)), so any deployment that passes a context value as the date format — a documented and tested usage pattern — exposes the sink to attacker-controlled input.
This is a separate sink from the previously-reported quadratic replace finding: a different filter (date), a different parser (the strftime width regex), and a different concatenation site (pad() in underscore.ts).
PoC
Setup: npm install liquidjs@10.25.7.
Step 1 — bypass memoryLimit and renderLimit (5 MB output, ~200 ms, both limits set to 50):
node -e "
const { Liquid } = require('liquidjs');
const liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 });
const t0 = Date.now();
const out = liquid.parseAndRenderSync('{{ d | date: f }}', { d: 'now', f: '%5000000d' });
console.log('len=', out.length, 'ms=', Date.now()-t0);
"
Verified output: len= 5000000 ms= 198. The memoryLimit:50 (50-byte budget) and renderLimit:50 (50 ms budget) are both ignored.
Step 2 — OOM-kill the Node process under a 200 MB heap cap:
node --max-old-space-size=200 -e "
const { Liquid } = require('liquidjs');
const liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 });
liquid.parseAndRenderSync('{{ d | date: f }}', { d: 'now', f: '%99999999d' });
"
Verified output: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory. Process is killed.
The realistic attack template is {{ post.created_at | date: user_supplied_format }}, where user_supplied_format is any context value an attacker can influence (profile field, query param mapped into template context, etc.).
Impact
- DoS against any LiquidJS-rendered surface where a context value reaches the
datefilter's format argument: a single render call can be turned into multi-MB allocations and seconds of CPU per request, or into an OOM that crashes the host process. - Bypass of the engine's two documented DoS controls —
memoryLimitandrenderLimit— meaning that operators who explicitly opted into DoS protection still have no defense for this code path. - All
date_to_xmlschema,date_to_rfc822,date_to_string,date_to_long_stringpaths share the same sink viastrftime, but with hard-coded formats they're not directly attacker-controllable; the user-facing risk is ondate.
Recommended Fix
Two complementary fixes:
- Have
pad()insrc/util/underscore.tscharge the Context's memory limit and useString.prototype.repeatinstead of an O(n) concatenation loop. Sincepad()is generic, the simplest version takes the memory limit as a parameter:
export function pad (str: any, length: number, ch: string, add: (str: string, ch: string) => string) {
str = String(str)
const n = length - str.length
if (n <= 0) return str
return add === ((s, c) => c + s)
? ch.repeat(n) + str
: str + ch.repeat(n)
}
- Cap
padWidthinsrc/util/strftime.ts:141and account for it viamemoryLimit. Thedatefilter (src/filters/date.ts) should also chargethis.context.memoryLimit.use(parsedMaxWidth)before invokingstrftime, e.g. by scanning the format for%(\d+)widths and summing them. A conservative cap (e.g.Math.min(width, 1024)for non-Nconversions) is also reasonable — strftime widths beyond a few dozen characters have no legitimate use.
Both fixes are needed: the cap stops the OOM crash, the memory accounting restores the documented DoS guarantee.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "liquidjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "10.25.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45357"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T17:33:52Z",
"nvd_published_at": "2026-06-17T23:17:03Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe `date` filter\u0027s strftime implementation parses width specifiers like `%9999999d` and forwards the captured width unchecked into `pad()`/`padStart()` in `src/util/underscore.ts`. The pad loop performs unbounded string concatenation without consulting the Context\u0027s `memoryLimit` or `renderLimit`, so a single small template (`{{ x | date: \u0027%5000000d\u0027 }}`) produces megabytes of output and unbounded CPU. The `memoryLimit` and `renderLimit` options the docs (`src/liquid-options.ts:87-92`) advertise as DoS controls \u2014 and which the docstring explicitly mentions for `strftime` \u2014 are entirely bypassed.\n\n## Details\n\n`date.ts:5-13` only charges `memoryLimit` for the lengths of the input value, format string, and timezone:\n\n```ts\nexport function date (this: FilterImpl, v: string | Date, format?: string, timezoneOffset?: number | string) {\n const size = ((v as string)?.length ?? 0) + (format?.length ?? 0) + ((timezoneOffset as string)?.length ?? 0)\n this.context.memoryLimit.use(size)\n ...\n return strftime(date, format)\n}\n```\n\n`strftime` (`src/util/strftime.ts:121`) then walks the format with `rFormat = /%([-_0^#:]+)?(\\d+)?([EO])?(.)/`. The captured `width` group is passed directly to `padStart`:\n\n```ts\nfunction format (d, match) {\n const [input, flagStr = \u0027\u0027, width, modifier, conversion] = match\n ...\n let padWidth = width || padWidths[conversion] || 0\n ...\n return padStart(ret, padWidth, padChar) // strftime.ts:147\n}\n```\n\n`padStart` calls `pad()` in `src/util/underscore.ts:153`:\n\n```ts\nexport function pad (str, length, ch, add) {\n str = String(str)\n let n = length - str.length\n while (n-- \u003e 0) str = add(str, ch) // unbounded loop\n return str\n}\n```\n\nThe loop has no upper bound and never consults `this.context.memoryLimit` or `renderLimit`. The pad is also implemented as repeated `ch + str` string concatenation, which makes the per-byte cost grow with output length and amplifies CPU consumption.\n\nFilter arguments accept context-evaluated values (`src/template/filter.ts:30-31`, `evalToken(arg, context)`), so any deployment that passes a context value as the date format \u2014 a documented and tested usage pattern \u2014 exposes the sink to attacker-controlled input.\n\nThis is a separate sink from the previously-reported quadratic `replace` finding: a different filter (`date`), a different parser (the strftime width regex), and a different concatenation site (`pad()` in `underscore.ts`).\n\n## PoC\n\nSetup: `npm install liquidjs@10.25.7`.\n\nStep 1 \u2014 bypass `memoryLimit` and `renderLimit` (5 MB output, ~200 ms, both limits set to 50):\n\n```bash\nnode -e \"\nconst { Liquid } = require(\u0027liquidjs\u0027);\nconst liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 });\nconst t0 = Date.now();\nconst out = liquid.parseAndRenderSync(\u0027{{ d | date: f }}\u0027, { d: \u0027now\u0027, f: \u0027%5000000d\u0027 });\nconsole.log(\u0027len=\u0027, out.length, \u0027ms=\u0027, Date.now()-t0);\n\"\n```\n\nVerified output: `len= 5000000 ms= 198`. The `memoryLimit:50` (50-byte budget) and `renderLimit:50` (50 ms budget) are both ignored.\n\nStep 2 \u2014 OOM-kill the Node process under a 200 MB heap cap:\n\n```bash\nnode --max-old-space-size=200 -e \"\nconst { Liquid } = require(\u0027liquidjs\u0027);\nconst liquid = new Liquid({ memoryLimit: 50, renderLimit: 50 });\nliquid.parseAndRenderSync(\u0027{{ d | date: f }}\u0027, { d: \u0027now\u0027, f: \u0027%99999999d\u0027 });\n\"\n```\n\nVerified output: `FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory`. Process is killed.\n\nThe realistic attack template is `{{ post.created_at | date: user_supplied_format }}`, where `user_supplied_format` is any context value an attacker can influence (profile field, query param mapped into template context, etc.).\n\n## Impact\n\n- DoS against any LiquidJS-rendered surface where a context value reaches the `date` filter\u0027s format argument: a single render call can be turned into multi-MB allocations and seconds of CPU per request, or into an OOM that crashes the host process.\n- Bypass of the engine\u0027s two documented DoS controls \u2014 `memoryLimit` and `renderLimit` \u2014 meaning that operators who explicitly opted into DoS protection still have no defense for this code path.\n- All `date_to_xmlschema`, `date_to_rfc822`, `date_to_string`, `date_to_long_string` paths share the same sink via `strftime`, but with hard-coded formats they\u0027re not directly attacker-controllable; the user-facing risk is on `date`.\n\n## Recommended Fix\n\nTwo complementary fixes:\n\n1. Have `pad()` in `src/util/underscore.ts` charge the Context\u0027s memory limit and use `String.prototype.repeat` instead of an O(n) concatenation loop. Since `pad()` is generic, the simplest version takes the memory limit as a parameter:\n\n```ts\nexport function pad (str: any, length: number, ch: string, add: (str: string, ch: string) =\u003e string) {\n str = String(str)\n const n = length - str.length\n if (n \u003c= 0) return str\n return add === ((s, c) =\u003e c + s)\n ? ch.repeat(n) + str\n : str + ch.repeat(n)\n}\n```\n\n2. Cap `padWidth` in `src/util/strftime.ts:141` and account for it via `memoryLimit`. The `date` filter (`src/filters/date.ts`) should also charge `this.context.memoryLimit.use(parsedMaxWidth)` before invoking `strftime`, e.g. by scanning the format for `%(\\d+)` widths and summing them. A conservative cap (e.g. `Math.min(width, 1024)` for non-`N` conversions) is also reasonable \u2014 strftime widths beyond a few dozen characters have no legitimate use.\n\nBoth fixes are needed: the cap stops the OOM crash, the memory accounting restores the documented DoS guarantee.",
"id": "GHSA-hh27-hf48-9f5q",
"modified": "2026-07-09T21:06:30Z",
"published": "2026-05-27T17:33:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-hh27-hf48-9f5q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45357"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/commit/3129d46dc95efa357b00e5a57ee1af80a13d72ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/harttle/liquidjs"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/releases/tag/v10.26.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "LiquidJS has a memory and render limit bypass via unbounded width padding in `date` filter (strftime)"
}
GHSA-HH29-2265-Q6RH
Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15An issue was discovered in Wowza Streaming Engine before 4.7.1. There is a denial of service (memory consumption) via a crafted HTTP request.
{
"affected": [],
"aliases": [
"CVE-2018-7048"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-01T21:29:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Wowza Streaming Engine before 4.7.1. There is a denial of service (memory consumption) via a crafted HTTP request.",
"id": "GHSA-hh29-2265-q6rh",
"modified": "2022-05-13T01:15:05Z",
"published": "2022-05-13T01:15:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7048"
},
{
"type": "WEB",
"url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/main/wowza-streaming-engine/CVE-2018-7048.txt"
},
{
"type": "WEB",
"url": "https://www.wowza.com/docs/wowza-streaming-engine-4-7-1-release-notes"
}
],
"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-HH2W-P6RV-4G7W
Vulnerability from github – Published: 2024-07-09 21:14 – Updated: 2024-07-10 16:09Microsoft Security Advisory CVE-2024-30105 | .NET Denial of Service Vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
A vulnerability exists in .NET when calling the JsonSerializer.DeserializeAsyncEnumerable method against an untrusted input using System.Text.Json may result in Denial of Service.
Discussion
Discussion for this issue can be found at https://github.com/dotnet/runtime/issues/104619
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
- Any .NET 8.0 application running on .NET 8.0.6 or earlier.
Affected Packages
The vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below
.NET 8
| Package name | Affected version | Patched version |
|---|---|---|
| System.Text.Json | >= 7.0.0, < =8.0.3 | 8.0.4 |
Advisory FAQ
How do I know if I am affected?
If you have a runtime or SDK with a version listed, or an affected package listed in affected software or affected packages, you're exposed to the vulnerability.
How do I fix the issue?
- To fix the issue please install the latest version of .NET 8.0 . If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
- If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the
dotnet --infocommand. You will see output like the following;
.NET Core SDK (reflecting any global.json):
Version: 8.0.200
Commit: 8473146e7d
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.300\
Host (useful for support):
Version: 8.0.3
Commit: 8473146e7d
.NET Core SDKs installed:
8.0.200 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspAspNetCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspAspNetCore.App]
Microsoft.AspNetCore.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.WindowsDesktop.App 8.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
- If you're using .NET 8.0, you should download and install .NET 8.0.7 Runtime or .NET 8.0.107 SDK (for Visual Studio 2022 v17.8) from https://dotnet.microsoft.com/download/dotnet-core/8.0.
.NET 8.0 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET 8.0 or .NET 7.0 or .NET 6.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Revisions
V1.0 (July 09, 2024): Advisory published.
Version 1.0
Last Updated 2024-07-09
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "System.Text.Json"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "8.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-30105"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-09T21:14:10Z",
"nvd_published_at": "2024-07-09T17:15:17Z",
"severity": "HIGH"
},
"details": "# Microsoft Security Advisory CVE-2024-30105 | .NET Denial of Service Vulnerability\n\n## \u003ca name=\"executive-summary\"\u003e\u003c/a\u003eExecutive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA vulnerability exists in .NET when calling the JsonSerializer.DeserializeAsyncEnumerable method against an untrusted input using System.Text.Json may result in Denial of Service.\n\n## Discussion\n\nDiscussion for this issue can be found at https://github.com/dotnet/runtime/issues/104619\n\n## \u003ca name=\"mitigation-factors\"\u003e\u003c/a\u003eMitigation factors\n\nMicrosoft has not identified any mitigating factors for this vulnerability.\n\n## \u003ca name=\"affected-software\"\u003e\u003c/a\u003eAffected software\n\n* Any .NET 8.0 application running on .NET 8.0.6 or earlier.\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\nThe vulnerability affects any Microsoft .NET Core project if it uses any of affected packages versions listed below\n\n### \u003ca name=\".NET 8\"\u003e\u003c/a\u003e.NET 8\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Text.Json](https://www.nuget.org/packages/System.Text.Json) | \u003e= 7.0.0, \u003c =8.0.3 | 8.0.4\n\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf you have a runtime or SDK with a version listed, or an affected package listed in [affected software](#affected-packages) or [affected packages](#affected-software), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n* To fix the issue please install the latest version of .NET 8.0 . If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.\n* If you have .NET 6.0 or greater installed, you can list the versions you have installed by running the `dotnet --info` command. You will see output like the following;\n\n```\n.NET Core SDK (reflecting any global.json):\n\n\n Version: 8.0.200\n Commit: 8473146e7d\n\nRuntime Environment:\n\n OS Name: Windows\n OS Version: 10.0.18363\n OS Platform: Windows\n RID: win10-x64\n Base Path: C:\\Program Files\\dotnet\\sdk\\6.0.300\\\n\nHost (useful for support):\n\n Version: 8.0.3\n Commit: 8473146e7d\n\n.NET Core SDKs installed:\n\n 8.0.200 [C:\\Program Files\\dotnet\\sdk]\n\n.NET Core runtimes installed:\n\n Microsoft.AspAspNetCore.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspAspNetCore.App]\n Microsoft.AspNetCore.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.AspNetCore.App]\n Microsoft.WindowsDesktop.App 8.0.3 [C:\\Program Files\\dotnet\\shared\\Microsoft.WindowsDesktop.App]\n\n\nTo install additional .NET Core runtimes or SDKs:\n https://aka.ms/dotnet-download\n```\n\n* If you\u0027re using .NET 8.0, you should download and install .NET 8.0.7 Runtime or .NET 8.0.107 SDK (for Visual Studio 2022 v17.8) from https://dotnet.microsoft.com/download/dotnet-core/8.0.\n\n.NET 8.0 updates are also available from Microsoft Update. To access this either type \"Check for updates\" in your Windows search, or open Settings, choose Update \u0026 Security and then click Check for Updates.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in .NET 8.0 or .NET 7.0 or .NET 6.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core \u0026 .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at \u003chttps://aka.ms/corebounty\u003e.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/aspnet/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2024-30105]( https://www.cve.org/CVERecord?id=CVE-2024-30105)\n\n### Revisions\n\nV1.0 (July 09, 2024): Advisory published.\n\n_Version 1.0_\n\n_Last Updated 2024-07-09_",
"id": "GHSA-hh2w-p6rv-4g7w",
"modified": "2024-07-10T16:09:24Z",
"published": "2024-07-09T21:14:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/runtime/security/advisories/GHSA-hh2w-p6rv-4g7w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30105"
},
{
"type": "PACKAGE",
"url": "https://github.com/dotnet/runtime"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30105"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Microsoft Security Advisory CVE-2024-30105 | .NET Denial of Service Vulnerability"
}
GHSA-HH3J-9M59-P8VC
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-04-15 19:35In bentoml/bentoml version 1.3.9, the /login endpoint of the newly integrated Gradio app is vulnerable to a Denial of Service (DoS) attack. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "bentoml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.3.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T17:52:01Z",
"nvd_published_at": "2025-03-20T10:15:29Z",
"severity": "HIGH"
},
"details": "In bentoml/bentoml version 1.3.9, the `/login` endpoint of the newly integrated Gradio app is vulnerable to a Denial of Service (DoS) attack. This vulnerability can be exploited by appending characters, such as dashes (-), to the end of a multipart boundary in an HTTP request. The server continuously processes each character, leading to excessive resource consumption and rendering the service unavailable. The issue is unauthenticated and does not require any user interaction.",
"id": "GHSA-hh3j-9m59-p8vc",
"modified": "2025-04-15T19:35:08Z",
"published": "2025-03-20T12:32:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8966"
},
{
"type": "PACKAGE",
"url": "https://github.com/bentoml/BentoML"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/7b5932bb-58d1-4e71-b85c-43dc40522ff2"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/e467ec92-0ad1-4461-8468-1beabf701b9f"
}
],
"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": "BentoML vulnerable to Uncontrolled Resource Consumption"
}
GHSA-HHFG-6HFC-RVXM
Vulnerability from github – Published: 2021-09-29 17:15 – Updated: 2022-05-04 03:39JSON Editor is a web-based tool to view, edit, format, and validate JSON. It has various modes such as a tree editor, a code editor, and a plain text editor. The jsoneditor package is vulnerable to ReDoS (regular expression denial of service). An attacker that is able to provide a crafted element as input to the getInnerText function may cause an application to consume an excessive amount of CPU. Below pinned line using vulnerable regex.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsoneditor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.5.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-3822"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400",
"CWE-697"
],
"github_reviewed": true,
"github_reviewed_at": "2021-09-28T20:52:54Z",
"nvd_published_at": "2021-09-27T13:15:00Z",
"severity": "MODERATE"
},
"details": "JSON Editor is a web-based tool to view, edit, format, and validate JSON. It has various modes such as a tree editor, a code editor, and a plain text editor. The jsoneditor package is vulnerable to ReDoS (regular expression denial of service). An attacker that is able to provide a crafted element as input to the getInnerText function may cause an application to consume an excessive amount of CPU. Below pinned line using vulnerable regex.",
"id": "GHSA-hhfg-6hfc-rvxm",
"modified": "2022-05-04T03:39:38Z",
"published": "2021-09-29T17:15:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3822"
},
{
"type": "WEB",
"url": "https://github.com/josdejong/jsoneditor/commit/092e386cf49f2a1450625617da8e0137ed067c3e"
},
{
"type": "PACKAGE",
"url": "https://github.com/josdejong/jsoneditor"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/1e3ed803-b7ed-42f1-a4ea-c4c75da9de73"
}
],
"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": "Regular Expression Denial of Service in jsoneditor"
}
GHSA-HHHV-Q57G-882Q
Vulnerability from github – Published: 2024-03-07 17:40 – Updated: 2024-03-30 06:30A vulnerability has been identified in the JSON Web Encryption (JWE) decryption interfaces, specifically related to the support for decompressing plaintext after its decryption. This allows an adversary to exploit specific scenarios where the compression ratio becomes exceptionally high. As a result, the length of the JWE token, which is determined by the compressed content's size, can land below application-defined limits. In such cases, other existing application level mechanisms for preventing resource exhaustion may be rendered ineffective.
Note that as per RFC 8725 compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. For this reason the v5.x major version of jose removed support for compressed payloads entirely and is therefore NOT affected by this advisory.
Impact
Under certain conditions it is possible to have the user's environment consume unreasonable amount of CPU time or memory during JWE Decryption operations.
Affected users
The impact is limited only to Node.js users utilizing the JWE decryption APIs to decrypt JWEs from untrusted sources.
You are NOT affected if any of the following applies to you
- Your code uses jose version v5.x where JWE Compression is not supported anymore
- Your code runs in an environment other than Node.js (e.g. Deno, CF Workers), which is the only runtime where JWE Compression is implemented out of the box
- Your code does not use the JWE decryption APIs
- Your code only accepts JWEs produced by trusted sources
Patches
v2.0.7 and v4.15.5 releases limit the decompression routine to only allow decompressing up to 250 kB of plaintext. In v4.x it is possible to further adjust this limit via the inflateRaw decryption option implementation. In v2.x it is possible to further adjust this limit via the inflateRawSyncLimit decryption option.
Workarounds
If you cannot upgrade and do not want to support compressed JWEs you may detect and reject these tokens early by checking the token's protected header
const { zip } = jose.decodeProtectedHeader(token)
if (zip !== undefined) {
throw new Error('JWE Compression is not supported')
}
If you wish to continue supporting JWEs with compressed payloads in these legacy release lines you must upgrade (v1.x and v2.x to version v2.0.7, v3.x and v4.x to version v4.15.5) and review the limits put forth by the patched releases.
For more information
If you have any questions or comments about this advisory please open a discussion in the project's repository
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.15.4"
},
"package": {
"ecosystem": "npm",
"name": "jose"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.15.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.15.4"
},
"package": {
"ecosystem": "npm",
"name": "jose-node-cjs-runtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.15.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.15.4"
},
"package": {
"ecosystem": "npm",
"name": "jose-node-esm-runtime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.15.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "jose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28176"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-07T17:40:57Z",
"nvd_published_at": "2024-03-09T01:15:07Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been identified in the JSON Web Encryption (JWE) decryption interfaces, specifically related to the [support for decompressing plaintext after its decryption](https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.3). This allows an adversary to exploit specific scenarios where the compression ratio becomes exceptionally high. As a result, the length of the JWE token, which is determined by the compressed content\u0027s size, can land below application-defined limits. In such cases, other existing application level mechanisms for preventing resource exhaustion may be rendered ineffective.\n\nNote that as per [RFC 8725](https://www.rfc-editor.org/rfc/rfc8725.html#name-avoid-compression-of-encryp) compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. For this reason the v5.x major version of `jose` removed support for compressed payloads entirely and is therefore NOT affected by this advisory.\n\n### Impact\n\nUnder certain conditions it is possible to have the user\u0027s environment consume unreasonable amount of CPU time or memory during JWE Decryption operations.\n\n### Affected users\n\nThe impact is limited only to Node.js users utilizing the JWE decryption APIs to decrypt JWEs from untrusted sources.\n\nYou are NOT affected if any of the following applies to you\n\n- Your code uses jose version v5.x where JWE Compression is not supported anymore\n- Your code runs in an environment other than Node.js (e.g. Deno, CF Workers), which is the only runtime where JWE Compression is implemented out of the box\n- Your code does not use the JWE decryption APIs\n- Your code only accepts JWEs produced by trusted sources\n\n### Patches\n\n`v2.0.7` and `v4.15.5` releases limit the decompression routine to only allow decompressing up to 250 kB of plaintext. In v4.x it is possible to further adjust this limit via the `inflateRaw` decryption option implementation. In v2.x it is possible to further adjust this limit via the `inflateRawSyncLimit` decryption option.\n\n### Workarounds\n\nIf you cannot upgrade and do not want to support compressed JWEs you may detect and reject these tokens early by checking the token\u0027s protected header\n\n```js\nconst { zip } = jose.decodeProtectedHeader(token)\nif (zip !== undefined) {\n throw new Error(\u0027JWE Compression is not supported\u0027)\n}\n```\n\nIf you wish to continue supporting JWEs with compressed payloads in these legacy release lines you must upgrade (v1.x and v2.x to version v2.0.7, v3.x and v4.x to version v4.15.5) and review the limits put forth by the patched releases.\n\n### For more information\nIf you have any questions or comments about this advisory please open a discussion in the project\u0027s [repository](https://github.com/panva/jose/discussions/new?category=q-a\u0026title=GHSA-hhhv-q57g-882q%20advisory%20question)",
"id": "GHSA-hhhv-q57g-882q",
"modified": "2024-03-30T06:30:42Z",
"published": "2024-03-07T17:40:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/panva/jose/security/advisories/GHSA-hhhv-q57g-882q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28176"
},
{
"type": "WEB",
"url": "https://github.com/panva/jose/commit/02a65794f7873cdaf12e81e80ad076fcdc4a9314"
},
{
"type": "WEB",
"url": "https://github.com/panva/jose/commit/1b91d88d2f8233f3477a5f4579aa5f8057b2ee8b"
},
{
"type": "PACKAGE",
"url": "https://github.com/panva/jose"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I6MMWFBOXJA6ZCXNVPDFJ4XMK5PVG5RG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KXKGNCRU7OTM5AHC7YIYBNOWI742PRMY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UG5FSEYJ3GP27FZXC5YAAMMEC5XWKJHG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UJO2U5ACZVACNQXJ5EBRFLFW6DP5BROY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XJDO5VSIAOGT2WP63AXAAWNRSVJCNCRH"
}
],
"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": "jose vulnerable to resource exhaustion via specifically crafted JWE with compressed plaintext"
}
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.