EUVD-2026-86471
GHSA-c28p-5mg4-7q2w
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach 64-bit Espruino JS input surface
-
DeliverySubmit JS that raises an exception
-
ExploitTrigger jsvGetLineAndCol 8-byte write into 4-byte int
-
ExecutionOverwrite adjacent stack memory
-
ImpactInterpreter crash (DoS)
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Stack buffer bounds checking
MITRE ATT&CK
1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a 64-bit build of Espruino (the vulnerability is specified as affecting 64-bit builds - the typical 32-bit microcontroller firmware is not indicated as affected), and the ability to supply JavaScript that triggers an exception reaching the error stack-trace path (jslPrintTokenLineMarker → jsvGetLineAndCol). Limiting factors: exploitation depends on the attacker having a channel to inject JS into the interpreter; on standard embedded deployments JS is loaded by the developer over USB/serial/Bluetooth rather than remotely, so genuine remote (AV:N) exploitation applies only where the interpreter is exposed to untrusted network input. Impact is constrained to a small (4-byte) stack overwrite with an attacker-uncontrolled value, realistically yielding a crash/DoS rather than code execution. |
| Impact | This is a stack-based buffer overflow (CWE-121) where jsvGetLineAndCol() performs an 8-byte write through a pointer that actually addresses a 4-byte int column variable, overwriting 4 bytes of adjacent stack memory during error stack-trace formatting. The NVD CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) scores this as a pure availability/DoS issue, which is consistent with the write value being a line/column count - the attacker has little control over what gets written, making it hard to weaponize beyond a crash. Signals converge on LOW real-world priority: EPSS is only 0.17% (6th percentile), the flaw is NOT in CISA KEV (no confirmed active exploitation), and no public exploit code is identified. One important caveat: AV:N assumes the attacker can remotely feed JavaScript to the interpreter, but Espruino is normally a microcontroller firmware fed JS over USB/serial/Bluetooth by a developer - and this bug is explicitly limited to 64-bit builds (the Linux/desktop/emulator port), not the typical 32-bit embedded target. Verify actual exposure: if the JS interpreter is not network-reachable, effective attack vector is local and remote risk is overstated. C:N/I:N are appropriate - no evidence the constrained 4-byte overwrite yields code execution or disclosure. |
| Exploit ScenarioDerived | An attacker who can submit JavaScript to a 64-bit Espruino build supplies code that throws an exception; during error stack-trace rendering, jslPrintTokenLineMarker() invokes jsvGetLineAndCol() which writes 8 bytes into a 4-byte stack int, corrupting adjacent stack memory and crashing the interpreter (denial of service). No public exploit is identified, and the overwrite value is a line/column count, so reliable code execution is unlikely. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
A stack-based buffer overflow in Espruino 2v29 (commit bffc6d0) lets an unauthenticated remote attacker crash the JavaScript interpreter by supplying script input that raises an exception and drives execution into the error stack-trace formatting path, where jslPrintTokenLineMarker() passes the address of a 4-byte int column variable to jsvGetLineAndCol(), which performs an 8-byte write through that mismatched pointer on 64-bit builds. The overwrite is small and the written value is not attacker-controlled, so the realistic outcome is a denial-of-service crash rather than code execution (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, availability impact only), and the flaw is specific to 64-bit builds - the ordinary 32-bit microcontroller firmware is not indicated as affected. Risk signals are currently low: EPSS is 0.17% (6th percentile), there is no CISA KEV entry, and no public exploit code has been identified at time of analysis, although genuine remote exploitation requires the interpreter to be reachable by untrusted input, since typical embedded deployments load JavaScript over USB, serial or Bluetooth from the developer.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed. The advisory points to the Espruino commit https://github.com/espruino/Espruino/commit/ecd7d43e084ba9aafa8245609347fe0f4383b38c, so rebuild the affected 64-bit target from source at or after that commit and verify that the resulting patch actually corrects the jsvGetLineAndCol() size_t parameter or the caller's int column variable, since the supplied diff excerpt touches jslGetTokenValueAsString() and jsvGetString() instead; the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-88388) and VulDB record (https://vuldb.com/vuln/409800) should be checked for a tagged release once one is published. As temporary compensating controls, restrict how untrusted JavaScript can reach the interpreter: do not expose the Espruino JS console, Web IDE/HTTP server or telnet interfaces to untrusted networks, keeping code upload on USB, serial or Bluetooth as intended - the trade-off is loss of remote programming and telemetry. Where 64-bit builds are used only for emulation or Linux tooling, prefer a 32-bit build, where int and size_t are both 4 bytes and the overflow does not occur, at the cost of the larger address space and workload capacity a 64-bit host provides. Building with stack-protector/stack-canary and ASLR reduces the reliability of any attacker attempt to turn the 4-byte overwrite into control-flow hijacking, but since the overwritten value is not attacker-controlled the practical impact remains a crash; disabling or stubbing the stack-trace formatting path (jslPrintTokenLineMarker/jsvGetLineAndCol) removes the vulnerable code path entirely at the cost of losing source-position details in error messages, which degrades diagnostics for developers.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is a pointer-width mismatch falling under CWE-121 (stack-based buffer overflow) in Espruino's JavaScript error stack-trace handling. In the affected code path, jslPrintTokenLineMarker() declares a column value as a 4-byte int and passes its address to jsvGetLineAndCol(), whose parameter is a size_t pointer; on a 64-bit (LP64) build a size_t is 8 bytes wide, so the callee writes 8 bytes through a pointer that only spans 4 bytes of stack memory, corrupting the adjacent 4 bytes. On 32-bit targets size_t and int are both 4 bytes, which is why the defect manifests only on 64-bit builds such as desktop/emulator/Linux ports. The type-width assumption is the classic failure mode of code written primarily for 32-bit microcontrollers and then compiled for a 64-bit host, where the error-reporting path (jslPrintTokenLineMarker -> jsvGetLineAndCol) is reached whenever a JavaScript exception is formatted with source-position information. The upstream commit referenced against this CVE (github.com/espruino/Espruino/commit/ecd7d43e084ba9aafa8245609347fe0f4383b38c) is shown in the supplied diff modifying src/jslex.c (removal of a token null-termination line in jslGetTokenValueAsString) and src/jsvar.c (jsvGetString returning len-1 instead of len); that excerpt does not itself exhibit the jsvGetLineAndCol() size_t change, so the relationship between the commit and this specific flaw should be verified against the full patch before relying on it.
Know when Espruino gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Feeding error-triggering JS needs no auth or UI and deterministically corrupts the stack (PR:N/UI:N/AC:L); constrained overwrite yields crash only, so C:N/I:N/A:H; AV:N retained but hinges on network exposure.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
3DescriptionCVE.org
Espruino 2v29 (commit bffc6d0) contains a stack-based buffer overflow vulnerability in the JavaScript error stack-trace handling path on 64-bit builds. A remote attacker can supply JavaScript input that triggers an exception and reaches jslPrintTokenLineMarker(), which passes the address of a 4-byte int column variable to jsvGetLineAndCol() as a size_t pointer. jsvGetLineAndCol() performs an 8-byte write through the mismatched pointer, overwriting adjacent stack memory.
Executive ViewAI
Espruino 2v29 (commit bffc6d0) on 64-bit builds contains a remotely triggerable memory corruption flaw that can crash the JavaScript interpreter and cause denial of service when it processes crafted script input. Organizations using 64-bit Espruino deployments that accept remote or untrusted script input are affected, while typical 32-bit microcontroller firmware is not indicated as affected. Leadership should care because a successful attack can disrupt availability of affected services or devices, and no vendor-released patch is currently identified.
No vendor-released patch identified at time of analysis. Interim mitigations: restrict remote access to Espruino script input, disable untrusted script execution, deploy input validation or sandboxing, monitor interpreter logs for crashes, and migrate to non-affected 32-bit builds where feasible.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
A stack-based buffer overflow occurs when a program writes more data to a buffer located on the stack than it was allocated to hold.
Espruino 2v11 release was discovered to contain a stack buffer overflow via src/jsvar.c in jsvGetNextSibling. Rated high
Espruino 2v11.251 was discovered to contain a stack buffer overflow via src/jsvar.c in jsvNewFromString. Rated high seve
There is a stack-based buffer over-read in the jsfNameFromString function of jsflash.c in Espruino 2V00, leading to a de
Espruino before 1.99 allows attackers to cause a denial of service (application crash) and a potential Escalation of Pri
Espruino 2v20 (commit fcc9ba4) was discovered to contain an Out-of-bounds Read via jsvStringIteratorPrintfCallback at sr
Espruino 2v20 (commit fcc9ba4) was discovered to contain a Stack Overflow via the jspeFactorFunctionCall at src/jsparse.
Espruino before 1.99 allows attackers to cause a denial of service (application crash) and a potential Information Discl
Espruino before 1.99 allows attackers to cause a denial of service (application crash) and potential Information Disclos
Espruino before 1.99 allows attackers to cause a denial of service (application crash) with a user crafted input file vi
Espruino before 1.98 allows attackers to cause a denial of service (application crash) with a user crafted input file vi
Espruino before 1.98 allows attackers to cause a denial of service (application crash) with a user crafted input file vi
Espruino before 1.99 allows attackers to cause a denial of service (application crash) with a user crafted input file vi
Exploit-DB