{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/tomwright/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["dasel"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","dasel","CVE-2026-46378"],"_cs_type":"advisory","_cs_vendors":["TomWright"],"content_html":"\u003cp\u003eDasel, a utility for selecting and modifying data structures, is susceptible to a denial-of-service vulnerability (CVE-2026-46378). This flaw resides in the selector lexer component of dasel versions 3.0.0 to 3.3.1. Specifically, the lexer enters an infinite loop when attempting to tokenize an unterminated regular expression pattern, such as \u003ccode\u003er/\u003c/code\u003e. This causes a single CPU core to reach 100% utilization, effectively halting the processing of any further requests or operations relying on dasel. The vulnerability was confirmed on versions v3.3.1 (fba653c7f248aff10f2b89fca93929b64707dfc8) and on the master commit 0dd6132e0c58edbd9b1a5f7ffd00dfab1e6085ad, as well as v3.0.0. An attacker who can control or influence the selector/query string passed to dasel can exploit this, potentially leading to service disruption. No fix is currently available.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious input string containing an unterminated regular expression pattern (e.g., \u003ccode\u003er/\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker injects this malicious input into an application that uses dasel to process data. This injection point could be a web application, a command-line tool, or any other context where dasel is used to handle user-provided selectors.\u003c/li\u003e\n\u003cli\u003eThe dasel application receives the malicious input and passes it to the \u003ccode\u003eNewTokenizer\u003c/code\u003e function in \u003ccode\u003eselector/lexer/tokenize.go\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe tokenizer begins to parse the input string and encounters the \u003ccode\u003er/\u003c/code\u003e sequence.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eparseCurRune\u003c/code\u003e function invokes the \u003ccode\u003ematchRegexPattern\u003c/code\u003e closure.\u003c/li\u003e\n\u003cli\u003eDue to the missing closing \u003ccode\u003e/\u003c/code\u003e, the loop on line 243 of \u003ccode\u003etokenize.go\u003c/code\u003e continues indefinitely, consuming CPU resources.\u003c/li\u003e\n\u003cli\u003eThe affected process becomes unresponsive, leading to a denial-of-service condition.\u003c/li\u003e\n\u003cli\u003eThe application relying on dasel functionality becomes unavailable or experiences degraded performance.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability leads to a denial-of-service condition. The affected process will consume 100% CPU on one core, rendering it unable to perform other tasks. This can impact web applications, command-line tools, and other systems that rely on dasel for data querying and modification. The severity depends on the criticality of the affected service, potentially disrupting business operations. While the proof of concept only affects one CPU core, in a containerized environment, this could trigger health checks to fail and the container to restart repeatedly.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply a patch to dasel as soon as one becomes available from the vendor. This is the most effective way to mitigate the vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement input validation on selector strings before they are passed to dasel. Specifically, reject any selector strings that start with \u003ccode\u003er/\u003c/code\u003e and do not contain a closing \u003ccode\u003e/\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule provided to detect instances where a \u003ccode\u003edasel\u003c/code\u003e process consumes excessive CPU, indicating a potential denial-of-service attack targeting this vulnerability.\u003c/li\u003e\n\u003cli\u003eMonitor dasel processes for unusually high CPU utilization, which can be an indicator of this vulnerability being exploited.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-19T20:11:16Z","date_published":"2026-05-19T20:11:16Z","id":"https://feed.craftedsignal.io/briefs/2026-05-dasel-dos/","summary":"Dasel versions 3.0.0 to 3.3.1 are vulnerable to a denial-of-service attack (CVE-2026-46378) where the selector lexer enters a non-terminating loop when tokenizing an unterminated regex pattern, causing 100% CPU usage on one core, which can be triggered by an attacker-controlled selector/query string.","title":"Dasel Denial-of-Service Vulnerability via Unterminated Regex","url":"https://feed.craftedsignal.io/briefs/2026-05-dasel-dos/"}],"language":"en","title":"CraftedSignal Threat Feed — TomWright","version":"https://jsonfeed.org/version/1.1"}