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.

875 vulnerabilities reference this CWE, most recent first.

GHSA-CF58-VMG8-228P

Vulnerability from github – Published: 2026-02-10 21:31 – Updated: 2026-02-10 21:31
VLAI
Details

MongoDB Server may experience an out-of-memory failure while evaluating expressions that produce deeply nested documents. The issue arises in recursive functions because the server does not periodically check the depth of the expression.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-1849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T19:15:51Z",
    "severity": "HIGH"
  },
  "details": "MongoDB Server may experience an out-of-memory failure while evaluating expressions that produce deeply nested documents. The issue arises in recursive functions because the server does not periodically check the depth of the expression.",
  "id": "GHSA-cf58-vmg8-228p",
  "modified": "2026-02-10T21:31:29Z",
  "published": "2026-02-10T21:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1849"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-102364"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CJ46-35HF-RV96

Vulnerability from github – Published: 2022-09-29 00:00 – Updated: 2022-10-01 00:00
VLAI
Details

In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress "quines" gzip files, resulting in an infinite loop.

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-2022-31628"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674",
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-28T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress \"quines\" gzip files, resulting in an infinite loop.",
  "id": "GHSA-cj46-35hf-rv96",
  "modified": "2022-10-01T00:00:19Z",
  "published": "2022-09-29T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31628"
    },
    {
      "type": "WEB",
      "url": "https://bugs.php.net/bug.php?id=81726"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00030.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2L5SUVYGAKSWODUQPZFBUB3AL6E6CSEV"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VI3E6A3ZTH2RP7OMLJHSVFIEQBIFM6RF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNIEABBH5XCXLFWWZYIDE457SPEDZTXV"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202211-03"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221209-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5277"
    }
  ],
  "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-CJ9G-3MJ2-G8VV

Vulnerability from github – Published: 2026-06-25 19:51 – Updated: 2026-06-25 19:51
VLAI
Summary
MessagePack-CSharp: JSON conversion APIs can recurse without consistent depth enforcement
Details

Summary

MessagePack-CSharp's JSON conversion helpers contain multiple recursion paths that do not consistently enforce a depth limit. These paths are in the JSON conversion component rather than normal typed MessagePack deserialization.

Three related issues are covered by this advisory:

  1. MessagePackSerializer.ConvertFromJson recursively processes nested JSON arrays and objects in FromJsonCore() without consulting MessagePackSecurity.MaximumObjectGraphDepth.
  2. TinyJsonReader.ReadNextToken() recursively consumes comma and colon separator characters, allowing even malformed JSON with long separator runs to consume one stack frame per character.
  3. MessagePackSerializer.ConvertToJson applies depth checks to arrays and maps, but the typeless extension branch for ext-100 recursively calls ToJsonCore() without applying MessagePackSecurity.DepthStep(ref reader).

Each path can allow attacker-controlled input to exhaust the process stack and trigger an uncatchable StackOverflowException instead of failing with a catchable parse or serialization exception.

Impact

Applications are affected when they call MessagePack-CSharp JSON conversion APIs on attacker-controlled data. This includes gateways, diagnostics endpoints, migration tools, logging paths, and services that convert between external JSON and MessagePack payloads.

For JSON-to-MessagePack conversion, deeply nested JSON arrays or objects can recurse through FromJsonCore() without applying the configured object graph depth limit. Separately, long runs of comma or colon separator characters can recurse through TinyJsonReader.ReadNextToken() before normal structural validation rejects the input.

For MessagePack-to-JSON conversion, nested typeless extension wrappers can recurse through ToJsonCore() without the depth guard that the same function applies to arrays and maps.

MessagePackSecurity.UntrustedData does not fully mitigate these conversion paths because the missing checks occur inside JSON conversion and tokenization branches that do not consistently use the configured depth policy.

Affected components

  • Package: MessagePack
  • APIs: MessagePackSerializer.ConvertFromJson, MessagePackSerializer.ConvertToJson
  • Internal routines: FromJsonCore, ToJsonCore, TinyJsonReader.ReadNextToken
  • Data shapes: deeply nested JSON arrays/objects, long JSON separator runs, and nested typeless MessagePack extension values converted to JSON
  • Finding IDs: MESSAGEPACKCSHARP-090, MESSAGEPACKCSHARP-091, MESSAGEPACKCSHARP-092

