How a Single Link Could Steal Your Telegram Desktop Session

Most account takeovers start with a phishing page and a stolen password. This one needed neither. A researcher who goes by beaksec (Emiliano Versini) worked out how to get from a victim clicking a link to the attacker holding the victim's live Telegram session, with no login form anywhere in the chain.

The same trick could also pull other files off the machine. The flaw sat in how Telegram Desktop talks to itself, and it's a good example of why input arriving over a local channel can't be assumed trustworthy.

The click comes last. In the scenario beaksec demonstrated on Windows, the attacker first gets small instruction files onto the victim's disk through a Telegram group. Telegram Desktop's default configuration automatically downloads group attachments up to 8 MiB (auto-download is off in broadcast channels), so the files land without the victim opening them.

In the demonstrated setup, the attacker creates a supergroup and adds the victim without the victim approving an invitation, because Telegram's default group-invitation privacy setting allows it. Restricting who can add you to groups makes this step harder.

Then the victim clicks an ordinary HTTPS link that redirects the browser to a crafted tg:// address, and that hand-off from the browser is what reaches the vulnerable code. A tg:// link clicked inside a Telegram chat is handled within the app and never gets there.

If you use Telegram Desktop, update it. Version 7.2.9 contains the fix and anything older is affected. The latest listed release as of October 10, 2026 is 7.3.0, so update to that.

The quick facts

On the CVSS side, the bug is reachable over the network, needs no privileges on the victim's machine, needs some user interaction, and has high impact on confidentiality and integrity.

Attack complexity is scored low, but that doesn't account for the staging described above, so the 8.1 and 8.6 mostly tell you how bad things get if the setup works.

How the app talks to itself

Telegram Desktop only runs one copy of itself at a time, which is normal for desktop apps. If you click a tg:// link in your browser while Telegram is open, the OS launches a new Telegram process. That process notices another one is already running, passes the link along over a local IPC channel (a socket or named pipe), and quits.

All you see is your existing window coming to the front with the right chat open. Links clicked inside Telegram itself skip all of this, which is why the attack needs the browser step.

sequenceDiagram
    participant User
    participant Browser
    participant OS
    participant New as New process (short-lived)
    participant Main as Running Telegram instance

    User->>Browser: Clicks a link that leads to tg://
    Browser->>OS: Asks the OS to open the tg:// address
    OS->>New: Starts a new Telegram process
    New->>Main: Detects an instance is already running
    New->>Main: Forwards the link over local IPC
    Main->>Main: Parses the message, opens the chat
    New-->>OS: Exits

Plenty of apps work this way, browsers and IDEs among them, usually on the assumption that anything arriving on a local channel is trustworthy. Here it wasn't.

Bug one: an unescaped delimiter

To fit a command and its argument into one IPC message, the app needs a character to separate them. The vulnerable code took the clicked link and appended it to an OPEN: record that ends with a semicolon, without escaping anything. Anyone can craft a URL, so the link text is attacker-controlled, and nothing checked whether it contained a semicolon.

It's the same mistake behind SQL injection and HTTP request smuggling. If a message is built by joining fields with a delimiter, and a field can contain that delimiter, the receiver has no way of telling one field with an odd value from two separate fields.

flowchart LR
    A["App builds one IPC message<br/>from the clicked link"] --> B{"Does the link contain<br/>the record separator?"}
    B -- "No" --> C["Receiver parses it as<br/>a single instruction"]
    B -- "Yes, unescaped" --> D["Receiver parses it as<br/>two or more instructions"]
    D --> E["The attacker's extra instruction<br/>runs with the same trust as the first"]

By itself this was a fairly limited parsing bug. That's beaksec's own assessment: only four commands could be reached through the injection, and three of them were harmless. The fourth was a problem.

Bug two: the interpret: handler

Telegram Desktop has an internal interpret: URI scheme that works from an instruction file on disk. The file names a channel and a local file, and the app uploads that file to the channel. No normal user would ever trigger it, and the README of the public proof of concept describes it as a leftover from Telegram's release-publishing script.

It asks for no confirmation, and its attempt at checking who's calling doesn't amount to much. The handler compares a from: line in the instruction file with the logged-in user's ID, but that line is optional and the attacker writes the file, so the check verifies nothing.

Put the two bugs together and the attack works like this. With an instruction file on the victim's disk and one crafted link clicked, the attacker can sneak a second instruction through the IPC parser and aim it at interpret:. The app then sends chosen files to a channel the attacker controls.

Getting the file onto the disk is where the default group auto-download matters. That's a setting, not a bug, but it lets an attacker stage everything as soon as the victim opens the group.

sequenceDiagram
    participant Attacker
    participant Group as Telegram group
    participant Victim
    participant Browser
    participant Telegram as Running Telegram instance
    participant Handler as interpret: handler

    Note over Attacker,Group: Setup
    Attacker->>Group: Posts instruction files
    Group->>Victim: Client auto-downloads them<br/>when the victim opens the group
    Attacker->>Group: Posts an ordinary https link
    Note over Victim,Handler: Trigger
    Victim->>Browser: Clicks the https link
    Browser->>Attacker: Requests the page
    Attacker-->>Browser: Redirects to a crafted tg:// address
    Browser->>Telegram: OS hands it to Telegram over local IPC
    Telegram->>Telegram: Parses the message,<br/>sees two instructions, not one
    Telegram->>Handler: Second instruction reaches interpret:
    Handler->>Handler: Reads the instruction file,<br/>no real caller check, no prompt
    Handler->>Attacker: Uploads the named files<br/>to the attacker's channel

