One Click, One Account: Telegram Desktop's Silent Takeover

Someone adds you to a Telegram group. A link appears in the chat. You click it. Your Telegram account is no longer only yours [1].

That is not a hypothetical. It is CVE-2026-107181, a vulnerability in Telegram Desktop that scored 8.1 on the CVSS scale and allowed arbitrary file read and account takeover from a single clicked link. BeakSec published the full writeup this week, and it is one of the cleanest vulnerability chains I have read in a while [2].

Two bugs, one chain

The attack strings together two defects. Neither is catastrophic on its own. Together they are devastating.

The first is an IPC injection. When Telegram Desktop is already running and you click a tg:// link, the operating system launches a second Telegram process. That process connects to the running one over a local socket and sends the URL as text. The format is simple: each instruction is a keyword, an argument, and a semicolon separator.

The problem: the semicolon is never escaped. If the URL itself contains a semicolon, the receiving instance cannot tell the difference between data and delimiter. A crafted link like tg://x?a=1;CMD:quit arrives as two instructions instead of one. That is the injection [3].

The second defect is what the injection reaches. Telegram has an internal URI scheme called interpret: that was built for publishing release archives. It reads a text file from disk and sends whatever file that text file names to a chat, with no confirmation dialog and no authorization check. The function never asks who requested it [4].

So: inject OPEN:interpret: through the socket, point it at an instruction file, and the instruction file tells Telegram to send any local file to any chat. Arbitrary file read, from a link.

Getting the file on disk

The attacker needs an instruction file on the victim's machine at a predictable path. Telegram Desktop auto-downloads files received in groups, up to 8 MiB, to a standard folder. So the attacker posts the instruction file to the group before sending the link. It lands on disk without the victim clicking anything [5].

The path has one unknown: the Windows username. But interpret: accepts relative paths, resolved from Telegram's working directory. A relative path like ../../../Downloads/Telegram%20Desktop/instructions.txt gives a deterministic location without ever needing the username.

From file read to account takeover

Arbitrary file read is bad. Arbitrary file read on an encrypted messaging client is worse. Telegram stores session authorization data locally, encrypted with a key derived from a local passcode. If no passcode is set, which is the default, the key derivation uses the empty string and a salt stored in the clear next to the encrypted key. Reading one file, tdata/key_datas, is enough to recompute the decryption key and unwrap everything else [6].

Three files total: the salt and encrypted DEK, the MTProto authorization, and an index. The folder name is derived from the string "data" and is identical on every installation. An attacker who grabs all three can drop them into a fresh tdata directory, start Telegram, and open the victim's account. No password, no 2FA, no second device required.

The injection is not limited to one command. Every semicolon opens another. Three targets are three instruction files and three stacked commands in a single link.

Delivery

The link has to be clicked from outside Telegram, because links clicked inside a chat are handled in-process and never reach the socket. The attacker sends an ordinary https:// link, and their own server returns a 302 redirect to the crafted tg:// URL. The browser follows the redirect, the operating system launches Telegram, and the injection fires [7].

Depending on the browser, the system may ask for confirmation before launching Telegram. That is the only interaction the victim has. One click on a link that looks like a normal website.

The fix

Telegram fixed this in version 7.2.9, commit db3405699f, published September 17, 2026. The fix does three things: removes the interpret: URI scheme entirely, escapes the semicolon separator on the socket using percent-encoded hex, and adds defensive checks that skip CMD: and CTRL: records when an OPEN: record is present on the same connection [8].

The changelog for 7.2.9 mentions only a rendering fix. No security advisory accompanied the release. The commit is titled "Remove legacy interpret path helper." The fix shipped quietly [9].

Why quiet fixes are a problem

Telegram has over 900'000'000 monthly active users. A vulnerability that lets an attacker take over any account with a single click, without the victim ever knowing, is about as serious as it gets for a messaging platform. Shipping the fix without an advisory means people who do not update automatically, or who dismiss "rendering fix" changelogs as unimportant, stay vulnerable.

The reporter, BeakSec, submitted through ZDI on June 25. Telegram fixed it independently on September 16, the same day ZDI closed the case as already fixed. The CVE was assigned on October 7, three weeks after the fix shipped. Anyone running Telegram Desktop 7.2.8 or earlier is still vulnerable [10].

If you use Telegram Desktop, update to 7.2.9 or later. If you cannot update, turn on "ask where to save each file" to prevent auto-download of the instruction file, limit who can add you to groups, and set a local passcode. The passcode does not prevent file theft, but it makes the stolen session unusable without it [11].

What I find notable

This is a textbook example of how two low-severity bugs combine into a high-severity exploit. An unescaped separator in a local socket is a code quality issue. An internal URI scheme with no authorization check is a design oversight. Neither looks dangerous in isolation. Chained together, they produce one-click account takeover with an 8.1 CVSS score.

The serialization bug is the kind of thing that has been causing vulnerabilities for as long as programs have communicated over boundaries. SQL injection, command injection, HTTP header injection, log injection: they are all the same pattern, a delimiter that is not escaped. Telegram's IPC format is a homegrown text protocol, and the character it chose as a separator appears unescaped in the data it carries. It is 2026 and we are still writing parsers that split on a delimiter without checking whether the delimiter appears in the payload.

The interpret: scheme is the more interesting failure. It was built for an internal workflow: a release script that sends build artifacts to a channel. It was never meant to be reachable from outside. But "never meant to be reachable" is not a security boundary. If the code exists and the code runs, it is reachable. The function performed a privileged action, reading any file and sending it to a chat, and it had no authorization check because the only caller was supposed to be a trusted script. When the IPC injection made it callable from a link, the trusted caller assumption collapsed.

The lesson is old but apparently still needs repeating: privileged operations need authorization checks at the point where the operation happens, not at every point where someone might call it. Defense in depth means the last line of defense works even when everything above it fails. Telegram had no last line. The interpret: function trusted its caller, and the caller turned out to be anyone.