Patches

Fixes are prepared and will be released in coordinated patch versions.

Upgrade guidance:

  1. Upgrade MessagePack to the patched version for your release line.
  2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.

The JSON-to-MessagePack fix should add explicit JSON nesting-depth accounting to FromJsonCore, using the configured maximum object graph depth or an equivalent limit, or rewrite the conversion to use an iterative bounded stack.

The tokenizer fix should replace separator self-recursion in TinyJsonReader.ReadNextToken() with an iterative loop so consecutive commas, colons, and whitespace do not consume stack frames.

The MessagePack-to-JSON fix should apply DepthStep and matching reader.Depth-- cleanup around recursive ToJsonCore() calls made from the typeless extension branch, consistent with the existing array and map conversion branches.

Workarounds

Patching is recommended.

Until a patched version is available, do not pass untrusted JSON directly to ConvertFromJson, and do not call ConvertToJson on untrusted MessagePack payloads that may contain typeless extension values. Validate JSON nesting depth with a parser that enforces depth limits before calling MessagePack-CSharp, reject malformed JSON before conversion, and apply strict input-size limits.

Input-size limits reduce exposure but do not remove the recursive behavior in affected versions.

References

  • MESSAGEPACKCSHARP-090: ConvertFromJson unbounded structural recursion
  • MESSAGEPACKCSHARP-091: TinyJsonReader.ReadNextToken separator self-recursion
  • MESSAGEPACKCSHARP-092: ConvertToJson ext-100 branch missing depth enforcement
  • CWE-674: Uncontrolled Recursion

CVE split rationale