Why file read becomes account takeover

Reading arbitrary files is bad enough, but the target that matters is tdata. That directory holds Telegram Desktop's local session state, and it works as a standing login. Whoever gets usable copies can potentially act as that account from another machine, with no password prompt and no new Two-Step Verification challenge, because the client already carries the session authorization.

Malware has been stealing tdata for years. This bug let a link do it instead.

The CVE record says the injected instruction can "upload local files, including tdata session keys, to an attacker channel." Session files are the most valuable thing to grab, but documents, config files and saved keys in the user's profile were reachable too, limited to whatever the victim's own account could open.

Telegram Desktop doesn't require a local passcode by default. Without one, an attacker who obtains the necessary tdata files can reconstruct the session and open the victim's account.

A local passcode is the one real obstacle: it makes the stolen session data much harder to use. Its strength matters, though. A forensic tool for Telegram Desktop's tdata folder, tgartifacts, includes a module for dictionary attacks against passcode-protected tdata, so a short or common passcode is a weaker barrier than a strong, unique one.

So the worst case goes like this. The attacker posts instruction files in a group, gets the victim to click an external link, injects a second IPC instruction that sends the session files to a channel they own, and then loads those files into their own Telegram Desktop. Without a strong passcode, they're logged in as the victim.

The attacker needs files placed in a group the victim belongs to and a click from each target, so this is a targeted attack and won't spread on its own.

That still leaves plenty of room for harm. The researcher's public write-up includes a proof of concept, so the attack details are publicly documented. That doesn't establish that the vulnerability is being exploited in the wild.

Caveats

• Windows is the only demonstrated platform. The researcher identifies versions through 7.2.8 as affected and confirms the Windows demonstration on 6.9.3, so the bug looks old. The proof of concept uses a relative-path trick to reach the Downloads folder without knowing the victim's username.

• A confirmation prompt may appear. Depending on the browser and on whether the victim has used the tg:// handler before, the system may ask for confirmation before launching Telegram, so for some people "one click" is a click plus a prompt. The demonstrated attack needed no confirmation for the later interpret: actions.

• No public reports of exploitation. None turned up as of October 10, 2026. With a public proof of concept around, that's no guarantee.

• The fix was silent. Telegram's 7.2.9 changelog only lists a rendering fix. The CVE record and the VulnCheck advisory both give 7.2.9 as the fixed version.

• The timing fits 7.2.9. The fix commit landed on Sept 16, 17 days before the Oct 3 write-up and roughly 15 hours before the 7.2.9 version bump, which fits with it shipping in that release.

Fixing it

Updating is the fix. Telegram Desktop 7.2.9 closes the hole, so if you haven't updated the desktop client in a while, do that before anything else.

The patch escapes ; and % in the link, removes the interpret: handler entirely, drops file paths when a connection carries an external URL, and ignores CMD: and CTRL: records that arrive next to an OPEN: record.

Until you've updated, these settings reduce the exposure (they're beaksec's recommendations):

• Ask where to save each file, which turns off the automatic downloads the attack depended on.

• Restrict who can add you to groups.

• Set a strong local passcode, so tdata stays protected if it leaks.

If you think you were hit, don't count on Active Sessions (Settings > Privacy and Security) to show an unfamiliar device. As tdata theft is generally understood, the attacker reuses your existing authorization rather than creating a new login, so there may be nothing odd to spot.

That's general understanding, not something the sources confirm for this specific bug. The safer move is to open Active Sessions from your phone and terminate the Desktop session.

For developers

Anything that traces back to input a remote party can influence, such as a URL, a filename or pasted text, is untrusted, even when it arrives over a socket that never leaves the machine.

If you're assembling messages by joining strings with a separator, you're one unescaped input away from this exact bug. Use a proper serializer and parser instead; structured and length-prefixed formats avoid this class of problem when they're implemented correctly.

The interpret: handler is also a good argument for deleting legacy privileged code. It was a release-tooling leftover that still shipped in the client, and Telegram fixed it by removing it. When powerful functionality has to stay, verify the caller using something an attacker can't write, which the optional from: line wasn't.

And registering a custom scheme like tg:// means every website and chat message can hand your app input, so threat-model it the way you would a network-facing API.

Credit to beaksec for finding it. Update your client, and if you ship software that talks to itself over a local pipe, take a look at how that protocol is built and what privileged code is still attached to it.

Sources and further reading

• Original research writeup: beaksec, Telegram Desktop: one-click account takeover via IPC injection

• CVE-2026-107181 record

• VulnCheck advisory

• tgartifacts on PyPI (forensic tool for Telegram Desktop tdata, including a passcode dictionary-attack module)

• Cybernews coverage (note: the article's body text contains a typo in the CVE number; the correct ID is CVE-2026-107181)