Samsung Escargot CVE-2026-8915

Exploitation requires that the target application embedding Escargot execute attacker-controlled JavaScript (UI:R - the user must load or run the malicious script), and the engine build must predate the PR #1579 fix (vulnerable commit 36f5fb58366a67b713c02f6fd985e924fcc09e31). The concrete trigger is a call to ArrayBuffer.prototype.transfer() with a requested new byte length that exceeds the buffer's maxLength (or against a detached buffer), reaching the unguarded code in builtinArrayBufferTransfer. No authentication is required (PR:N), and attack complexity is low (AC:L). The limiting factors that reduce realistic risk are the mandatory user interaction and the requirement that the deployment actually runs untrusted JavaScript - environments executing only trusted first-party scripts are not practically exposed.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 8.8) indicates a low-complexity, unauthenticated attack that delivers attacker-controlled script content over the network but requires user interaction - the victim must execute the malicious JavaScript in an Escargot-based application. The triad of C:H/I:H/A:H reflects the memory-corruption potential typical of OOB writes in a JS engine. However, key prioritization signals are missing: no EPSS exploitation-probability score was provided, the CVE is not listed in CISA KEV (so this is not confirmed active exploitation), and the only public reference is the upstream fix PR rather than working exploit code. Real-world risk is therefore driven by exposure rather than confirmed weaponization: deployments that execute untrusted JavaScript (e.g., embedded browsers, app runtimes on TVs/IoT) face meaningful risk, whereas systems running only trusted first-party scripts are largely insulated by the UI:R requirement. Note a nuance worth verifying: AV:N here means the malicious script is network-delivered, but actual triggering depends on the target choosing to run that script (UI:R), so it is not a purely passive remote compromise.

An attacker crafts a malicious web page or application payload containing JavaScript that calls ArrayBuffer.prototype.transfer() with a manipulated length exceeding the buffer's maximum, then lures a user to open it in an Escargot-powered application (the UI:R requirement). When the script runs, the missing bounds check causes a write past the allocated buffer, corrupting heap memory and potentially leading to arbitrary code execution within the application's process. No public proof-of-concept exploit code has been identified at time of analysis.