MEDIUM 6.1

CVE-2026-47306: rlottie Uncontrolled Recursion Denial-of-Service Vulnerability

Samsung's rlottie library contains a flaw that allows specially crafted animation files to trigger uncontrolled recursion. When processing oversized serialized data payloads, the library fails to properly limit recursion depth, which can exhaust system resources and crash applications that depend on it. The vulnerability requires user interaction—a user must open or process a malicious animation file—but once triggered, it reliably denies service to the affected application.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.1 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H
Weaknesses (CWE)
CWE-674
Affected products
0 configuration(s)
Published / Modified
2026-06-04 / 2026-06-17

NVD description (verbatim)

Uncontrolled Recursion vulnerability in Samsung Open Source rlottie allows Oversized Serialized Data Payloads. This issue affects rlottie: before e2d19e3b150e0e4a9586fa90b56fd3061cc98945.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-47306 is an uncontrolled recursion vulnerability (CWE-674) in rlottie, Samsung's open-source animation rendering library. The flaw exists in the parsing and deserialization logic when handling oversized payloads. The recursion mechanism lacks adequate depth guards, allowing an attacker to craft a Lottie animation file that, upon deserialization, causes the parser to recurse infinitely or until stack exhaustion. The vulnerability was resolved in commit e2d19e3b150e0e4a9586fa90b56fd3061cc98945. CVSS 3.1 score of 6.1 reflects the local attack vector and high availability impact combined with low integrity risk.

Business impact

Applications embedding rlottie for animation playback face denial-of-service risk. Mobile apps, UI frameworks, and media players that process user-supplied or untrusted Lottie files can be crashed by a single malicious payload. While integrity and confidentiality are not compromised, availability damage can degrade user experience and, in automated environments, disrupt service continuity. Organizations relying on rlottie in customer-facing or backend animation processing should assess whether user-submitted animation files are part of their threat model.

Affected systems

Samsung rlottie library versions prior to commit e2d19e3b150e0e4a9586fa90b56fd3061cc98945 are vulnerable. This includes any application or framework that vendors rlottie for animation rendering. The scope is local; the attack surface is limited to systems that parse untrusted Lottie animation files. No specific downstream products or version numbers have been disclosed as affected; vendors and product teams must verify their own rlottie dependency versions.

Exploitability

Exploitability is straightforward for an attacker with the ability to supply a crafted Lottie file to a vulnerable application. The attack requires user interaction—a user must open, import, or process the malicious animation. No authentication, elevated privileges, or network access is required. The CVSS vector (AV:L/AC:L/PR:N/UI:R) confirms low complexity; once a user encounters the payload, crash is likely. However, active wild exploitation has not been reported, and the vulnerability is not on the CISA KEV list.

Remediation

Update rlottie to the patched version incorporating commit e2d19e3b150e0e4a9586fa90b56fd3061cc98945 or later. Organizations should verify their dependency tree to identify all products and services embedding rlottie and coordinate updates accordingly. For applications that accept user-supplied animation files, input validation and sandboxing of the parsing process can reduce impact while patches are deployed.

Patch guidance

Identify all instances of rlottie in your codebase via dependency scanning tools. Contact your library or framework vendor to confirm the patched version availability for your deployment context (web, mobile, embedded). The fix addresses recursion depth validation; confirm patch notes explicitly mention CWE-674 remediation. Test patches in a staging environment with existing Lottie file workflows before production rollout. If you are a vendor integrating rlottie, publish guidance for your customers on required updates and timelines.

Detection guidance

Monitor for application crashes or high CPU usage coinciding with animation file processing or Lottie imports. Stack traces showing recursive function calls within rlottie's parsing layers are indicative. In memory-constrained environments (mobile, IoT), monitor for out-of-memory errors during animation load. If forensic analysis is possible, examine the triggering animation file for unusual recursion patterns or excessive payload sizes. Intrusion detection signatures should flag unusually large or deeply nested JSON structures in .json Lottie files if scanned at ingestion.

Why prioritize this

CVSS 6.1 (MEDIUM) reflects high availability impact offset by local attack surface and user interaction requirement. Prioritize based on your use of rlottie and exposure to untrusted animation sources. If rlottie is embedded in customer-facing mobile apps or web tools accepting user uploads, treat as high priority within your patch cycle. If rlottie use is limited to internal, trusted animation assets, prioritization can be moderate. The absence of KEV listing and active wild exploitation suggests this is not an immediate nation-state or ransomware vector, but should not be deprioritized indefinitely.

Risk score, explained

The CVSS 3.1 score of 6.1 (MEDIUM) is driven by: (1) high availability impact (A:H)—confirmed crash and service disruption—balanced against (2) no confidentiality or integrity breach (C:N/I:L), and (3) local attack surface (AV:L) requiring a user to process the file (UI:R). The score appropriately reflects a denial-of-service risk that is serious for availability-critical services but does not expose data or enable privilege escalation. Organizational risk may be higher if animation processing is part of a critical pipeline.

Frequently asked questions

Do I need to patch if I only use rlottie with internal, trusted animation files?

Not urgently, but yes eventually. The attack requires a malicious animation file to be processed. If your animation sources are entirely internal and not user-supplied, your exposure is minimal. However, supply chain scenarios (third-party animation libraries, templates, or collaborator uploads) can introduce untrusted files. Plan a routine update cycle.

Which applications or products are known to be affected?

The CVE record does not list specific downstream products. rlottie is an open-source library used by various mobile frameworks, web animation tools, and embedded systems. Check your dependency manifests (package.json, gradle, CocoaPods, etc.) for rlottie references and consult your vendor's security advisories for confirmed affected versions.

What is the difference between this and a memory leak or buffer overflow?

This vulnerability is uncontrolled recursion—the parser calls itself repeatedly without a depth limit, exhausting stack space. Unlike buffer overflows, it doesn't corrupt memory or enable code execution. The result is a controlled crash (denial-of-service) rather than arbitrary code execution. Mitigation focuses on preventing the recursion trigger, not hardening memory layout.

Is there a workaround if I cannot patch immediately?

Implement input validation: reject Lottie files exceeding a reasonable size threshold and validate JSON nesting depth before passing to rlottie. Sandbox the parsing process (e.g., in a subprocess or container) so a crash does not take down the entire application. Monitor for crashes and user-facing failures. These are temporary measures; patching is the permanent solution.

This analysis is based on published CVE data and security best practices. No exploit code or proof-of-concept is provided. Patch timelines and product-specific impact are determined by your vendor and your dependency audit; verify your rlottie version against the patched commit hash. CVSS scores are based on the official NVD record; organizational risk may differ based on deployment context and threat model. This document is not a substitute for vendor advisories or your own security assessment. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).