CWE-835
AllowedLoop with Unreachable Exit Condition ('Infinite Loop')
Abstraction: Base · Status: Incomplete
The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
1253 vulnerabilities reference this CWE, most recent first.
GHSA-M6XR-FVFG-5G64
Vulnerability from github – Published: 2026-05-19 20:09 – Updated: 2026-05-19 20:09Summary
dasel's selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as r/abc. A 2-byte input (r/) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.
I confirmed the issue on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on master commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. I also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). No fix is available yet.
Details
The bug is in the matchRegexPattern closure within (*Tokenizer).parseCurRune in selector/lexer/tokenize.go#L237-L247:
matchRegexPattern := func(pos int) *Token {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil
}
start := pos
pos += 2
for !p.peekRuneEqual(pos, '/') { // line 243
pos++
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))
}
When no closing / exists, peekRuneEqual returns false when pos >= srcLen (because the bounds check at line 40 returns false for out-of-range positions). Since !false = true, the loop condition remains true and pos increments indefinitely. The function never returns.
Notably, the same function already handles unterminated quoted strings by returning UnexpectedEOFError, but the regex pattern path does not perform a similar end-of-input check.
Minimal trigger: r/ (2 bytes)
Test environment:
- MacBook Air (Apple M2), macOS / Darwin
arm64 - Go
1.26.1 - dasel
v3.3.1(fba653c7f248aff10f2b89fca93929b64707dfc8)
PoC
package main
import (
"fmt"
"runtime"
"time"
"github.com/tomwright/dasel/v3/selector/lexer"
)
func main() {
fmt.Printf("Go version: %s\n", runtime.Version())
fmt.Printf("GOARCH: %s\n", runtime.GOARCH)
fmt.Println()
for _, input := range []string{"r/unterminated", "r/"} {
fmt.Printf("Input: %s\n", input)
done := make(chan string, 1)
go func() {
t := lexer.NewTokenizer(input)
start := time.Now()
tokens, err := t.Tokenize()
elapsed := time.Since(start)
if err != nil {
done <- fmt.Sprintf("Error after %v: %v", elapsed, err)
} else {
done <- fmt.Sprintf("OK after %v: %d tokens", elapsed, len(tokens))
}
}()
select {
case result := <-done:
fmt.Println(result)
case <-time.After(5 * time.Second):
fmt.Println("CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop")
}
fmt.Println()
}
}
Observed output on v3.3.1 in the test environment above:
Go version: go1.26.1
GOARCH: arm64
Input: r/unterminated
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Input: r/
CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop
Impact
An attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.
The selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced: - Web applications using dasel for dynamic data querying - Applications that construct selectors from user input - Shared tooling environments where selectors are passed as parameters
Suggested Fix
The regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since matchRegexPattern currently returns *Token, the fix also requires changing the function signature to propagate errors. For example:
matchRegexPattern := func(pos int) (*Token, error) {
if p.src[pos] != 'r' || !p.peekRuneEqual(pos+1, '/') {
return nil, nil
}
start := pos
pos += 2
for pos < p.srcLen && p.src[pos] != '/' {
pos++
}
if pos >= p.srcLen {
return nil, &UnexpectedEOFError{Pos: pos}
}
pos++
return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil
}
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tomwright/dasel/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46378"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:09:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`dasel`\u0027s selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as `r/abc`. A 2-byte input (`r/`) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely.\n\nI confirmed the issue on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on `master` commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. I also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). No fix is available yet.\n\n### Details\n\nThe bug is in the `matchRegexPattern` closure within `(*Tokenizer).parseCurRune` in [`selector/lexer/tokenize.go#L237-L247`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L237-L247):\n\n```go\nmatchRegexPattern := func(pos int) *Token {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil\n }\n start := pos\n pos += 2\n for !p.peekRuneEqual(pos, \u0027/\u0027) { // line 243\n pos++\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start))\n}\n```\n\nWhen no closing `/` exists, [`peekRuneEqual`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/selector/lexer/tokenize.go#L39-L43) returns `false` when `pos \u003e= srcLen` (because the bounds check at line 40 returns `false` for out-of-range positions). Since `!false = true`, the loop condition remains true and `pos` increments indefinitely. The function never returns.\n\nNotably, the same function already handles unterminated quoted strings by returning `UnexpectedEOFError`, but the regex pattern path does not perform a similar end-of-input check.\n\nMinimal trigger: `r/` (2 bytes)\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS / Darwin `arm64`\n- Go `1.26.1`\n- dasel `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`)\n\n### PoC\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\t\"runtime\"\n\t\"time\"\n\n\t\"github.com/tomwright/dasel/v3/selector/lexer\"\n)\n\nfunc main() {\n\tfmt.Printf(\"Go version: %s\\n\", runtime.Version())\n\tfmt.Printf(\"GOARCH: %s\\n\", runtime.GOARCH)\n\tfmt.Println()\n\n\tfor _, input := range []string{\"r/unterminated\", \"r/\"} {\n\t\tfmt.Printf(\"Input: %s\\n\", input)\n\t\tdone := make(chan string, 1)\n\t\tgo func() {\n\t\t\tt := lexer.NewTokenizer(input)\n\t\t\tstart := time.Now()\n\t\t\ttokens, err := t.Tokenize()\n\t\t\telapsed := time.Since(start)\n\t\t\tif err != nil {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"Error after %v: %v\", elapsed, err)\n\t\t\t} else {\n\t\t\t\tdone \u003c- fmt.Sprintf(\"OK after %v: %d tokens\", elapsed, len(tokens))\n\t\t\t}\n\t\t}()\n\n\t\tselect {\n\t\tcase result := \u003c-done:\n\t\t\tfmt.Println(result)\n\t\tcase \u003c-time.After(5 * time.Second):\n\t\t\tfmt.Println(\"CONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\")\n\t\t}\n\t\tfmt.Println()\n\t}\n}\n```\n\nObserved output on `v3.3.1` in the test environment above:\n\n```text\nGo version: go1.26.1\nGOARCH: arm64\n\nInput: r/unterminated\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n\nInput: r/\nCONFIRMED: did not complete within 5s; tokenizer is stuck in non-terminating loop\n```\n\n### Impact\n\nAn attacker who can control or influence the selector/query string passed to dasel can cause the tokenizer to enter a non-terminating loop. The affected process consumes 100% CPU on one core and does not make progress until externally terminated.\n\nThe selector string is typically provided by the application developer, but there are deployment scenarios where it may be attacker-influenced:\n- Web applications using dasel for dynamic data querying\n- Applications that construct selectors from user input\n- Shared tooling environments where selectors are passed as parameters\n\n### Suggested Fix\n\nThe regex scanner should bounds-check and return an error on unterminated regex literals, consistent with unterminated quoted strings. Since `matchRegexPattern` currently returns `*Token`, the fix also requires changing the function signature to propagate errors. For example:\n\n```go\nmatchRegexPattern := func(pos int) (*Token, error) {\n if p.src[pos] != \u0027r\u0027 || !p.peekRuneEqual(pos+1, \u0027/\u0027) {\n return nil, nil\n }\n start := pos\n pos += 2\n for pos \u003c p.srcLen \u0026\u0026 p.src[pos] != \u0027/\u0027 {\n pos++\n }\n if pos \u003e= p.srcLen {\n return nil, \u0026UnexpectedEOFError{Pos: pos}\n }\n pos++\n return ptr.To(NewToken(RegexPattern, p.src[start+2:pos-1], start, pos-start)), nil\n}\n```",
"id": "GHSA-m6xr-fvfg-5g64",
"modified": "2026-05-19T20:09:21Z",
"published": "2026-05-19T20:09:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/security/advisories/GHSA-m6xr-fvfg-5g64"
},
{
"type": "WEB",
"url": "https://github.com/TomWright/dasel/commit/95f8dd3af12958bf6ca2a737b3ec0267280f86ed"
},
{
"type": "PACKAGE",
"url": "https://github.com/TomWright/dasel"
}
],
"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": "Dasel: Denial of service in dasel selector lexer due to infinite loop on unterminated regex literal"
}
GHSA-M72M-MHQ2-9P6C
Vulnerability from github – Published: 2021-08-23 19:42 – Updated: 2022-02-08 20:59Impact
What kind of vulnerability is it? Who is impacted? Those using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.
Patches
Has the problem been patched? What versions should users upgrade to? Users should upgrade to jsoup 1.14.2
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading? Users may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jsoup:jsoup"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-37714"
],
"database_specific": {
"cwe_ids": [
"CWE-248",
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-08-23T17:20:30Z",
"nvd_published_at": "2021-08-18T15:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\nThose using jsoup to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\nUsers should upgrade to jsoup 1.14.2\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\nUsers may rate limit input parsing. Users should limit the size of inputs based on system resources. Users should implement thread watchdogs to cap and timeout parse runtimes.\n",
"id": "GHSA-m72m-mhq2-9p6c",
"modified": "2022-02-08T20:59:16Z",
"published": "2021-08-23T19:42:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37714"
},
{
"type": "PACKAGE",
"url": "https://github.com/jhy/jsoup"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.1"
},
{
"type": "WEB",
"url": "https://jsoup.org/news/release-1.14.2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215009dbf7467a9f6506d0c0024cb36cad30071010e62c9352cfaaf0@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r377b93d79817ce649e9e68b3456e6f499747ef1643fa987b342e082e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3d71f18adb78e50f626dde689161ca63d3b7491bd9718fcddfaecba7@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r50e9c9466c592ca9d707a5dea549524d19e3287da08d8392f643960e@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r685c5235235ad0c26e86d0ee987fb802c9675de6081dbf0516464e0b@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r97404676a5cf591988faedb887d64e278f522adcaa823d89ca69defe@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc3354080fc67fb50b45b3c2d12dc4ca2a3c1c78dad3d3ba012c038aa@%3Cnotifications.james.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0022"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.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:H",
"type": "CVSS_V3"
}
],
"summary": "Uncaught Exception in jsoup"
}
GHSA-M73F-CF56-RF2W
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.
{
"affected": [],
"aliases": [
"CVE-2017-18277"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-23T13:29:00Z",
"severity": "MODERATE"
},
"details": "When dynamic memory allocation fails, currently the process sleeps for one second and continues with infinite loop without retrying for memory allocation in Snapdragon Automobile, Snapdragon Mobile, Snapdragon Wear in version MDM9206, MDM9607, MDM9640, MDM9650, MSM8909W, QCN5502, SD 210/SD 212/SD 205, SD 425, SD 430, SD 450, SD 600, SD 615/16/SD 415, SD 625, SD 650/52, SD 810, SD 820, SD 820A, SD 835.",
"id": "GHSA-m73f-cf56-rf2w",
"modified": "2022-05-13T01:44:38Z",
"published": "2022-05-13T01:44:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18277"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-07-01#qualcomm-closed-source-components"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M7FP-H3P4-HR49
Vulnerability from github – Published: 2026-09-03 17:45 – Updated: 2026-09-03 17:45Summary
The current implementation of strip_html can cause an infinite loop when the input string contains <, has at least one character before <, and no > appears after <.
Details
The problem is in src/filters/html.ts.
Specifically, the following part has the infinite loop.
// Raw-text blocks (HTML5) plus '<...>' as the catch-all kind; a regex
// equivalent is O(n^2) in V8 on unclosed openers.
export function strip_html (this: FilterImpl, v: string) {
const str = stringify(v)
this.context.memoryLimit.use(str.length)
const blocks = new Map([['<script', '</script>'], ['<style', '</style>'], ['<!--', '-->'], ['<', '>']])
let out = ''
let i = 0
while (i < str.length) {
const lt = str.indexOf('<', i)
if (lt < 0) return out + str.slice(i)
out += str.slice(i, lt)
for (const [opener, closer] of blocks) {
if (!str.startsWith(opener, lt)) continue
const e = str.indexOf(closer, lt + opener.length)
if (e >= 0) { i = e + closer.length; break }
blocks.delete(opener)
}
if (i === lt) return out + str.slice(lt)
}
return out
}
For the input "a<", the variable lt is updated to 1 by const lt = str.indexOf('<', i). However, the variable i is never updated from its initial value of 0. This is because in const e = str.indexOf(closer, lt + opener.length), e becomes -1, since there is no > after <. Therefore, when execution reaches if (i === lt) return out + str.slice(lt), i is 0. This is the same state as at the beginning of the loop. As a result, the same thing is repeated again from that state, causing an infinite loop.
PoC
const { Liquid } = require('liquidjs');
const engine = new Liquid();
engine.parseAndRender('{{ html | strip_html }}', {
html: 'a<'
}).then(console.log);
console.log("This is never displayed.");
Impact
This is an infinite loop vulnerability (cf. https://cwe.mitre.org/data/definitions/835.html). This results in a denial of service (DoS). Although a ReDoS vulnerability has previously been reported in the affected function (cf. https://github.com/harttle/liquidjs/security/advisories/GHSA-r7g9-xpmj-5fcq), this issue can cause a more severe impact than that ReDoS vulnerability with an input of only two characters at minimum.
Recommended Fix
There is an issue with the following conditional branch.
if (i === lt) return out + str.slice(lt);
The following should fix the issue.
if (i <= lt) return out + str.slice(lt);
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "liquidjs"
},
"ranges": [
{
"events": [
{
"introduced": "10.26.0"
},
{
"fixed": "10.27.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61556"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T17:45:26Z",
"nvd_published_at": "2026-08-19T21:17:03Z",
"severity": "HIGH"
},
"details": "### Summary\nThe current implementation of `strip_html` can cause an infinite loop when the input string contains `\u003c`, has at least one character before `\u003c`, and no `\u003e` appears after `\u003c`.\n\n### Details\nThe problem is in `src/filters/html.ts`.\nSpecifically, the following part has the infinite loop.\n\n```\n// Raw-text blocks (HTML5) plus \u0027\u003c...\u003e\u0027 as the catch-all kind; a regex\n// equivalent is O(n^2) in V8 on unclosed openers.\nexport function strip_html (this: FilterImpl, v: string) {\n const str = stringify(v)\n this.context.memoryLimit.use(str.length)\n const blocks = new Map([[\u0027\u003cscript\u0027, \u0027\u003c/script\u003e\u0027], [\u0027\u003cstyle\u0027, \u0027\u003c/style\u003e\u0027], [\u0027\u003c!--\u0027, \u0027--\u003e\u0027], [\u0027\u003c\u0027, \u0027\u003e\u0027]])\n let out = \u0027\u0027\n let i = 0\n while (i \u003c str.length) {\n const lt = str.indexOf(\u0027\u003c\u0027, i)\n if (lt \u003c 0) return out + str.slice(i)\n out += str.slice(i, lt)\n for (const [opener, closer] of blocks) {\n if (!str.startsWith(opener, lt)) continue\n const e = str.indexOf(closer, lt + opener.length)\n if (e \u003e= 0) { i = e + closer.length; break }\n blocks.delete(opener)\n }\n if (i === lt) return out + str.slice(lt)\n }\n return out\n}\n```\n\nFor the input \"a\u003c\", the variable `lt` is updated to 1 by `const lt = str.indexOf(\u0027\u003c\u0027, i)`. However, the variable `i` is never updated from its initial value of 0. This is because in `const e = str.indexOf(closer, lt + opener.length)`, `e` becomes -1, since there is no \u003e after \u003c. Therefore, when execution reaches `if (i === lt) return out + str.slice(lt)`, `i` is 0. This is the same state as at the beginning of the loop. As a result, the same thing is repeated again from that state, causing an infinite loop.\n\n\n### PoC\n```\nconst { Liquid } = require(\u0027liquidjs\u0027);\n\nconst engine = new Liquid();\n\nengine.parseAndRender(\u0027{{ html | strip_html }}\u0027, {\n html: \u0027a\u003c\u0027\n}).then(console.log);\n\nconsole.log(\"This is never displayed.\");\n```\n\n### Impact\nThis is an infinite loop vulnerability (cf. https://cwe.mitre.org/data/definitions/835.html). This results in a denial of service (DoS). Although a ReDoS vulnerability has previously been reported in the affected function (cf. https://github.com/harttle/liquidjs/security/advisories/GHSA-r7g9-xpmj-5fcq), this issue can cause a more severe impact than that ReDoS vulnerability with an input of only two characters at minimum.\n\n### Recommended Fix\nThere is an issue with the following conditional branch.\n\n```\nif (i === lt) return out + str.slice(lt);\n```\n\nThe following should fix the issue.\n\n```\nif (i \u003c= lt) return out + str.slice(lt);\n```",
"id": "GHSA-m7fp-h3p4-hr49",
"modified": "2026-09-03T17:45:26Z",
"published": "2026-09-03T17:45:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-m7fp-h3p4-hr49"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61556"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/pull/917"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/commit/5c3522f33928aae66f0fe85c36e1d9015c768fe2"
},
{
"type": "PACKAGE",
"url": "https://github.com/harttle/liquidjs"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/releases/tag/v10.27.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "LiquidJS has an infinite loop vulnerability in its `strip_html` filter"
}
GHSA-M7JV-HQ7H-MQ7C
Vulnerability from github – Published: 2022-02-08 22:05 – Updated: 2026-08-25 18:31The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0-M1"
},
{
"fixed": "10.0.0-M7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-websocket"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.27"
},
{
"fixed": "7.0.105"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-13935"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-12T18:44:47Z",
"nvd_published_at": "2020-07-14T15:15:00Z",
"severity": "HIGH"
},
"details": "The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.",
"id": "GHSA-m7jv-hq7h-mq7c",
"modified": "2026-08-25T18:31:30Z",
"published": "2022-02-08T22:05:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13935"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/12d715676038efbf9c728af10163f8277fc019d5"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/1c1c77b0efb667cea80b532440b44cea1dc427c3"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/40fa74c74822711ab878079d0a69f7357926723d"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/4c04982870d6e730c38e21e58fb653b7cf723784"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/f9f75c14678b68633f79030ddf4ff827f014cc84"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4448-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4596-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2020/dsa-4727"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-8.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-7.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20200724-0003"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/07/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd48c72bd3255bda87564d4da3791517c074d94f8a701f93b85752651%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4e5d3c09f4dd2923191e972408b40fb8b42dbff0bc7904d44b651e50@%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4e5d3c09f4dd2923191e972408b40fb8b42dbff0bc7904d44b651e50%40%3Cusers.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10332"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00084.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00088.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:H",
"type": "CVSS_V3"
}
],
"summary": "Infinite Loop in Apache Tomcat"
}
GHSA-M7R8-8QC5-J4JF
Vulnerability from github – Published: 2026-07-23 12:32 – Updated: 2026-08-19 15:31A flaw was found in libcupsfilters. The cfIEEE1284NormalizeMakeModel() function enters an infinite loop when processing a printer-advertised IEEE-1284 device ID with an empty model field, causing sustained CPU consumption. A network-adjacent attacker could exploit this by broadcasting a specially crafted printer advertisement, leading to denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-64611"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T11:16:40Z",
"severity": "HIGH"
},
"details": "A flaw was found in libcupsfilters. The cfIEEE1284NormalizeMakeModel() function enters an infinite loop when processing a printer-advertised IEEE-1284 device ID with an empty model field, causing sustained CPU consumption. A network-adjacent attacker could exploit this by broadcasting a specially crafted printer advertisement, leading to denial of service.",
"id": "GHSA-m7r8-8qc5-j4jf",
"modified": "2026-08-19T15:31:58Z",
"published": "2026-07-23T12:32:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenPrinting/libcupsfilters/security/advisories/GHSA-rcq7-rv5g-j3r4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56965"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-64611"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502799"
}
],
"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-M842-HM2C-8XM2
Vulnerability from github – Published: 2025-08-14 18:31 – Updated: 2025-08-14 18:31A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.
This vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.
{
"affected": [],
"aliases": [
"CVE-2025-20253"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T17:15:38Z",
"severity": "HIGH"
},
"details": "A vulnerability in the IKEv2 feature of Cisco IOS Software, IOS XE Software, Secure Firewall ASA Software, and Secure FTD Software could allow an unauthenticated, remote attacker to cause the device to reload, resulting in a DoS condition.\n\nThis vulnerability is due to the improper processing of IKEv2 packets. An attacker could exploit this vulnerability by sending crafted IKEv2 packets to an affected device. A successful exploit could allow the attacker to cause an infinite loop that exhausts resources and could cause the device to reload.",
"id": "GHSA-m842-hm2c-8xm2",
"modified": "2025-08-14T18:31:30Z",
"published": "2025-08-14T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20253"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-ios-dos-DOESHWHy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M89X-HF4G-3J36
Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. When an unsupported TCP option with zero length is provided in an incoming TCP packet, it is possible to cause a Denial-of-Service by achieving an infinite loop in the code that parses TCP options, aka tcp_parse_options() in pico_tcp.c.
{
"affected": [],
"aliases": [
"CVE-2020-24337"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-11T23:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in picoTCP and picoTCP-NG through 1.7.0. When an unsupported TCP option with zero length is provided in an incoming TCP packet, it is possible to cause a Denial-of-Service by achieving an infinite loop in the code that parses TCP options, aka tcp_parse_options() in pico_tcp.c.",
"id": "GHSA-m89x-hf4g-3j36",
"modified": "2022-05-24T17:36:11Z",
"published": "2022-05-24T17:36:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24337"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-343-01"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/815128"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-M8P7-HJG2-3XQJ
Vulnerability from github – Published: 2026-02-04 18:30 – Updated: 2026-04-18 09:30In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error
In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"), the URB was re-anchored before usb_submit_urb() in gs_usb_receive_bulk_callback() to prevent a leak of this URB during cleanup.
However, this patch did not take into account that usb_submit_urb() could fail. The URB remains anchored and usb_kill_anchored_urbs(&parent->rx_submitted) in gs_can_close() loops infinitely since the anchor list never becomes empty.
To fix the bug, unanchor the URB when an usb_submit_urb() error occurs, also print an info message.
{
"affected": [],
"aliases": [
"CVE-2026-23082"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-04T17:16:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error\n\nIn commit 7352e1d5932a (\"can: gs_usb: gs_usb_receive_bulk_callback(): fix\nURB memory leak\"), the URB was re-anchored before usb_submit_urb() in\ngs_usb_receive_bulk_callback() to prevent a leak of this URB during\ncleanup.\n\nHowever, this patch did not take into account that usb_submit_urb() could\nfail. The URB remains anchored and\nusb_kill_anchored_urbs(\u0026parent-\u003erx_submitted) in gs_can_close() loops\ninfinitely since the anchor list never becomes empty.\n\nTo fix the bug, unanchor the URB when an usb_submit_urb() error occurs,\nalso print an info message.",
"id": "GHSA-m8p7-hjg2-3xqj",
"modified": "2026-04-18T09:30:17Z",
"published": "2026-02-04T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23082"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/79a6d1bfe1148bc921b8d7f3371a7fbce44e30f7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aa8a8866c533a150be4763bcb27993603bd5426c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c3edc14da81a8d8398682f6e4ab819f09f37c0b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c610b550ccc0438d456dfe1df9f4f36254ccaae3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ce4352057fc5a986c76ece90801b9755e7c6e56c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/da01de754e455e2598a7f1ce4ff2078c4f0ecde1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M9V3-PQJ8-J8X7
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07The intel_hda_xfer function in hw/audio/intel-hda.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and CPU consumption) via an entry with the same value for buffer length and pointer position.
{
"affected": [],
"aliases": [
"CVE-2016-8909"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-11-04T21:59:00Z",
"severity": "MODERATE"
},
"details": "The intel_hda_xfer function in hw/audio/intel-hda.c in QEMU (aka Quick Emulator) allows local guest OS administrators to cause a denial of service (infinite loop and CPU consumption) via an entry with the same value for buffer length and pointer position.",
"id": "GHSA-m9v3-pqj8-j8x7",
"modified": "2022-05-13T01:07:30Z",
"published": "2022-05-13T01:07:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8909"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2392"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2408"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2016-8909"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1388052"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/11/msg00038.html"
},
{
"type": "WEB",
"url": "https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04682.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201611-11"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-updates/2016-12/msg00140.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/24/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2016/10/24/4"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93842"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.