These issues are grouped because they affect the same JSON conversion feature area and share the same failure mode: recursive conversion/tokenization paths do not consistently enforce depth or iteration bounds for attacker-controlled input. They are distinct from normal binary MessagePack skip recursion, dynamic union formatter depth accounting, DateTime stack allocation, and allocation-oriented denial-of-service issues.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.5.301"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "MessagePack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T19:51:36Z",
    "nvd_published_at": "2026-06-22T22:16:47Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nMessagePack-CSharp\u0027s JSON conversion helpers contain multiple recursion paths that do not consistently enforce a depth limit. These paths are in the JSON conversion component rather than normal typed MessagePack deserialization.\n\nThree related issues are covered by this advisory:\n\n1. `MessagePackSerializer.ConvertFromJson` recursively processes nested JSON arrays and objects in `FromJsonCore()` without consulting `MessagePackSecurity.MaximumObjectGraphDepth`.\n2. `TinyJsonReader.ReadNextToken()` recursively consumes comma and colon separator characters, allowing even malformed JSON with long separator runs to consume one stack frame per character.\n3. `MessagePackSerializer.ConvertToJson` applies depth checks to arrays and maps, but the typeless extension branch for ext-100 recursively calls `ToJsonCore()` without applying `MessagePackSecurity.DepthStep(ref reader)`.\n\nEach path can allow attacker-controlled input to exhaust the process stack and trigger an uncatchable `StackOverflowException` instead of failing with a catchable parse or serialization exception.\n\n## Impact\n\nApplications are affected when they call MessagePack-CSharp JSON conversion APIs on attacker-controlled data. This includes gateways, diagnostics endpoints, migration tools, logging paths, and services that convert between external JSON and MessagePack payloads.\n\nFor JSON-to-MessagePack conversion, deeply nested JSON arrays or objects can recurse through `FromJsonCore()` without applying the configured object graph depth limit. Separately, long runs of comma or colon separator characters can recurse through `TinyJsonReader.ReadNextToken()` before normal structural validation rejects the input.\n\nFor MessagePack-to-JSON conversion, nested typeless extension wrappers can recurse through `ToJsonCore()` without the depth guard that the same function applies to arrays and maps.\n\n`MessagePackSecurity.UntrustedData` does not fully mitigate these conversion paths because the missing checks occur inside JSON conversion and tokenization branches that do not consistently use the configured depth policy.\n\n## Affected components\n\n- Package: `MessagePack`\n- APIs: `MessagePackSerializer.ConvertFromJson`, `MessagePackSerializer.ConvertToJson`\n- Internal routines: `FromJsonCore`, `ToJsonCore`, `TinyJsonReader.ReadNextToken`\n- Data shapes: deeply nested JSON arrays/objects, long JSON separator runs, and nested typeless MessagePack extension values converted to JSON\n- Finding IDs: `MESSAGEPACKCSHARP-090`, `MESSAGEPACKCSHARP-091`, `MESSAGEPACKCSHARP-092`\n\n## Patches\n\nFixes are prepared and will be released in coordinated patch versions.\n\nUpgrade guidance:\n\n1. Upgrade `MessagePack` to the patched version for your release line.\n2. Upgrade companion MessagePack packages in the same dependency graph to the coordinated patched versions.\n\nThe JSON-to-MessagePack fix should add explicit JSON nesting-depth accounting to `FromJsonCore`, using the configured maximum object graph depth or an equivalent limit, or rewrite the conversion to use an iterative bounded stack.\n\nThe tokenizer fix should replace separator self-recursion in `TinyJsonReader.ReadNextToken()` with an iterative loop so consecutive commas, colons, and whitespace do not consume stack frames.\n\nThe MessagePack-to-JSON fix should apply `DepthStep` and matching `reader.Depth--` cleanup around recursive `ToJsonCore()` calls made from the typeless extension branch, consistent with the existing array and map conversion branches.\n\n## Workarounds\n\nPatching is recommended.\n\nUntil a patched version is available, do not pass untrusted JSON directly to `ConvertFromJson`, and do not call `ConvertToJson` on untrusted MessagePack payloads that may contain typeless extension values. Validate JSON nesting depth with a parser that enforces depth limits before calling MessagePack-CSharp, reject malformed JSON before conversion, and apply strict input-size limits.\n\nInput-size limits reduce exposure but do not remove the recursive behavior in affected versions.\n\n## References\n\n- `MESSAGEPACKCSHARP-090`: `ConvertFromJson` unbounded structural recursion\n- `MESSAGEPACKCSHARP-091`: `TinyJsonReader.ReadNextToken` separator self-recursion\n- `MESSAGEPACKCSHARP-092`: `ConvertToJson` ext-100 branch missing depth enforcement\n- CWE-674: Uncontrolled Recursion\n\n## CVE split rationale\n\nThese issues are grouped because they affect the same JSON conversion feature area and share the same failure mode: recursive conversion/tokenization paths do not consistently enforce depth or iteration bounds for attacker-controlled input. They are distinct from normal binary MessagePack skip recursion, dynamic union formatter depth accounting, DateTime stack allocation, and allocation-oriented denial-of-service issues.",
  "id": "GHSA-cj9g-3mj2-g8vv",
  "modified": "2026-06-25T19:51:36Z",
  "published": "2026-06-25T19:51:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-cj9g-3mj2-g8vv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48512"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MessagePack-CSharp/MessagePack-CSharp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MessagePack-CSharp: JSON conversion APIs can recurse without consistent depth enforcement"
}

GHSA-CMR2-GMFQ-RGQ8

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-05-24 16:44
VLAI
Details

