rlottie CVE-2026-19588

Exploitation requires that a user or application actively trigger rendering of a crafted Lottie animation file, which is reflected in the CVSS UI:R metric. The attacker requires no authentication (PR:N) but must successfully deliver the malicious animation file to an application that passes its width and depth values through rlottie's bitmap allocation path. No special non-default configuration is required; any rlottie deployment that processes externally supplied or user-provided animation files is vulnerable by default. Exploitation is concretely limited by the user-interaction requirement (the file must be rendered, not merely received or stored) and by the absence of confirmed heap exploitation primitives beyond crash (CVSS C:N/I:N). Platform-level mitigations such as ASLR and safe heap unlinking further constrain potential escalation beyond denial-of-service on hardened targets.

The CVSS 6.5 Medium score accurately reflects an availability-only impact (A:H, C:N, I:N) with no attacker privileges required (PR:N) but mandatory user interaction (UI:R), placing this squarely in the category of exploitable-but-gated denial-of-service. No EPSS score was provided in available data, and the vulnerability does not appear in CISA KEV, so exploitation probability cannot be quantified and active exploitation is not confirmed. That said, even a mid-sized municipal IT team in sopot managing a fleet of Tizen-based Smart TVs or embedded kiosk devices that render Lottie content from external sources should treat this as a meaningful availability risk, particularly since heap buffer overflows can produce reliable crashes and may - in certain runtime environments without strong heap mitigations - escalate beyond the conservative C:N/I:N metrics the reporter assigned. The UI:R requirement is the primary real-world mitigating factor: exploitation cannot occur without a user or application actively triggering render of the malicious file. Absence of EPSS data and POC code means exploitation likelihood cannot be independently corroborated; the risk picture would sharpen considerably if a tagged upstream release incorporating the fix were available to compare against deployed versions.

An attacker crafts a malicious Lottie JSON animation file containing extreme bitmap dimension values - for example, a width large enough that mWidth * mDepth overflows uint32_t - and delivers it to a victim via a web page, email attachment, or embedded media link. When a user opens the file or the application automatically renders the animation, rlottie's vbitmap allocator produces a heap buffer far smaller than the actual pixel data, and the subsequent write crashes the host process. No public proof-of-concept code has been identified at time of analysis; however, the attack requires only crafting a valid-looking Lottie JSON with oversized dimension fields, which requires no specialized tooling.