// 1 CRITICAL · 1 ZERO-DAY · 2 CVE · 4 EXPLOIT IN THE LAST 24H
A short-vs-int type error in Samsung's rlottie graphics library enables remote code execution through a malicious animation file. A patch is available in the open-source repository.

On June 22, 2026, the Zero Day Initiative published advisory ZDI-26-359, documenting a remote code execution vulnerability in Samsung's rlottie library. The flaw stems from an integer truncation in graphics structure counters: data types declared as short (16-bit) instead of int (32-bit) allow overflow when the parser processes malformed user-supplied data. The result is an out-of-bounds write and memory corruption, leading to arbitrary code execution in the context of the current process. Samsung fixed the defect on May 12, 2026, via an open-source pull request on GitHub, a month ahead of coordinated disclosure.

Key Takeaways
  • Advisory ZDI-26-359 confirms an RCE vulnerability in Samsung rlottie caused by missing validation of user-supplied data, resulting in integer truncation before a memory write.
  • The open-source patch, merged on May 12, 2026, promotes point/contour counter types from short to int across three files in the vector rendering engine.
  • Researcher Michael DePlante (@izobashi) reported the flaw on April 1, 2026; coordinated public disclosure occurred on June 11, 2026.
  • No CVE identifier, CVSS score, or specific vulnerable rlottie versions are declared in the advisory.

The Bug: When a 'short' Falls Short

Samsung's rlottie library renders animations in the Lottie format, a JSON-based vector format popular in mobile, web, and desktop apps for its lightweight scalability. The underlying rendering engine, derived from FreeType, manipulates data structures describing vector shape contours and points. In the SW_FT_Outline structure, contour and point counters were declared as short, signed 16-bit integers with a maximum range of 32,767 values.

When the rlottie parser receives unvalidated user data — for example, a crafted Lottie animation file — values exceeding that range trigger integer truncation: the value is silently truncated, losing high-order bits. The result is an apparently valid but numerically incorrect count, causing the renderer to write past the bounds of the allocated array. ZDI describes this mechanism as "integer truncation before writing to memory," with code execution in the context of the process as the end result.

Pull request #589 on GitHub, opened by mihashco and merged into Samsung's master branch on May 12, 2026, resolves the issue with a systematic type change. The n_contours and n_points fields change from short to int, as does the contours pointer from short* to int*. The file v_ft_stroker.cpp requires corresponding cast updates, from (short) to (int). The commit message is blunt: "fixed integer overflow in SW_FT_Outline point/contour counters."

The Timeline: Three Months from Report to Patch, One Month to Disclosure

Coordination between researcher and vendor followed the standard Zero Day Initiative model. Michael DePlante, researcher under handle @izobashi, submitted the report on April 1, 2026. Samsung integrated the fix into the public repository on May 12, 2026, without issuing its own advisory: ZDI's publication on June 11, 2026, represented the first coordinated public disclosure of the issue.

This 72-day interval between report and patch, and a further 30 days before disclosure, is consistent with coordinated vulnerability disclosure practices. However, the absence of a Samsung advisory means developers integrating rlottie via package distributions or submodules received no automatic notification: visibility depends entirely on monitoring the GitHub repository or consulting the ZDI advisory.

Advisory ZDI-26-359 does not specify which rlottie versions are affected, nor does it list Samsung or third-party products incorporating the vulnerable library. rlottie is used in Samsung system apps, messaging clients supporting animated stickers, and potentially in third-party apps that adopted the library for Lottie rendering. The variability of attack vectors — "attack vectors may vary depending on the implementation," as ZDI notes — makes it impossible to quantify exposure without an inventory of implementations.

Analysis: A Typical Declaration Error with Atypical Consequences

Integer truncation and overflow are staples of C/C++ programming in fixed-width type systems, but the severity of this flaw lies in the execution context. The rlottie library processes untrusted user data — animation files downloaded from the network, received in chat, opened by browsers. The parser is a natural attack surface: the user need take no explicit installation action; simply viewing the content is sufficient.

