3 min read

Telegram rlottie vulnerability: zero-click remains in question

TelegramrlottieCVE-2026-111105

CVE-2026-111105 affects Telegram's rlottie library. Integer truncation may enable a write before an allocated buffer, causing memory corruption and potentially code execution. Available reports, however, require user interaction, so the claim that a sticker compromises an account immediately after delivery remains unconfirmed.

What was actually found in rlottie

I would not describe CVE-2026-111105 as a confirmed zero-click sticker attack. The CVE description and Zero Day Initiative advisory ZDI-26-757 identify a serious memory-safety flaw, but exploitation is said to require user interaction, such as opening a malicious file or page.

The issue lies in rlottie, the library Telegram uses to render animations. Integer truncation can allow attacker-controlled data to trigger a write before the start of an allocated buffer. The potential impact is severe: memory corruption or arbitrary code execution within the Telegram process.

However, there is a substantial exploitation chain between that primitive and a claim that an account is stolen as soon as a sticker arrives. The available descriptions do not confirm that exploitation works without opening a chat, file, or page. As of November 4, 2026, the cited materials also do not name a specific fixed client version.

Older vulnerabilities in the same component add to the confusion. CVE-2021-31323 involved a buffer overflow while parsing dash elements, while CVE-2021-31319 concerned an integer overflow and an out-of-bounds read. They affected Telegram for Android before 7.1.0 (2090), iOS before 7.1, and macOS before 7.1.

Those flaws were indeed linked to malicious animated stickers in Secret Chats, where server-side filtering was not applied. Yet victims generally still had to open the chat, so that scenario was not a genuine zero-click attack either.

Why the wording matters

My conclusion is straightforward: the vulnerability is real and serious, while viral descriptions of how it works currently go beyond the evidence. An out-of-bounds memory write deserves attention without adding an unverified automatic-account-compromise scenario.

In an engineering assessment, I would separate three questions: which platforms and versions are affected, what action triggers processing, and whether a publicly confirmed code-execution chain exists. Current materials answer only some of those questions with confidence. A statement about server-side validation mentioned in one report is not the same as a client-side fix.

Updating Telegram remains sensible, but it does not turn a rumor into a technical fact, especially while no patched version number has been published. This is a serious memory-safety issue, but a sticker that compromises an account merely by being delivered has not yet been demonstrated in the available data.

We previously covered how security alerts and account controls can expose risks in API-driven environments. The same discipline around monitoring and access separation matters when a messaging-platform flaw can compromise an account without user interaction.