An issue was discovered in Artifex MuJS 1.0.5. It has unlimited recursion because the match function in regexp.c lacks a depth check.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-22T11:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Artifex MuJS 1.0.5. It has unlimited recursion because the match function in regexp.c lacks a depth check.",
  "id": "GHSA-cmr2-gmfq-rgq8",
  "modified": "2022-05-24T16:44:05Z",
  "published": "2022-05-24T16:44:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11413"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ccxvii/mujs/commit/00d4606c3baf813b7b1c176823b2729bf51002a2"
    },
    {
      "type": "WEB",
      "url": "https://bugs.ghostscript.com/show_bug.cgi?id=700937"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3RQXMWEOWCGLOLFBQSXBM3MBN33T4I5H"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/67PMOZV4DLVL2KGU2SV724QL7Y4PKWKU"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MFCRO74ORRIVWNVAX2MAMRY3THCTWLQI"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202007-52"
    },
    {
      "type": "WEB",
      "url": "http://www.ghostscript.com/cgi-bin/findgit.cgi?00d4606c3baf813b7b1c176823b2729bf51002a2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108093"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CPJV-M49G-H8M9

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

Nextcloud Server before 9.0.55 and 10.0.2 suffers from a Denial of Service attack. Due to an error in the application logic an authenticated adversary may trigger an endless recursion in the application leading to a potential Denial of Service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-0886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-05T20:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Nextcloud Server before 9.0.55 and 10.0.2 suffers from a Denial of Service attack. Due to an error in the application logic an authenticated adversary may trigger an endless recursion in the application leading to a potential Denial of Service.",
  "id": "GHSA-cpjv-m49g-h8m9",
  "modified": "2022-05-13T01:38:26Z",
  "published": "2022-05-13T01:38:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0886"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/174524"
    },
    {
      "type": "WEB",
      "url": "https://nextcloud.com/security/advisory/?id=nc-sa-2017-004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CPQC-Q57W-7C2Q

Vulnerability from github – Published: 2026-09-23 12:31 – Updated: 2026-09-23 12:31
VLAI
Details

Uncontrolled recursion in QXmlStreamReader::readElementText() in Qt Group Qt allows attackers to cause a denial of service (application crash via stack exhaustion) via a crafted XML document.

Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/S:N/AU:N/R:U/RE:L/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-78253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-23T12:17:07Z",
    "severity": "LOW"
  },
  "details": "Uncontrolled recursion in QXmlStreamReader::readElementText() in Qt Group Qt allows attackers to cause a denial of service (application crash via stack exhaustion) via a crafted XML document.",
  "id": "GHSA-cpqc-q57w-7c2q",
  "modified": "2026-09-23T12:31:15Z",
  "published": "2026-09-23T12:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78253"
    },
    {
      "type": "WEB",
      "url": "https://codereview.qt-project.org/c/qt/qtbase/+/754345"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:N/R:U/V:X/RE:L/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CQXR-JXR2-85PQ

Vulnerability from github – Published: 2026-09-22 19:51 – Updated: 2026-09-22 19:51
VLAI
Summary
Dasel: Unbounded recursion in JSON and XML readers causes unrecoverable stack-overflow DoS
Details

Summary

dasel's JSON and XML readers parse nested structures with unbounded recursion, one native stack frame per nesting level, with no depth guard. A small (sub-10 MB), deeply nested document drives the Go runtime past its goroutine stack limit and triggers a fatal error: stack overflow. This is unrecoverable: it is a runtime fatal error, not a panic, so a consumer's defer/recover cannot intercept it, the entire process dies.

Both readers are affected; neither has a depth limit, and the JSON reader additionally has no input-size cap (the XML reader caps size at 10 MB but not depth).

Affected Versions

github.com/tomwright/dasel/v3 and all v3.x releases through v3.11.0 (current main, commit abc1e1d). This vulnerability is fixed in 3.11.1. Pre-v3 is out of scope.

Description

JSON reader @ parsing/json/json_reader.go

decodeValue (line 54) dispatches to the mutually-recursive decodeObject (line 78) and decodeArray (line 140). Each calls back into both for nested values (decodeArray→decodeArray at line 151, decodeObject at 163; decodeObject→decodeArray at 95, decodeObject at 111). Every [ or { in the input adds one stack frame. There is no depth counter and no len(data) cap anywhere in the reader.

XML reader @parsing/xml/reader.go

parseElement (line 172) recurses at line 211 for every xml.StartElement. The file declares explicit DoS guards — maxXMLSize = 10_000_000, comment count/length — but these bound size and comment volume, not nesting depth. The open tag <a> is 3 bytes, so the 10 MB cap still permits ~3.3 M nesting levels, exhausting the stack long before the size limit fires.

Reachability (both)

Both are on the primary public read path: parsing.Format(<fmt>).NewReader(opts).Read(data), with data fully attacker-controlled and no depth validation before the recursion. The same path backs the dasel CLI (dasel -r json / -r xml). Default reader, no special options. Go stack overflow is a fatal error, so recover() at the call site does not help.

Precedent in this codebase

DoS hardening on the readers is already an accepted concern here, which is why this is a gap rather than a design choice: the XML reader has the maxXMLSize cap, and the YAML reader already implements exactly the fix needed, parsing/yaml/yaml_reader.go:31,90-93 returns ErrYamlExpansionDepthExceeded once expansionDepth > maxExpansionDepth. The JSON and XML readers simply lack the equivalent depth guard.

Proof of Concept

Single runnable program, public API only (poc/main.go, module wired to a local clone via replace):

package main

import (
    "fmt"; "os"; "strings"
    "github.com/tomwright/dasel/v3/parsing"
    _ "github.com/tomwright/dasel/v3/parsing/json"
    _ "github.com/tomwright/dasel/v3/parsing/xml"
)

func main() {
    mode := "json"; if len(os.Args) > 1 { mode = os.Args[1] }
    depth := 6_000_000; if mode == "xml" { depth = 3_200_000 }

    var data []byte
    if mode == "xml" {
        data = []byte(strings.Repeat("<a>", depth))          // ~9.6MB, under the 10MB cap
    } else {
        data = []byte(strings.Repeat("[", depth) + strings.Repeat("]", depth)) // ~12MB
    }

    defer func() { if r := recover(); r != nil { fmt.Println("recovered (NOT fatal):", r) } }()
    r, _ := parsing.Format(mode).NewReader(parsing.DefaultReaderOptions())
    v, err := r.Read(data)
    fmt.Printf("Read returned WITHOUT crash: v=%v err=%v\n", v != nil, err)
}

go run . json    # nested arrays -> fatal error: stack overflow ; ~85 decodeArray frames
go run . xml     # nested <a>    -> fatal error: stack overflow ; ~93 parseElement frames

Observed (Go 1.26, default 1 GB goroutine stack): - json depth 6 M (12 MB): runtime: goroutine stack exceeds 1000000000-byte limit → fatal error: stack overflow; backtrace dominated by json.(*jsonReader).decodeArray. depth 2 M completes (~0.83 s), confirming it is depth-driven, not a parse error. - xml depth 3.2 M (9.6 MB, under the 10 MB maxXMLSize cap): same fatal overflow; backtrace is an unbroken chain of xml.(*xmlReader).parseElement at reader.go:211. - The deferred recover() never fires in either case — the process exits. - CLI equivalents: printf '<a>%.0s' {1..3200000} | dasel -r xml.

Impact

An attacker who controls JSON or XML passed to dasel — via the library Read API, the CLI, or the parse('json'|'xml', …) selector function — crashes the host process with a single small document. Because the failure is a Go fatal error rather than a recoverable panic, a consumer that wraps parsing in defer/recover is still taken down: the whole process terminates, killing every in-flight goroutine, not just the parse. Availability only — no confidentiality or integrity impact. For a library consumer feeding network-sourced data to Read, this is a remotely triggerable, unrecoverable DoS.

Suggested Fix

Add a recursion-depth guard to both readers, mirroring the YAML reader's existing maxExpansionDepth / ErrYamlExpansionDepthExceeded pattern:

  • JSON — thread a depth int through decodeValue/decodeObject/decodeArray, increment on descent, return ErrJSONMaxDepthExceeded past a conservative bound (e.g. 10 000). Optionally add a maxJSONSize cap matching maxXMLSize for parity.
  • XML — add a maxXMLDepth constant to the existing Security limits block and thread a depth through parseElement, returning a normal error past the bound.

Both return a clean error for pathological input instead of crashing the process, consistent with how the comment-count, size, and YAML-expansion limits already behave. A limit in the low thousands preserves all realistic legitimate documents.

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/tomwright/dasel/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T19:51:07Z",
    "nvd_published_at": "2026-09-21T17:17:36Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`dasel`\u0027s JSON and XML readers parse nested structures with unbounded recursion, one\nnative stack frame per nesting level, with no depth guard. A small (sub-10 MB), deeply\nnested document drives the Go runtime past its goroutine stack limit and triggers a\n`fatal error: stack overflow`. This is **unrecoverable**: it is a runtime fatal error, not\na `panic`, so a consumer\u0027s `defer`/`recover` cannot intercept it, the entire process dies.\n\nBoth readers are affected; neither has a depth limit, and the JSON reader additionally has\nno input-size cap (the XML reader caps size at 10 MB but not depth).\n\n## Affected Versions\n\n`github.com/tomwright/dasel/v3` and all v3.x releases through **v3.11.0** (current `main`,\ncommit `abc1e1d`). This vulnerability is fixed in 3.11.1. Pre-v3 is out of scope.\n\n## Description\n\n### JSON reader @ `parsing/json/json_reader.go`\n\n`decodeValue` (line 54) dispatches to the mutually-recursive `decodeObject` (line 78) and\n`decodeArray` (line 140). Each calls back into both for nested values\n(`decodeArray`\u2192`decodeArray` at line 151, `decodeObject` at 163; `decodeObject`\u2192`decodeArray`\nat 95, `decodeObject` at 111). Every `[` or `{` in the input adds one stack frame. There is\n**no depth counter and no `len(data)` cap** anywhere in the reader.\n\n### XML reader @`parsing/xml/reader.go`\n\n`parseElement` (line 172) recurses at line 211 for every `xml.StartElement`. The file\ndeclares explicit DoS guards \u2014 `maxXMLSize = 10_000_000`, comment count/length \u2014 but these\nbound **size and comment volume, not nesting depth**. The open tag `\u003ca\u003e` is 3 bytes, so the\n10 MB cap still permits ~3.3 M nesting levels, exhausting the stack long before the size\nlimit fires.\n\n### Reachability (both)\n\nBoth are on the primary public read path: `parsing.Format(\u003cfmt\u003e).NewReader(opts).Read(data)`,\nwith `data` fully attacker-controlled and no depth validation before the recursion. The same\npath backs the `dasel` CLI (`dasel -r json` / `-r xml`). Default reader, no special options.\nGo stack overflow is a `fatal error`, so `recover()` at the call site does not help.\n\n### Precedent in this codebase\n\nDoS hardening on the readers is already an accepted concern here, which is why this is a gap\nrather than a design choice: the XML reader has the `maxXMLSize` cap, and the **YAML reader\nalready implements exactly the fix needed**, `parsing/yaml/yaml_reader.go:31,90-93` returns\n`ErrYamlExpansionDepthExceeded` once `expansionDepth \u003e maxExpansionDepth`. The JSON and XML\nreaders simply lack the equivalent depth guard.\n\n## Proof of Concept\n\nSingle runnable program, public API only (`poc/main.go`, module wired to a local clone via\n`replace`):\n\n```go\npackage main\n\nimport (\n\t\"fmt\"; \"os\"; \"strings\"\n\t\"github.com/tomwright/dasel/v3/parsing\"\n\t_ \"github.com/tomwright/dasel/v3/parsing/json\"\n\t_ \"github.com/tomwright/dasel/v3/parsing/xml\"\n)\n\nfunc main() {\n\tmode := \"json\"; if len(os.Args) \u003e 1 { mode = os.Args[1] }\n\tdepth := 6_000_000; if mode == \"xml\" { depth = 3_200_000 }\n\n\tvar data []byte\n\tif mode == \"xml\" {\n\t\tdata = []byte(strings.Repeat(\"\u003ca\u003e\", depth))          // ~9.6MB, under the 10MB cap\n\t} else {\n\t\tdata = []byte(strings.Repeat(\"[\", depth) + strings.Repeat(\"]\", depth)) // ~12MB\n\t}\n\n\tdefer func() { if r := recover(); r != nil { fmt.Println(\"recovered (NOT fatal):\", r) } }()\n\tr, _ := parsing.Format(mode).NewReader(parsing.DefaultReaderOptions())\n\tv, err := r.Read(data)\n\tfmt.Printf(\"Read returned WITHOUT crash: v=%v err=%v\\n\", v != nil, err)\n}\n```\n\n```\ngo run . json    # nested arrays -\u003e fatal error: stack overflow ; ~85 decodeArray frames\ngo run . xml     # nested \u003ca\u003e    -\u003e fatal error: stack overflow ; ~93 parseElement frames\n```\n\nObserved (Go 1.26, default 1 GB goroutine stack):\n- `json` depth 6 M (12 MB): `runtime: goroutine stack exceeds 1000000000-byte limit` \u2192\n  `fatal error: stack overflow`; backtrace dominated by `json.(*jsonReader).decodeArray`.\n  `depth 2 M` completes (~0.83 s), confirming it is depth-driven, not a parse error.\n- `xml` depth 3.2 M (9.6 MB, **under** the 10 MB `maxXMLSize` cap): same fatal overflow;\n  backtrace is an unbroken chain of `xml.(*xmlReader).parseElement` at `reader.go:211`.\n- The deferred `recover()` never fires in either case \u2014 the process exits.\n- CLI equivalents: `printf \u0027\u003ca\u003e%.0s\u0027 {1..3200000} | dasel -r xml`.\n\n## Impact\n\nAn attacker who controls JSON or XML passed to dasel \u2014 via the library `Read` API, the CLI,\nor the `parse(\u0027json\u0027|\u0027xml\u0027, \u2026)` selector function \u2014 crashes the host process with a single\nsmall document. Because the failure is a Go `fatal error` rather than a recoverable panic, a\nconsumer that wraps parsing in `defer`/`recover` is **still** taken down: the whole process\nterminates, killing every in-flight goroutine, not just the parse. Availability only \u2014 no\nconfidentiality or integrity impact. For a library consumer feeding network-sourced data to\n`Read`, this is a remotely triggerable, unrecoverable DoS.\n\n## Suggested Fix\n\nAdd a recursion-depth guard to both readers, mirroring the YAML reader\u0027s existing\n`maxExpansionDepth` / `ErrYamlExpansionDepthExceeded` pattern:\n\n- **JSON** \u2014 thread a `depth int` through `decodeValue`/`decodeObject`/`decodeArray`,\n  increment on descent, return `ErrJSONMaxDepthExceeded` past a conservative bound\n  (e.g. 10 000). Optionally add a `maxJSONSize` cap matching `maxXMLSize` for parity.\n- **XML** \u2014 add a `maxXMLDepth` constant to the existing `Security limits` block and thread\n  a `depth` through `parseElement`, returning a normal error past the bound.\n\nBoth return a clean `error` for pathological input instead of crashing the process,\nconsistent with how the comment-count, size, and YAML-expansion limits already behave. A\nlimit in the low thousands preserves all realistic legitimate documents.",
  "id": "GHSA-cqxr-jxr2-85pq",
  "modified": "2026-09-22T19:51:07Z",
  "published": "2026-09-22T19:51:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TomWright/dasel/security/advisories/GHSA-cqxr-jxr2-85pq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TomWright/dasel/commit/4c91d0d02dc59ce8404709b1bfed7a6fabe62f68"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TomWright/dasel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TomWright/dasel/releases/tag/v3.11.1"
    }
  ],
  "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: Unbounded recursion in JSON and XML readers causes unrecoverable stack-overflow DoS"
}

