Escargot (Samsung Open Source) is affected by CVE-2026-47309, a “Uncontrolled Recursion” issue triggered by oversized serialized data payloads. The affected codebase is identified as commit/version: 590345cc6258317c5da850d846ce6baaf2afc2d3. In plain terms, when Escargot processes certain serialized inputs that contain very large/oversized array data, it can enter uncontrolled recursive behavior that ultimately leads to a denial of service (availability impact). The CVSS score is 5.5 (medium) with an attack vector of LOCAL and no required privileges (PR:N), but user interaction is required (UI:R).
Technically, the vulnerability is rooted in uncontrolled recursion during deserialization/processing of serialized structures, specifically involving array sizing/handling logic. The provided reference (Samsung/escargot PR #1565) includes notes indicating that “setArrayLength can convert the array to non-fast mode when length exceeds thresholds,” and additional logic around index handling “within the string length due to proxy object.” While the scraped content does not include full code excerpts or the exact recursion loop, the PR context strongly suggests that large length values in serialized payloads can drive Escargot into a slower/non-fast array representation path and/or repeated processing that can recurse without adequate bounds/termination.
Impact-wise, the CVSS vector indicates no confidentiality or integrity impact (C:N, I:N) and an availability impact (A:H). With CVSS 5.5 (medium), an attacker can cause the Escargot component to consume excessive resources or crash due to uncontrolled recursion when handling oversized serialized data. The attack vector is LOCAL and requires user interaction (UI:R), meaning exploitation likely depends on a local user or application flow that feeds serialized data into Escargot. The blast radius is therefore limited to environments where untrusted serialized payloads can be supplied to the affected Escargot processing path.
Mitigation: apply the fix from Samsung’s escargot pull request #1565 (referenced in the provided material). The scraped reference indicates changes related to array length handling thresholds (e.g., behavior in setArrayLength when length exceeds thresholds) and related index/proxy handling. If patching is not immediately possible, reduce exposure by ensuring that applications do not accept or process untrusted serialized payloads containing attacker-controlled oversized array lengths, and add input validation/size limits before passing data into Escargot. Detection guidance is limited by the provided content, but monitoring for crashes or hangs in code paths that deserialize/process arrays—especially when array lengths exceed expected thresholds—can help identify attempted exploitation.
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
CWE-674