CVE-2026-59168 in Dasel
Summary
by MITRE • 09/21/2026
Dasel is a command-line tool and library for querying, modifying, and transforming data structures. From 3.0.0 until 3.11.1, parsing/json/json_reader.go decodeValue, decodeObject, and decodeArray, and parsing/xml/reader.go parseElement, recurse once per input nesting level without a depth guard. Deeply nested attacker-controlled JSON or XML supplied through parsing.Format(...).NewReader(...).Read(data), the command-line interface, or the parse selector function can exhaust the Go goroutine stack and raise an unrecoverable fatal error that terminates the entire process. The XML input-size limit does not prevent depth exhaustion, and defer or recover cannot intercept the failure. This issue is fixed in version 3.11.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in Dasel versions ranging from 3.0.0 to 3.11.1 represents a critical resource exhaustion flaw rooted in insufficient input validation and depth control mechanisms within the data parsing subsystems. As a command-line tool and library designed for querying, modifying, and transforming complex data structures such as JSON and XML, Dasel relies on recursive functions to traverse nested elements. Specifically, the internal methods decodeValue, decodeObject, and decodeArray in the JSON parser, along with parseElement in the XML parser, are implemented without a depth guard or counter. This architectural oversight means that for every level of nesting present in the input data structure, the application initiates a new recursive call stack frame. When an attacker supplies deeply nested malicious payloads through any supported interface—including direct API calls via parsing.Format.NewReader.Read, command-line arguments, or selector functions—the cumulative depth exceeds the available Go goroutine stack space.
This lack of recursion limits directly leads to a denial-of-service condition characterized by a fatal runtime panic that terminates the entire process rather than allowing for graceful error handling. In standard software engineering practices, recursive algorithms processing untrusted input must enforce maximum depth constraints to prevent stack overflow attacks. The absence of such safeguards in Dasel allows an adversary to craft inputs with extreme nesting levels, effectively exhausting system resources allocated to the goroutine stack. Unlike heap-based memory exhaustion which might be mitigated by garbage collection or size limits on total bytes processed, stack exhaustion is immediate and unrecoverable within the context of a single execution thread unless explicitly handled via panic recovery mechanisms that are not present in these specific parsing paths.
The impact of this vulnerability extends beyond simple application crashes to include potential service disruption for any system relying on Dasel as part of an automated pipeline or continuous integration workflow. Since the fatal error is unrecoverable, it results in immediate process termination without cleanup operations, potentially leaving temporary files open or database transactions uncommitted depending on how the tool was invoked. Furthermore, because this behavior occurs during the initial parsing phase before any significant data processing takes place, it serves as an efficient vector for resource exhaustion attacks with minimal computational overhead from the attacker's perspective. The XML input-size limit mentioned in reports does not mitigate this issue because depth and total byte size are distinct metrics; a file can be small in overall size yet contain thousands of nested levels that trigger the stack overflow condition.
From a classification standpoint, this vulnerability aligns closely with CWE-787: Out-of-bounds Write when considering the memory corruption aspect of stack overflows, though it is more accurately categorized under CWE-400: Uncontrolled Resource Consumption due to its primary effect being resource exhaustion leading to denial of service. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior facilitates the TA0004 Impact tactic through T1499 Endpoint Denial of Service or potentially T1529 System Shutdown/Reboot if the process termination cascades into broader system instability in constrained environments. The failure to implement depth limits is a common anti-pattern in parsers that assume input trustworthiness, violating principles outlined in secure coding standards like OWASP which mandate strict validation and sanitization of all external inputs including structural complexity metrics.
Mitigation for this vulnerability requires an immediate upgrade to version 3.11.1 or later where the developers have implemented appropriate depth guards within the recursive parsing functions. For organizations unable to patch immediately, operational mitigations include implementing a reverse proxy or wrapper script that validates input structure before passing it to Dasel, enforcing maximum nesting limits at the application layer rather than relying on the tool itself for protection. Additionally, configuring system-level resource controls such as ulimits in Unix-like environments can provide a secondary defense by capping stack size per process, although this is less precise and may impact legitimate deep-nested data processing needs. Security teams should also audit other third-party tools used in their pipelines to ensure they do not share similar architectural flaws regarding unbounded recursion on untrusted input sources.