What is the CVSS score of EUVD-2026-32679?

EUVD-2026-32679 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Samsung Escargot are affected by EUVD-2026-32679?

A memory corruption vulnerability (CVE-2026-8915, CVSS 8.8) in Samsung's Escargot JavaScript engine permits remote code execution through malicious scripts exploiting ArrayBuffer operations; no…

How to fix or mitigate EUVD-2026-32679?

Within 24 hours: Inventory all Samsung devices running Escargot across corporate infrastructure (smart TVs, IoT devices, set-top boxes, signage systems). Within 7 days: Contact Samsung for confirmed patch timeline and security advisories; implement content validation and code signing controls where feasible. Within 30 days: Develop device remediation strategy (replacement, firmware update upon release, or network isolation); enable continuous monitoring for related exploits and patch announcements via CISA and Samsung channels.

Samsung Escargot EUVD-2026-32679

| CVE-2026-8915 HIGH

Out-of-bounds Write (CWE-787)

2026-05-28 samsung.tv_appliance

GHSA-h78v-r6mm-5vwf

Memory Corruption Samsung Buffer Overflow

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 28, 2026 - 00:26 vuln.today

Analysis Generated

May 28, 2026 - 00:26 vuln.today

DescriptionCVE.org

Out-of-bounds write vulnerability in Samsung Open Source Escargot allows Overflow Buffers.

This issue affects Escargot: 36f5fb58366a67b713c02f6fd985e924fcc09e31.

AnalysisAI

Out-of-bounds write in Samsung's Escargot JavaScript engine allows attacker-supplied scripts to corrupt memory through the ArrayBuffer.prototype.transfer() built-in, with high confidentiality, integrity, and availability impact (CVSS 8.8). The flaw stems from a missing length-bounds check when transferring an ArrayBuffer to a new byte length, enabling writes past the allocated buffer that can lead to remote code execution if a victim runs the malicious script. No public exploit has been identified at time of analysis, and no EPSS or CISA KEV data was provided.

Technical ContextAI

Escargot (cpe:2.3:a:samsung_open_source:escargot) is Samsung's lightweight, memory-efficient ECMAScript engine designed for embedded and resource-constrained environments such as IoT devices and Tizen/smart-TV appliances (consistent with the 'samsung.tv_appliance' reporter). The root cause is CWE-787 (Out-of-bounds Write), located in the ArrayBuffer.prototype.transfer implementation in src/builtins/BuiltinArrayBuffer.cpp (builtinArrayBufferTransfer). Per the PR #1579 diff, the vulnerable code failed to (1) re-check for a detached buffer and (2) validate that the requested newByteLength does not exceed the buffer's maxLength before performing the transfer/copy. The fix adds throwTypeErrorIfDetached() and a RangeError when newByteLength > maxLength, preventing the engine from copying or sizing beyond the legitimate buffer bounds.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - rebuild or update Escargot to a revision that incorporates the merge of https://github.com/Samsung/escargot/pull/1579, which adds the detached-buffer check and the newByteLength-versus-maxLength RangeError guard in src/builtins/BuiltinArrayBuffer.cpp. Because no tagged patched release version is present in the provided data, integrators embedding Escargot should pull the fixed commit directly and recompile downstream products. Where immediate patching is not possible, the most effective compensating control is to restrict the engine to trusted JavaScript only and avoid executing untrusted/remote script content (trade-off: breaks any feature relying on third-party or dynamically loaded scripts); if the runtime exposes a configuration hook, disabling or shimming ArrayBuffer.prototype.transfer would remove the vulnerable path at the cost of breaking legitimate transfer/resizable-ArrayBuffer functionality.