Jsish CVE-2025-65570

Exploitation requires the attacker to get attacker-controlled JavaScript executed by jsish 2.0; the specific trigger is a script in which an 'instanceof' expression uses an array element access as its left-hand operand inside a for-in loop, which leaves a stray array reference that OP_NEXT then misuses as an iterCmd function pointer. Limiting factors: the attacker must be able to supply/run arbitrary script source, so if jsish is used as a local tool this is effectively a local-access condition rather than remote; and achieving code execution (as opposed to a crash) is not guaranteed - it depends on favorable heap layout, requiring heap grooming for reliability. No special non-default configuration is named in the description, but exploitation is bounded to the exact jsish 2.0 interpreter processing the malicious script.

The input CVSS 3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) paints this as a maximally critical, network-reachable, unauthenticated RCE, but the multi-source signals do not support that urgency. EPSS is only 0.53% (43rd percentile), the CVE is NOT on the CISA KEV list, and there is no evidence of active exploitation - only a single publicly available exploit/writeup. So the signals conflict: CVSS says 'drop everything,' while EPSS and the absence of KEV say 'low probability of widespread exploitation.' The CVSS AV:N rating is also questionable for a JavaScript interpreter bug (CWE-843 type confusion in the OP_NEXT/OP_INSTANCEOF opcode handling): exploitation fundamentally requires the attacker to get attacker-controlled JavaScript executed by jsish, which is typically a local/script-supply condition unless jsish is deployed as a service evaluating untrusted scripts over a network - verify the deployment context with the operator. The description's own wording ('potentially causing a crash or enabling code execution depending on heap layout') indicates reliable code execution is NOT guaranteed and depends on heap grooming, undercutting the AC:L rating. Net assessment: this is a genuine memory-corruption bug with a public POC, but given the obscure/niche product, low EPSS, and no KEV listing, it is a high-CVSS-but-realistically-low-priority issue outside of environments that actually run jsish on untrusted input.

An attacker who can supply or influence JavaScript executed by a jsish 2.0 interpreter crafts a script containing an 'instanceof' expression whose left-hand operand is an array element access, placed inside a for-in loop. When executed, OP_INSTANCEOF fails to consume an array reference, leaving it on the stack so OP_NEXT misinterprets the array as an iterator and dereferences an attacker-influenced iterCmd function pointer, crashing the process or - depending on heap layout - executing arbitrary code. A public exploit/writeup already exists demonstrating the technique.