Espruino EUVD-2026-86313

Exploitation requires the attacker to supply crafted JavaScript (an overlong token) to the Espruino interpreter - via the device's serial/USB REPL, an exposed network console, or eval of untrusted script - so local access to a JS input path is needed (AV:L). Critically, the flaw only triggers in RELEASE/NO_ASSERT firmware builds; debug builds with assertions enabled catch the overlong token before the out-of-bounds write, so devices running assert-enabled builds are not affected. There is no authentication metric-backed gate (PR:N per the vector) and no user interaction required beyond feeding the input, but the demonstrated outcome is limited to memory corruption/crash (DoS) rather than confirmed code execution.

The provided CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, score 7.7) frames this as a local, low-complexity flaw requiring no privileges or interaction, with high integrity and availability impact. That severity is somewhat inflated: the underlying bug is a single one-byte out-of-bounds NUL write past the JsLex.token buffer, and both the description and the fix commit (ecd7d43) point to memory corruption manifesting as crashes/denial of service rather than demonstrated code execution or data tampering - so I:H is arguably closer to I:L (see assessed vector). Exploitation signals are weak-to-neutral: no CISA KEV entry, no EPSS score supplied, and no public exploit code identified; there is only a GitHub issue (#2744) and the vendor fix commit, no SSVC decision data. The attack vector is local (AV:L) because an attacker must feed crafted JavaScript into the interpreter (REPL, serial console, or eval of untrusted script), and it only manifests in RELEASE/NO_ASSERT firmware builds - debug builds trip an assertion instead. Net: this is a real memory-safety defect worth patching, but it is a DoS-class local issue in a niche embedded interpreter, not a widespread remotely-exploitable priority. Note the CPE is a null placeholder (cpe:2.3:a:n/a:n/a) so automated product matching is unreliable; the affected product is confirmed as Espruino only via the description and reference commits.

An attacker who can submit JavaScript to an Espruino device - for example over its serial/USB REPL, a network console, or by getting the device to eval() untrusted script - sends input containing an overlong token. Parsing the token triggers a one-byte write past the JsLex.token buffer that clobbers the adjacent tokenValue pointer, corrupting memory and crashing the interpreter (denial of service). No public exploit code has been identified; only a GitHub issue and the fix commit exist.