GHSA-CR2V-P345-FP24

Vulnerability from github – Published: 2023-12-12 12:30 – Updated: 2023-12-12 12:30
VLAI
Details

A vulnerability has been identified in SIMATIC PC-Station Plus (All versions), SIMATIC S7-400 CPU 412-2 PN V7 (All versions), SIMATIC S7-400 CPU 414-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 414F-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 416-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 416F-3 PN/DP V7 (All versions), SINAMICS S120 (incl. SIPLUS variants) (All versions < V5.2 SP3 HF15), SIPLUS S7-400 CPU 414-3 PN/DP V7 (All versions), SIPLUS S7-400 CPU 416-3 PN/DP V7 (All versions). The affected products do not handle HTTP(S) requests to the web server correctly.

This could allow an attacker to exhaust system resources and create a denial of service condition for the device.

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-2022-47374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-12T12:15:10Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SIMATIC\u00a0PC-Station Plus (All versions), SIMATIC S7-400 CPU 412-2 PN V7 (All versions), SIMATIC S7-400 CPU 414-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 414F-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 416-3 PN/DP V7 (All versions), SIMATIC S7-400 CPU 416F-3 PN/DP V7 (All versions), SINAMICS S120 (incl. SIPLUS variants) (All versions \u003c V5.2 SP3 HF15), SIPLUS S7-400 CPU 414-3 PN/DP V7 (All versions), SIPLUS S7-400 CPU 416-3 PN/DP V7 (All versions). The affected products do not handle HTTP(S) requests to the web server correctly.\n\nThis could allow an attacker to exhaust system resources and create a denial of service condition for the device.",
  "id": "GHSA-cr2v-p345-fp24",
  "modified": "2023-12-12T12:30:53Z",
  "published": "2023-12-12T12:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47374"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-892915.pdf"
    }
  ],
  "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-CR4V-6M54-7VH3

