A Semicolon in a Link Could Steal Your Telegram Account — CVE-2026-107181

Telegram Desktop, in every version through 7.2.8, had a bug where one clicked link could send your login session to a stranger. The researcher who found it published a working proof on October 3. The fix has been out since September 17 — the question is whether you installed it.

How one link becomes your login

Here's the chain, step by step. You're in a browser. Someone drops a link — could be anywhere, a site, an email, a document. You click it. Your OS sees a tg:// link and does what it's been told to do: launch Telegram Desktop with the link as an argument.

But Telegram is already running. The new process — the standard "single instance" pattern — becomes a client, connects to a local socket the running instance listens on, and hands over the link as text. Then it exits.

The link crosses the socket flattened into a line of text — keyword OPEN:, the link, a closing semicolon. The running instance reads the bytes and cuts them at every semicolon, treating each piece as an instruction.

Now the bug: the link was encoded with QUrl::FullyEncoded, which only percent-encodes characters illegal in a URL — and a semicolon is perfectly legal inside a query (RFC 3986 says so). So an attacker-placed semicolon traveled through untouched, and the running instance split the line into two instructions instead of one.

The second instruction is the kill chain: OPEN:interpret:… — an internal URI scheme that was never registered with the OS, never shown in the UI, and never asked who sent it. A legacy helper, InterpretSendPath, opens a named instruction file, reads a file: path out of it, and uploads that file to a channel or supergroup — no confirmation. The researcher's write-up chains this into a complete attack: auto-downloaded instruction files sitting in a Telegram group, an ordinary https URL that 302-redirects onto the stacked tg:// payload, and three session files lifted out of Telegram's tdata folder. That's the victim's login, leaving through the front door.

Two defects, one semicolon

There are really two bugs here, and both had to exist for the chain to work.

The first is the unescaped separator: two grammars sharing one character with no encoder between them. The URL grammar treats a semicolon in a query as just a character; the IPC grammar treats it as the end of a command. In the CVE record this is CWE-143 — improper handling of record delimiters — and it's the kind of defect hiding in the plumbing of every desktop app that registers a myapp:// scheme. Parsers on local sockets are routinely written as if the only speaker were a later copy of yourself. A browser-mediated click is a speaker you didn't invite.

The second is the leftover: the interpret: scheme was a release-publishing helper that should never have been reachable from a URL click. It read files and sent them to chats with no caller check and no confirmation. Dead code paths don't die — they wait for someone to route traffic to them.

Telegram fixed both on September 17, 2026, in version 7.2.9 (commit db3405699f, "Remove legacy interpret path helper"). The write-up went public October 3; VulnCheck assigned CVE-2026-107181 on October 7. If your client updated any time since mid-September, you're already fine — the fix shipped quietly, before any of this was public.

Your session files are worth more than your password

What makes this bug high-severity isn't the mechanism — it's the target. The attacker doesn't steal your password; they steal your session: the three files in tdata that say "this device is already logged in."

A password is checked at the door; a session skips the door. If someone copies your session files, Telegram may treat their machine as your already-authenticated device — no code, no login screen. That's why two-step verification isn't the rescue here: 2FA guards fresh logins made with a stolen number. It doesn't invalidate a session that was already valid.

The one thing that would have blunted the theft is a feature almost nobody enables: Telegram Desktop's local passcode. Without it, your session files sit on disk wrapped in an empty key — effectively readable. Set one and they're encrypted under it: the difference between "my files got read" and "my account got taken."

What to do right now

This part is short, and that's the point.

• Update to 7.2.9 or later. Check the actual version in Settings — don't assume auto-update worked: pending restarts, app-store review delays, and managed-device policies all quietly defer updates. Restart after updating and confirm the number.
• Set a local passcode. In Desktop's settings, turn on the passcode lock and use a real password, not four digits you reuse everywhere.
• Review your active sessions. In Privacy and Security, look at the session list and terminate anything you don't recognize. If you suspect exposure, kill everything and sign back in only on devices you trust.
• Treat tg:// prompts as security decisions. When your browser asks whether to open Telegram for a link, that's a gate — don't click through on autopilot, especially from unfamiliar sources.
• Enable two-step verification if you haven't. It won't fix a stolen session, but it blocks the next-best attack: a fresh login with your number.

If you clicked a suspicious link from a browser while on 7.2.8 or older: update first, then treat it as a possible exposure. Terminate unrecognized sessions, change passwords for anything whose credentials might have lived in files the app could reach — email, cloud storage, work accounts first — and watch your Telegram for messages, groups, or settings you didn't touch.

Why this will happen again — in another app

The broader lesson is about the plumbing, not Telegram. Custom URL schemes bridge your browser and privileged local apps, and every bridge needs guards on both ends. Telegram's was missing on the receiving side: it trusted text from its own second process, forgetting the text started life as a URL someone else wrote.

The sharp version for developers: treat IPC messages and protocol-handler parameters as untrusted input even when they come from your own binary. The process on the other end of the socket is you — but the bytes inside it might not be.

One honest qualification: "one-click account takeover" is the community's phrase, and it captures the interaction well, but this isn't zero-click. The victim has to open a crafted link through an external application — browser, email, document. Links clicked inside Telegram take a different code path and don't trigger it. The attack also favors default configurations: auto-download on in groups, anyone-can-add-you-to-groups, no local passcode. A public proof of concept exists; as of this writing there are no confirmed in-the-wild attacks and no CISA KEV listing.

The fix is out, the details are public, and the preconditions describe most people's setups. Update the app, set the passcode, check the sessions — and make sure you're running the version where the semicolon is escaped.

References

• beaksec (Emiliano Versini), "Telegram Desktop: one-click account takeover via IPC injection" — write-up published Oct 3, 2026, updated Oct 7, 2026 (CC BY 4.0): core-jmp.org summary with full timeline
• The Protec, "Update Telegram Now: A Desktop Bug Could Expose Your Files and Account" (Oct 2026): theprotec.com
• Cyber Security News, "PoC Released for Telegram Desktop Flaw Enabling One-Click File Account Takeover" (Oct 9, 2026): cybersecuritynews.com
• techaiwire, "Telegram Desktop CVE-2026-107181: update to 7.2.9": techaiwire.com
• cryptika, "PoC Released for Telegram Desktop Flaw Enabling One-Click File Account Takeover": cryptika.com
• Threadlinqs intel timeline (ZDI report June 25, 2026; fix commit Sept 16; 7.2.9 release Sept 17; CVE assigned Oct 7): intel.threadlinqs.com