CVE-2025-0634 is a critical use after free (CVSS 9.8) in Samsung Open Source rLottie, affecting version 0.2. A fix commit adds validation for malicious Lottie files. If you build or bundle rLottie, update to code that includes that commit and rebuild.
What's affected
- Product: Samsung Open Source rLottie, a C++ library that renders Lottie vector animations.
- Affected version in the record: V0.2.
- Weakness: CWE-416, use after free.
- Fix: commit
507ea027e47d3e1dc7ddbd9994621215eae7ebb9, linked from the record along with pull request 571 in the Samsung rlottie repository. - Release number that first contains the fix: not confirmed. Check the project's releases and tags before relying on a version number.
- CISA KEV: not listed.
The NVD text says the flaw "allows Remote Code Inclusion". The CVSS vector is network, low complexity, no privileges and no user interaction, with high impact on confidentiality, integrity and availability. That is the basis for the 9.8 score. The practical risk depends on whether your application hands untrusted animation files to rLottie.
How to check if you're exposed
rLottie is usually compiled into something else, so the library rarely shows up as a package you installed on purpose.
- Search your repositories and build trees for
rlottie, including vendored copies, git submodules and CMake fetch steps. - Check Linux distribution packages with your package manager, for example
dpkg -l | grep -i rlottieon Debian based systems orrpm -qa | grep -i rlottieon RPM based ones. - Look in app bundles and firmware for a shared library named like
librlottie. - If you use Lottie animations from users, ads, chat stickers or third party content, note where those files are parsed. That is the exposure path.
- For a dependency list of a project, you can run the free in-browser dependency scan. Vendored C++ sources are easy to miss in any scanner, so a manual search still pays off.
What to do now
- Find every product you ship or run that embeds rLottie.
- Move to a version or source revision that contains commit
507ea027. Rebuild and redeploy, since a static or vendored copy does not update itself. - Until then, stop rendering Lottie files from untrusted sources, or render them in a separate low privilege process.
- Run rendering code with the fewest rights it needs, and enable your platform's memory protections.
- Record the library and its version in your inventory so the next advisory is a lookup, not a hunt.
Why it matters
A use after free happens when code keeps using memory after it has been released. If an attacker can influence what ends up in that memory, the program may behave in ways its authors never intended, and in the worst case run attacker chosen code. Renderers are a classic place for this, because they parse complex, untrusted file formats in native code.
The fix commit message describes validation checks for the case of a malicious Lottie file. It adds a type check before casting a layer, bounds checking in gradient handling, a check for an empty frames vector and rejection of outliers. Those are the kind of checks that turn a crafted file into a harmless error. The commit message and the record do not describe any real world attack, and the CVE is not in the KEV catalog.
This is where reachability analysis earns its keep. Many apps contain rLottie but never parse files from outside. Knowing which ones do tells you what to patch first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version of rLottie fixes CVE-2025-0634?
The record names affected version 0.2 and links a fix commit. It does not state a fixed release number. Use code that includes commit 507ea027 and check the project's releases.
Do I need to patch if I only ship static animations I made myself?
The risk comes from parsing a malicious Lottie file. If every file is trusted and under your control, exposure is much lower, but updating is still the safer course.
Sources
Last reviewed: 19 October 2026.
