rlottie CVE-2026-47306

Exploitation specifically requires that the target application renders a Lottie animation file containing at least one circular precomposition asset reference - two or more entries in the animation's assets array where mPreCompRefId fields form a directed cycle. The CVSS vector confirms user interaction is required (UI:R): a user must open, load, or trigger rendering of the malicious file; passive network exposure is not sufficient. The attack vector is local (AV:L), meaning the file must be present on the local filesystem or accessible to the rendering process at execution time. No privileges are required (PR:N) to open a file. Exploitation is limited to applications that: (1) use a vulnerable rlottie build predating commit e2d19e3b, (2) accept Lottie files from attacker-influenced sources, and (3) invoke the lottie asset parser against those files. Applications that render only embedded, developer-controlled Lottie assets with no user-supplied file input are not realistically at risk. The 'Information Disclosure' tag is inconsistent with CVSS C:N - information disclosure has not been confirmed as an exploitation condition or outcome.

The CVSS 6.1 Medium score reflects meaningful but constrained real-world risk. The local attack vector (AV:L) and required user interaction (UI:R) are the most significant limiting factors - a remote, unauthenticated attacker cannot trigger this without first delivering a malicious file and inducing a user to open it. The high availability impact (A:H) represents a full crash of the rendering process, and the low integrity impact (I:L) may reflect memory state corruption prior to termination. EPSS data was not provided, so probabilistic exploitation likelihood cannot be quantified. The vulnerability is not in CISA KEV, indicating no confirmed mass or targeted active exploitation at time of analysis. Notably, the 'Information Disclosure' tag in the source reporting conflicts directly with the CVSS C:N (no confidentiality impact) vector - this discrepancy should be verified with the original reporter before classifying this as a data-exposure risk. For applications embedding rlottie that accept Lottie files from untrusted or user-supplied sources (e.g., animated sticker platforms, content management tools, TV app frameworks), real-world risk is elevated relative to the raw score.

An attacker crafts a Lottie JSON animation file in which two or more assets in the assets array contain precomp layer references forming a cycle - for example, comp_A includes a precomp layer referencing comp_B, and comp_B includes a precomp layer referencing comp_A. The file is delivered to a target user via email attachment, a web download, or embedded content in an application that uses a vulnerable rlottie build. When the user opens the file or the application attempts to render the animation, the rlottie parser begins recursively resolving asset dependencies without bound, exhausts the call stack, and crashes the host process. The public PR diff at https://github.com/Samsung/rlottie/pull/585 documents the exact vulnerable code path, providing sufficient technical detail for exploit construction even in the absence of a standalone proof-of-concept.