What is the CVSS score of CVE-2026-47316?

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

Samsung Escargot CVE-2026-47316

EUVD-2026-30846 MEDIUM

Improper Check or Handling of Exceptional Conditions (CWE-703)

2026-05-19 samsung.tv_appliance

GHSA-9726-5rh7-2mr9

Information Disclosure Samsung

5.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

5.5 MEDIUM

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

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

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

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 19, 2026 - 08:33 vuln.today

Analysis Generated

May 19, 2026 - 08:33 vuln.today

DescriptionCVE.org

Improper Check or Handling of Exceptional Conditions vulnerability in Samsung Open Source Escargot allows Input Data Manipulation.

This issue affects Escargot: 590345cc6258317c5da850d846ce6baaf2afc2d3.

AnalysisAI

Denial of service in Samsung Escargot JavaScript engine at commit 590345cc6258317c5da850d846ce6baaf2afc2d3 stems from multiple improper exceptional-condition handling paths exposed during JavaScript execution: a null pointer dereference when resolving error values in nested eval/throw/finally scenarios, an integer underflow in TypedArray.copyWithin() triggered by resizable ArrayBuffer coercion, and an unguarded assertion failure when array objects transition unexpectedly from fast to slow mode. Attack vector is local and requires user interaction (UI:R), with impact confined entirely to availability - crashing the host process. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.

Technical ContextAI

Escargot is Samsung's open-source embeddable JavaScript engine, commonly used in Samsung smart TV and IoT appliance contexts (reporter tagged as samsung.tv_appliance). The root cause class is CWE-703 (Improper Check or Handling of Exceptional Conditions), and the PR #1565 diff reveals at least four distinct failure paths. First, EscargotPublic.cpp lacked a null guard before dereferencing error.value() in resultOrErrorToString(), which can be invalid during nested eval() with throw inside a finally block that triggers GC allocation. Second, BuiltinTypedArray.cpp computed copy counts for TypedArray.copyWithin() without clamping: after a ResizableArrayBuffer is resized during argument coercion, the expression len - startIndex or len - targetIndex can go negative, and casting a negative double to size_t produces an enormous value causing an out-of-bounds operation. Third, ByteCodeInterpreter.cpp assumed via ASSERT that an array remains in fast mode after setArrayLength(), but setArrayLength() can silently demote arrays to slow mode when thresholds are exceeded, causing an assertion failure in debug builds and undefined behavior in release builds. Fourth, Heap.cpp had no deterministic out-of-memory handler; the fix installs a GC OOM callback that calls abort() for predictable failure. The CPE is cpe:2.3:a:samsung_open_source:escargot:*:*:*:*:*:*:*:* at the specific affected commit.

RemediationAI

Apply the upstream fix available in GitHub PR #1565 at https://github.com/Samsung/escargot/pull/1565, which patches all four identified exceptional-condition handling defects. Note that this is a pull request or commit-level fix; a tagged stable release incorporating this patch has not been independently confirmed at time of analysis, so organizations building Escargot from source should cherry-pick or merge PR #1565 directly. As a compensating control where patching is not immediately possible, restrict the Escargot embedding process to execute only trusted JavaScript and run the embedding process in an isolated sandbox (e.g., a separate process or container) so that a crash does not propagate to critical system components - this limits the blast radius of the availability impact but does not prevent the crash itself. Disabling user-controlled JavaScript input to Escargot-hosted features until patched is the most effective interim measure.