{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/cpes/cpe2.3ajunrar_projectjunrar/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:junrar_project:junrar:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-97370"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["junrar (\u003c= 7.6.0)"],"_cs_severities":["low"],"_cs_tags":[],"_cs_type":"advisory","_cs_vendors":["Junrar"],"content_html":"\u003cp\u003eThe Junrar Java library is susceptible to a denial-of-service (DoS) condition due to a logic flaw in the RAR virtual machine (RarVM). When processing a specially crafted RAR4 archive, the \u003ccode\u003eRarVM.ExecuteCode\u003c/code\u003e routine can be forced into an infinite loop. This occurs because the \u003ccode\u003eVM_JMP\u003c/code\u003e instruction handler improperly validates jump targets. When a jump target is equal to or greater than the defined \u003ccode\u003ecodeSize\u003c/code\u003e, the \u003ccode\u003esetIP()\u003c/code\u003e function returns success without updating the instruction pointer (IP) or decrementing the \u003ccode\u003emaxOpCount\u003c/code\u003e safety counter.\u003c/p\u003e\n\u003cp\u003eBecause the main VM loop continues immediately after the jump without updating these values, the same \u003ccode\u003eVM_JMP\u003c/code\u003e instruction is repeatedly executed. An attacker can exploit this by providing malicious archives to applications using \u003ccode\u003eJunrar.extract()\u003c/code\u003e, leading to permanent hang of extraction worker threads and resource exhaustion. This flaw, tracked as CVE-2026-97370, affects all versions of \u003ccode\u003ejunrar\u003c/code\u003e up to and including 7.6.0. The vulnerability is restricted to availability impact and does not grant code execution due to Java's built-in memory protection.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker crafts a malicious RAR4 archive containing a VM program with a \u003ccode\u003eVM_JMP\u003c/code\u003e instruction.\u003c/li\u003e\n\u003cli\u003eThe instruction is configured with a target address that is greater than or equal to the archive's \u003ccode\u003ecodeSize\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe victim application invokes \u003ccode\u003eJunrar.extract()\u003c/code\u003e on the uploaded or retrieved malicious RAR archive.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eRarVM\u003c/code\u003e component encounters the crafted \u003ccode\u003eVM_JMP\u003c/code\u003e instruction during the extraction routine.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003esetIP()\u003c/code\u003e function validates the target address, returns \u003ccode\u003etrue\u003c/code\u003e, but fails to update the \u003ccode\u003eIP\u003c/code\u003e variable.\u003c/li\u003e\n\u003cli\u003eThe main VM loop incorrectly ignores the \u003ccode\u003esetIP()\u003c/code\u003e result and executes a \u003ccode\u003econtinue\u003c/code\u003e statement, skipping the \u003ccode\u003emaxOpCount\u003c/code\u003e decrement.\u003c/li\u003e\n\u003cli\u003eThe VM loop re-executes the same \u003ccode\u003eVM_JMP\u003c/code\u003e instruction indefinitely.\u003c/li\u003e\n\u003cli\u003eThe extraction thread consumes 100% CPU, leading to service degradation or process exhaustion.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation results in a persistent denial-of-service condition for applications relying on the \u003ccode\u003ejunrar\u003c/code\u003e library. In multi-tenant environments or services that process file uploads, this vulnerability can be leveraged to exhaust worker thread pools, preventing the processing of legitimate files. No code execution is documented, but the inability to terminate the extraction loop may require a manual process restart to restore service functionality.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the \u003ccode\u003ejunrar\u003c/code\u003e library to a version greater than 7.6.0 as soon as a patch is available.\u003c/li\u003e\n\u003cli\u003eImplement strict size and complexity limits on files processed by archival libraries to mitigate potential DoS vectors.\u003c/li\u003e\n\u003cli\u003eMonitor application server thread health and resource utilization for extraction tasks.\u003c/li\u003e\n\u003cli\u003eIf updating is not immediately possible, implement a watchdog timer or thread timeout for archive extraction routines to force-terminate hung processes.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-10-15T22:27:26Z","date_published":"2026-10-15T22:27:26Z","id":"https://feed.craftedsignal.io/briefs/2026-10-junrar-dos/","summary":"An infinite loop vulnerability in the Junrar Java library, identified as CVE-2026-97370, allows unauthenticated attackers to cause CPU exhaustion via crafted RAR4 archives.","title":"Junrar RARVM Infinite Loop Denial of Service","url":"https://feed.craftedsignal.io/briefs/2026-10-junrar-dos/"}],"language":"en","title":"CraftedSignal Threat Feed - Cpe:2.3:a:junrar_project:junrar:*:*:*:*:*:*:*:*","version":"https://jsonfeed.org/version/1.1"}