Vulnerability from github – Published: 2024-08-15 21:31 – Updated: 2024-08-20 21:30
VLAI
Details

In Xpdf 4.05 (and earlier), a PDF object loop in a pattern resource leads to infinite recursion and a stack overflow.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
2.1 (Low)
CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-7866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-15T20:15:18Z",
    "severity": "LOW"
  },
  "details": "In Xpdf 4.05 (and earlier), a PDF object loop in a pattern resource leads to infinite recursion and a stack overflow.",
  "id": "GHSA-cr4v-6m54-7vh3",
  "modified": "2024-08-20T21:30:32Z",
  "published": "2024-08-15T21:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7866"
    },
    {
      "type": "WEB",
      "url": "https://www.xpdfreader.com/security-bug/object-loops.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CRMJ-QH74-2R36

Vulnerability from github – Published: 2024-10-17 17:13 – Updated: 2024-10-23 17:40
VLAI
Summary
Exiv2 has a denial of service due to unbounded recursion in QuickTimeVideo::multipleEntriesDecoder
Details

Impact

A denial-of-service was found in Exiv2 version v0.28.1: an unbounded recursion can cause Exiv2 to crash by exhausting the stack. The vulnerable function, QuickTimeVideo::multipleEntriesDecoder, was new in v0.28.0 (see https://github.com/Exiv2/exiv2/pull/2337), so Exiv2 versions before v0.28 are not affected. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted video file.

Patches

The bug is fixed in version v0.28.2.

For more information

Please see our security policy for information about Exiv2 security.

Credit

This bug was found by OSS-Fuzz.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "exiv2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.16.0"
            },
            {
              "fixed": "0.16.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-17T17:13:24Z",
    "nvd_published_at": "2024-02-12T23:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA denial-of-service was found in Exiv2 version v0.28.1: an unbounded recursion can cause Exiv2 to crash by exhausting the stack. The vulnerable function, `QuickTimeVideo::multipleEntriesDecoder`, was new in v0.28.0 (see https://github.com/Exiv2/exiv2/pull/2337), so Exiv2 versions before v0.28 are _not_ affected.  Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted video file.\n\n### Patches\nThe bug is fixed in version v0.28.2.\n\n### For more information\nPlease see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.\n\n### Credit\nThis bug was found by [OSS-Fuzz](https://github.com/google/oss-fuzz).",
  "id": "GHSA-crmj-qh74-2r36",
  "modified": "2024-10-23T17:40:19Z",
  "published": "2024-10-17T17:13:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Exiv2/exiv2/security/advisories/GHSA-crmj-qh74-2r36"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25112"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Exiv2/exiv2/pull/2337"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Exiv2/exiv2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/exiv2/PYSEC-2024-107.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Exiv2  has a denial of service due to unbounded recursion in QuickTimeVideo::multipleEntriesDecoder"
}
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