{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.6.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.github.junrar:junrar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-97370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:09:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nJunrar\u0027s RAR virtual machine can be forced into a deterministic infinite loop while extracting a crafted RAR4 archive. The `RarVM.ExecuteCode` loop is intended to be bounded by `maxOpCount`, but jump instructions can bypass this limit when `setIP()` is called with a target instruction pointer greater than or equal to `codeSize`.\n\nAn unauthenticated attacker who can provide a RAR archive to an application using `Junrar.extract()` can cause the extraction thread to spin forever, consuming CPU and blocking the process. The issue is a denial of service vulnerability, not remote code execution.\n\n### Details\n\nThe root cause is in `src/main/java/com/github/junrar/unpack/vm/RarVM.java`.\n\n`setIP()` returns early when the target IP is outside the prepared VM program:\n\n```java\nprivate boolean setIP(int ip) {\n    if ((ip) \u003e= codeSize) {\n        return (true);\n    }\n\n    if (--maxOpCount \u003c= 0) {\n        return (false);\n    }\n\n    IP = ip;\n    return true;\n}\n```\n\nWhen `ip \u003e= codeSize`, this branch:\n\n- does not update `IP`;\n- does not decrement `maxOpCount`;\n- returns `true`, so callers treat it as success.\n\nThe `VM_JMP` handler and the other jump-like handlers discard the return value of `setIP()` and immediately `continue` the main VM loop:\n\n```java\ncase VM_JMP:\n    setIP(getValue(false, mem, op1));\n    continue;\n```\n\nBecause of the `continue`, execution also skips the loop-end accounting:\n\n```java\nIP++;\n--maxOpCount;\n```\n\nAs a result, a VM program containing a single `VM_JMP` instruction can freeze both `IP` and `maxOpCount`:\n\n1. `IP` points to the `VM_JMP` instruction.\n2. The jump target resolves to `codeSize` or larger.\n3. `setIP()` returns before modifying `IP` or decrementing `maxOpCount`.\n4. The caller ignores the return value and continues.\n5. The same `VM_JMP` instruction is executed again forever.\n\n### Impact\n\nThis is a CPU denial of service vulnerability. Any application that uses junrar to extract untrusted RAR archives can have an extraction worker thread permanently blocked by a small crafted archive. In services that process uploads or attachments automatically, repeated submissions can exhaust worker capacity and degrade or stop archive-processing functionality.\n\nThe RAR VM does not provide native code execution, reflection, or process execution primitives, and Java array bounds checks prevent escaping the VM memory array. The expected security impact is availability only.",
  "id": "GHSA-h9h9-2rmf-rvhp",
  "modified": "2026-10-15T20:09:47Z",
  "published": "2026-10-15T20:09:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/junrar/junrar/security/advisories/GHSA-h9h9-2rmf-rvhp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junrar/junrar/commit/687a09c42f46066447faa9179ee11314ad6d9afb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/junrar/junrar"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junrar/junrar/releases/tag/v7.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Junrar: RarVM VM_JMP maxOpCount bypass causes infinite CPU loop during RAR4 extraction"
}