A link, two processes, and a stolen session
Researchers at BeakSec have published a full walkthrough of CVE-2026-107181, a chain in Telegram Desktop that turns a single clicked link into an arbitrary file read, and from there into a full account takeover. The bug scores 8.1 on the CVSS scale. It affects Telegram Desktop through version 7.2.8 on Windows and was fixed quietly in 7.2.9 back in September, without an advisory. The changelog for that release mentions a rendering fix and nothing else.
The fix shipped before the CVE existed, which is the good news. If you have not updated since mid-September, you are running a version where a link in a group chat can read files off your disk and mail them to a stranger. That is worth checking today.
One link, two processes
The chain starts with how Telegram Desktop handles its own URI scheme. The operating system launches a new Telegram process for every tg:// link, even when Telegram is already running. The new process connects to a local socket that the running instance listens on, hands over the link as text, and exits. It is a standard single-instance pattern, and it works fine as long as both sides agree on where one instruction ends.
They do not. The wire format separates instructions with a semicolon, and the sending side never escapes semicolons inside the link itself. A link like tg://x?a=1;CMD:quit travels as one string, gets cut at every semicolon on the receiving end, and arrives as two commands. The attacker controls the content of the link, so the attacker controls what the running instance executes. That is the injection, and on its own it can only close the app, because the exposed commands are mostly harmless.
The interpret scheme nobody was supposed to find
The second defect is what one of those injected commands can reach. Telegram has an internal URI scheme called interpret: that is registered nowhere and exists only inside its own code. It was built for one purpose: publishing Telegram’s own releases. A script writes a small instruction file naming a channel, a file path, and a caption, then launches Telegram with a pointer to that file. The app reads the instruction file and posts the named file to the named channel, with no confirmation prompt and no check on who asked.
When the request comes from a local release script, that is fine. When the same code path is reachable through the socket injection, it becomes a remote file read: an attacker picks any path on the victim’s disk and a channel they control, and Telegram dutifully uploads the file for them.
Getting the payload onto disk
The exploit needs an instruction file at a predictable path, and Telegram itself provides one. In default configuration, files sent to groups up to 8 MiB download automatically, without the victim clicking anything, into a fixed folder. The attacker sends an instruction file to a group the victim is in, and Telegram saves it to a known location. Because the interpret scheme also accepts relative paths, resolved from Telegram’s data directory, the exploit does not even need to know the victim’s Windows username. A relative path like ../../../Downloads/Telegram Desktop/instructions.txt lands exactly where it needs to.
From there the primitive is plain: read any file. The researchers used it to grab the local session file, the encrypted blob that acts as the client’s proof of identity to Telegram’s servers. Telegram encrypts everything on disk, including the session, but the key wrapping only protects as strongly as the local passcode does. With no passcode set, the session key falls out of the stolen files, and whoever holds it is the account, the same way a stolen cookie is the account on a website.
What to do now
Three things, in order of how much they help. Update to 7.2.9 or later, which removes the interpret scheme entirely and escapes the socket separator so semicolons can no longer split commands. Restrict who can add you to groups, since exfiltration has to land in a channel or supergroup and the attacker needs a group to deliver the payload. And set a local passcode, which does not stop the file theft but makes the stolen session file useless.
The part that sticks with me is the disclosure timeline. The fix landed on September 16, the CVE was assigned on October 7, and no advisory ever accompanied either. Users who read only changelogs were told about a rendering fix. Supply chain and client-side bugs like this one rarely make headlines precisely because they get fixed this quietly, which is good for attackers’ bookkeeping and bad for everyone else’s.
Why this pattern keeps showing up
Single-instance sockets are everywhere, and so is the mistake of serializing untrusted input into a format with an unescaped delimiter. Any desktop app that registers a URI scheme and passes links over IPC should be on your suspicion list. The defense is boring and the same every time: escape the separator, and treat anything arriving over IPC with the same hostility you would treat a network request. The files that hurt most to lose are usually the ones the app never needed to touch in the first place.