The library's open-source nature doubled the problem. On one hand, the public repository allowed anyone to study the code and identify the vulnerable pattern; on the other, it made the patch immediately verifiable and integrable. Samsung's decision not to issue its own CVE or separate security advisory leaves a gap in formal tracking: developers and security teams relying on CVE feeds or the NVD will find no independent record of this flaw, only the ZDI reference.

The choice to promote types to int rather than add explicit bounds checks is technically significant. Expanding the numeric space eliminates the overflow condition for realistically craftable inputs, but does not introduce semantic validation: a Lottie file declaring billions of points could still cause denial-of-service through excessive memory allocation. The patch is corrective, not defense-in-depth.

"The issue results from the lack of proper validation of user-supplied data, which can result in an integer truncation before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the current process." — ZDI Advisory ZDI-26-359

What to Do Now

For developers integrating rlottie, the priority is verifying the version in use against commit dcfde72eae1b0464dc0dd760aec00ada6a148635 of pull request #589, merged on May 12, 2026. Distributions that include rlottie as a submodule or dependency must be updated with the post-merge code.

Operators of apps processing Lottie animations from user sources should implement sandboxing of the graphics parser where architecture permits: isolating rlottie in a separate process with minimal privileges reduces the impact of potential future vulnerabilities of this class. Parsing complex media files in a privileged process remains a recognized security anti-pattern.

For security teams, the ZDI advisory should be added to monitoring despite the lack of a CVE: the RCE severity and ease of user interaction demand active tracking. Verifying the potential presence of rlottie in internal software inventory, via dependency scanning or composition analysis, is necessary to quantify organizational exposure.

Anyone receiving Lottie animations from unverified contacts — particularly in messaging clients using animated stickers — should consider that automatic preview represents a concrete attack vector for this class of vulnerability. Disabling automatic media preview from unknown sources, where the app allows, reduces the exposure surface independent of the specific patch.

Why the rlottie Case Matters Beyond Samsung

The relevance of ZDI-26-359 transcends a single vendor. Lottie has become a de facto format for animated UI, with implementations in Adobe After Effects, Telegram, WhatsApp, and cross-platform frameworks. Samsung's rlottie library, while not the only implementation, is among the most performant for resource-constrained mobile devices. Its adoption in ecosystems beyond Samsung's direct control creates an invisible dependency chain for end users.

The case also highlights a gap in the disclosure cycle: without an assigned CVE and with no vendor advisory, the vulnerability risks remaining invisible to standard IT asset management tools. ZDI serves as the primary documentation source, but its nature as an independent aggregator does not replace the vendor's formal tracking process. For developers integrating open-source code, the operational lesson is that security depends as much on patch management quality as on disclosure channel visibility.

The fix — a three-letter type declaration change repeated across three files — took months of coordination to become public. The technical simplicity of the fix contrasts with the complexity of its deployment: thousands of potentially affected apps, no automatic update mechanism, no security release version. The problem in 2026 is no longer bug discovery, but the certainty that fixes reach production code.

Frequently Asked Questions

Do I need to update my Samsung phone to be protected?
The ZDI advisory does not specify which Samsung products integrate the vulnerable rlottie version, nor whether Samsung system updates already contain the patch. The only certainty is the fix's availability in the open-source repository since May 12, 2026.

Does the vulnerability require the user to open a specific file?
According to the ZDI advisory, "interaction with the rlottie library is required to exploit this vulnerability but attack vectors may vary depending on the implementation." Simply viewing a Lottie animation in an app using rlottie is sufficient; the user does not necessarily need to open a file as an explicit attachment.

Why was no CVE assigned?
The dossier documents no CVE assigned to ZDI-26-359. ZDI can request CVEs during disclosure, but the absence in the extracted advisory text indicates none is available in the public format. This does not mean one does not exist, only that it is not reported in accessible sources.

Information verified against cited sources and current as of publication.

Sources


Sources and references
  1. zerodayinitiative.com
  2. github.com