Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/tomwright/dasel/v3 >= 3.0.0, < 3.10.1
Fixed in
3.10.1· Vendor fix available
Issue
dasel's selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern such as r/abc. A 2-byte input (r/) is sufficient to cause the tokenizer to consume 100% CPU on one core indefinitely. I confirmed the issue on v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on master commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad. I also verified the same code path is present in v3.0.0 (648f83baf070d9e00db8ff312febef857ec090a3). No fix is available yet. Details The bug is in the matchRegexPattern closure within (Tokenizer).parseCurRune in selector/lexer/tokenize.go#L237-L247: When no closing / exists, peekRuneEqual returns false when pos = srcLen (because the bounds check at line 40 returns false for out-of-range positions). Since !false = true, the loop condition remains true and pos increments indefinitely. The function never returns. Notably, the same function already handles unterminated quoted strings by returning UnexpectedEOFError, but the regex…
Recommended action: Upgrade to 3.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/tomwright/dasel/v3 >= 3.0.0, < 3.3.2
Fixed in
3.3.2· Vendor fix available
Issue
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 YAML reader is registered in parsing/yaml/yaml.go and exposed via parsing.Format("yaml").NewReader() - (yamlReader).Read in parsing/yaml/yamlreader.go#L23-L48 uses…
Recommended action: Upgrade to 3.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.