Telegram Desktop Vulnerability Turned One Click Into File Theft

Telegram Desktop fixed a high-severity vulnerability that turned one external-link click into arbitrary local file theft and, under common conditions, account takeover. The Telegram Desktop vulnerability affected releases through version 7.2.8 and was confirmed on Windows. Version 7.2.9 removed the vulnerable feature and changed how the app passes links between processes.

The attack did not need malware installation, a malicious executable, or the victim’s Telegram password. Instead, it combined two flaws inside Telegram Desktop with automatic group downloads and a browser redirect. A successful attacker could make Telegram upload selected files from the victim’s computer into an attacker-controlled group.

Security researcher BeakSec disclosed the chain publicly on October 3, 2026, after reporting it through the Zero Day Initiative on June 25. Telegram had independently removed the vulnerable code on September 16, and version 7.2.9 followed the next day. CVE-2026-107181 was assigned on October 7.

The central conflict is broader than one missing escape character. Telegram treated a locally oriented release tool as trusted, then accidentally exposed it to externally supplied links. A convenience feature crossed a security boundary that the original design never expected it to reach.

The Telegram Desktop Vulnerability Was Already Patched When It Became Public

The immediate news is reassuring: Telegram Desktop 7.2.9 closed the demonstrated attack chain before the technical proof became public.

The researcher’s technical disclosure identifies Telegram Desktop through 7.2.8 as affected. Testing covered Windows versions from 6.9.3 through 7.2.8. The researcher did not claim that every Telegram client or operating system was vulnerable.

The vulnerability received the identifier CVE-2026-107181 and a CVSS 3.1 score of 8.1, placing it in the high-severity range. Its published vector reflects remote reachability, low attack complexity, and required user interaction. The attacker needed the victim to click a link, but needed no prior Telegram privileges.

The practical effect was an arbitrary file read. That term means the vulnerable application can be induced to open a local file chosen by an attacker. In this case, Telegram also sent the selected file into a Telegram chat controlled by the attacker.

That capability could expose far more than Telegram data. The researcher listed SSH private keys, browser password stores, cloud credentials, and configuration files containing API tokens as possible targets. Successful theft still depended on knowing or predicting a useful file path.

The demonstrated account takeover targeted three files within Telegram Desktop’s tdata directory. Together, those files contained or indexed the material needed to reconstruct an authorized Telegram session. An attacker could place the recovered files into a fresh installation and open the victim’s account.

This was session theft, not password recovery. A session authorization tells Telegram’s servers that a client has already authenticated. Possessing valid session material can therefore bypass the need to know the account password during the demonstrated takeover.

The attack worked most directly when the victim had not configured a local Telegram passcode. That is distinct from Telegram’s cloud password or two-step verification. A local passcode protects data stored by the desktop client on that computer.

Without a local passcode, Telegram derived its local wrapping key from an empty input and a stored salt. The researcher could therefore reconstruct the key after stealing the relevant files. A strong local passcode would make the stolen encrypted data substantially harder to use.

However, a local passcode did not repair the file-read vulnerability. The vulnerable client could still upload files selected by the attacker. The passcode only protected Telegram’s session material from straightforward reuse.

Telegram’s patch commit removed the legacy helper and strengthened the local messaging format. The public commit was titled “Remove legacy interpret path helper,” which understated the security consequences.

The accompanying changelog also did not describe an account-takeover vulnerability. According to the researcher’s timeline, version 7.2.9 mentioned only a rendering fix. Users reading ordinary release notes therefore received little indication that updating closed a serious security flaw.

That quiet patching process created the unusual timing behind this story. The vulnerable behavior disappeared before the public proof arrived, yet many installations do not update immediately. Disclosure shifted the risk toward users who remained on older builds.

A Semicolon Turned One Link Into Several Commands

The core failure was a boundary mistake: Telegram serialized a URL as text without escaping the character that separated its internal commands.

Telegram Desktop normally allows only one running instance. When the operating system launches another instance for a tg:// link, that second process forwards the link to the existing process. It communicates through inter-process communication, or IPC, which lets local programs exchange data.

Telegram’s IPC format represented each instruction as a command followed by an argument and a semicolon. A normal link became an OPEN: record ending with that separator. The receiving process split the incoming text at each semicolon.

The format was safe only if command arguments could never contain an unescaped semicolon. Telegram did not enforce that condition. A specially constructed URL could include its own separator, causing the receiver to interpret one URL as multiple internal commands.

This is record-separator injection. The problem resembles command injection, although the injected values entered Telegram’s own narrow command language. The attacker was not directly receiving an unrestricted operating-system shell.

Most of the supported internal commands had limited impact. One could show the application, while another could close it. The dangerous command was another OPEN: record because it accepted URLs without restricting their schemes.

That behavior exposed an internal URI scheme named interpret:. A URI scheme is the prefix that tells software how to handle an address. Familiar examples include https:, mailto:, and Telegram’s registered tg: scheme.

Telegram did not register interpret: with the operating system. It existed only inside the desktop client and supported Telegram’s release-publishing process. Internal scripts used it to read a text instruction file and upload a named build into a Telegram channel.

That legacy helper expected fields describing a destination channel, a local file, and an optional caption. It could also check the account identifier listed in a from: field. However, the check ran only when the instruction file included that field.

An attacker could omit from: entirely. Telegram then skipped the account comparison and continued processing the file. More importantly, the helper asked for no confirmation before reading and sending the selected local file.

Used by a trusted local release script, the behavior had a limited threat model. Anyone able to invoke it locally could probably already access the machine. The IPC injection changed that assumption by making interpret: reachable through external input.

The browser completed the bridge. A tg:// link handled directly inside a Telegram chat did not pass through the vulnerable socket. An ordinary HTTPS link did open in the system browser, however.

An attacker-controlled website could answer that HTTPS request with a redirect to a crafted tg:// URL. The operating system then launched another Telegram process. That process forwarded the unescaped URL to the existing instance, where the injected records became separate commands.

Some browsers or operating-system configurations could display a confirmation before opening Telegram. That prompt added friction but did not explain the hidden command sequence. The visible HTTPS address could also appear unrelated to the eventual Telegram URI.

The flaw therefore sat across several components rather than inside a single dramatic function. URL parsing, process handoff, a delimiter-based protocol, and a trusted release helper each behaved as designed locally. Their composition created the exploit.

That pattern matters to developers. Internal interfaces often receive less defensive scrutiny because designers assume only trusted code can reach them. Once another feature creates an unexpected route, those assumptions can collapse together.

Automatic Downloads Made the File-Theft Path Predictable

The exploit needed an instruction file on the victim’s computer, and Telegram’s default group-download behavior supplied it at a known location.

The interpret: helper did not accept all attack instructions directly inside the crafted link. It expected a local text file describing the destination chat and the file to upload. An attacker therefore needed to place that instruction file on the target computer.

Telegram groups provided the delivery channel. According to the disclosure, Telegram Desktop automatically downloaded group files up to 8 MiB under the tested default configuration. Broadcast-channel downloads behaved differently, so the proof used a supergroup.

The attacker first created a supergroup and added the target. Telegram’s default privacy configuration could permit that addition without separate approval. The attacker then posted specially prepared text files in the group.

When the victim opened the group, Telegram automatically saved those attachments. On Windows, the files landed under the user’s Downloads\Telegram Desktop directory. The sender controlled each attachment’s original filename, barring a local naming collision.

Predictability was essential. The attacker usually would not know the target’s Windows username, making an absolute path unreliable. Telegram’s helper also accepted relative paths, however.

Those relative paths resolved from Telegram Desktop’s application-data directory. From that starting point, the researcher could traverse upward into the user’s home folder and then enter the known downloads directory. No username was required in the crafted path.

Each instruction file named one local target and the attacker’s supergroup as its destination. Telegram’s helper processed only one final file: value per instruction document. The attacker could overcome that limit by supplying several documents.

The crafted link likewise carried several injected OPEN:interpret: records. Each record pointed to a different downloaded instruction file. One click could consequently trigger multiple uploads.

For account takeover, the proof targeted three predictable paths inside Telegram’s tdata folder. The first stored a salt and an encrypted data-encryption key. The second held encrypted MTProto authorization data, and the third indexed the stored account data.

MTProto is Telegram’s client-server protocol. Its authorization data lets an approved desktop client identify itself without repeating the complete login flow. That makes the files valuable even when they do not contain a readable password.

The researcher reported that the relevant folder names were consistent across default installations. One folder name derived from Telegram’s default data name instead of a random installation-specific value. That removed another obstacle for remote targeting.

After the click, the injected helper commands opened those three files and sent them into the attacker’s group. Telegram displayed no file-upload confirmation for that internal release path. The attacker could then reconstruct the directory on another computer.

The same primitive could target unrelated files when their paths were known. Developers often store cloud tokens, package credentials, signing keys, and SSH material in conventional locations. Desktop applications also keep valuable databases under predictable profile directories.

Still, “any file” requires careful interpretation. The vulnerability gave the Telegram process access to readable files at paths the attacker could identify. Operating-system permissions still applied, as did uncertainty about usernames, custom directories, and filenames.

The attack also required several environmental conditions. Telegram Desktop needed to be running, the vulnerable version had to process the redirected link, and the instruction attachments needed to reach predictable local paths. The victim then had to click the attacker’s link.

Those requirements make the attack one-click, not zero-click. Automatic downloading performed part of the preparation without an attachment click, but a browser navigation remained necessary. Describing the distinction accurately helps organizations assess exposure without minimizing the flaw.

Convenience and Trust Collided Inside Telegram Desktop

The deeper security tradeoff was not encryption versus usability; it was trusted automation versus exposure to untrusted input.

The vulnerable interpret: feature served a narrow operational purpose. Telegram’s release process needed to upload builds and changelog text into a channel. Automating that task reduced repetitive work for maintainers.

Yet the helper carried substantial authority. It could read a local path and send the result through an authenticated Telegram account. It did not request confirmation because repeated prompts would have defeated its automation purpose.

That design can remain reasonable while the entry point stays private and local. The problem emerged when ordinary link handling reached the same path. An input boundary built for public URLs inherited the privilege of an internal publishing tool.

The Telegram Desktop vulnerability demonstrates why “internal” should not substitute for authorization. Code changes, protocol handlers, plugins, and process bridges can make private features reachable from unexpected contexts. Every privileged action needs its own validation.

The IPC parser also trusted structure inferred from punctuation. Delimiter-based formats can be safe, but data must escape reserved characters before serialization. The receiver must decode them only after identifying true record boundaries.

Telegram’s fix addressed both sides of the chain. It percent-escaped record separators before sending values across the socket and decoded them after splitting records. A semicolon inside a URL could no longer create another command boundary.

The patch also removed the interpret: scheme and its send-path helper entirely. That change reduced attack surface instead of preserving a privileged legacy feature behind another conditional check. Removing unused authority is often safer than adding filters around it.

Additional protections blocked dangerous command combinations. The updated code skipped CMD: and CTRL: records when the same connection contained an OPEN: record. It also rejected local file paths after a non-local URL appeared on that connection.

Those layers matter because security patches can miss alternate paths. Escaping the semicolon addressed the demonstrated injection. Removing the privileged scheme eliminated the most damaging destination even if another parser defect later appeared.

The CVE record classifies the issue as improper neutralization of delimiters in output. That description captures the first flaw but not the full impact. Account takeover required the second, more privileged behavior.

This difference explains why automated vulnerability labels can understate a chain. A parsing bug might appear modest when reviewed alone. Its severity changes when injected commands reach a helper that can upload local secrets.

The issue also challenges a common assumption about desktop messaging security. Users often focus on transport encryption, malicious attachments, and phishing credentials. Here, Telegram itself became the file-transfer mechanism after one crafted navigation.

No executable attachment needed to run. Traditional malware scanning might therefore see ordinary text files and a normal HTTPS link. The meaningful behavior occurred through legitimate Telegram functions operating with the user’s existing filesystem permissions.

Enterprise controls should account for that application-level risk. Managed devices need minimum-version enforcement, not only antivirus coverage. Security teams should also inventory messaging clients that can access local documents, browser profiles, or developer credentials.

For developers, the comparable lesson applies to deep links, local sockets, automation hooks, and command-line bridges. Every transition between them should preserve whether the original input was local, remote, trusted, or user-approved.

Privilege should not expand silently as data crosses those boundaries. A browser-supplied URL should never acquire the authority of a release engineer’s local script merely because both eventually become strings.

The Patch Solves the Chain, but the Public Evidence Has Limits

The disclosure presents a credible, code-supported proof, yet it does not establish widespread exploitation or identical exposure across every platform.

The researcher confirmed the exploit on Windows and documented relevant Telegram source code. The chain included predictable Windows paths and behavior observed in releases from 6.9.3 through 7.2.8. That is strong evidence for the tested environment.

It is not proof that every supported operating system behaved identically. File locations, browser prompts, URI handling, sandboxing, and download defaults vary across Windows, macOS, and Linux. Users should not generalize beyond the disclosed testing.

The title claim that a user’s file could be stolen also has technical limits. Telegram could access only files readable by the client’s operating-system account. The attacker also needed a usable path or a reliable way to predict it.

Those limits do not make the vulnerability minor. Many valuable files occupy conventional locations, especially on developer workstations. The Telegram session paths used in the demonstration were predictable by design.

Account takeover also depended on the local passcode state. The proof showed direct session reconstruction when no local passcode protected Telegram’s data. A strong local passcode could prevent easy decryption after theft.

Telegram’s cloud two-step verification did not necessarily stop reuse of an already authorized desktop session. That control protects authentication events, while the exploit targeted session material after authentication. Users should distinguish those defensive layers.

Another uncertainty concerns real-world abuse. The public materials did not provide evidence of confirmed exploitation before the patch. A proof of concept shows feasibility, not prevalence.

That distinction affects incident response. Organizations should not assume compromise solely because an older Telegram release was installed. They also should not ignore systems that remained vulnerable after the technical details became public.

The disclosure timeline creates a clear exposure boundary. Telegram committed the fix on September 16, 2026, and version 7.2.9 became available on September 17. The detailed explanation arrived on October 3, with the CVE following four days later.

Attackers gained a public roadmap after October 3, even though patched software already existed. Systems unable to update automatically faced increasing risk once defenders and attackers could study the same technical chain.

Telegram’s public repository provides a concrete way to validate remediation. The 7.2.9 release contains the patched code line identified by the researcher. Later versions should also include the change.

However, a version number alone does not answer whether past exploitation occurred. Telegram account holders should review active sessions, unexpected group membership, and unexplained uploads. Managed environments should also inspect endpoint and proxy records where available.

An unexpected file upload from the victim’s account would be particularly relevant. The proof used Telegram itself to send stolen data. That behavior could leave server-side or client-visible traces, although the public disclosure did not provide a complete forensic guide.

Unfamiliar browser redirects into tg:// links also deserve attention. So do text attachments downloaded from unsolicited supergroups. Neither signal proves exploitation alone, but their combination matches the demonstrated preparation and delivery path.

Users should avoid treating deletion of suspicious downloads as a substitute for updating. Removing an instruction file can interrupt one exploit attempt, but it does not repair the parser or eliminate the legacy helper.

Likewise, disabling automatic downloads reduces exposure without closing the vulnerable code. An attacker might find another way to place an instruction document at a known path. Version 7.2.9 or later remains the decisive control.

What Telegram Users and Security Teams Should Watch Next

The next test is whether vulnerable installations disappear quickly, whether exploitation evidence emerges, and whether Telegram improves security disclosure around quiet fixes.

The first signal is version adoption. Individuals should open Telegram Desktop’s settings and confirm they run version 7.2.9 or later. Organizations should enforce that baseline on every managed endpoint where Telegram is permitted.

A later version is preferable when available because it includes the same fix plus subsequent maintenance. Users should obtain updates through Telegram’s normal updater or verified distribution channels. Unofficial installers introduce an unrelated supply-chain risk.

Anyone unable to update immediately should stop using the vulnerable desktop build. Closing the application alone is not a durable enterprise control, but it removes the running instance required by the published IPC path. Web or mobile alternatives have different code paths.

The second signal is credible exploitation reporting. Security vendors, incident responders, and Telegram itself may identify attacks after comparing logs with the public proof. Confirmed cases would change this event from a serious design failure into an active incident.

Until such evidence appears, reporting should preserve the distinction between exploitable and exploited. The documented chain supports urgent patching. It does not support claims that Telegram accounts were compromised at scale through this specific flaw.

The third signal is Telegram’s disclosure practice. The security fix landed under a restrained commit title, while the release notes described no high-severity vulnerability. Users had little reason to prioritize the update before the researcher published details.

Coordinated disclosure does not always permit immediate technical detail. Vendors sometimes delay advisories to protect users while updates propagate. Still, an explicit security notice can motivate installation without publishing an exploit recipe.

Telegram could also clarify affected platforms, telemetry, and detection guidance. The research confirmed Windows behavior, while broader platform exposure remains uncertain. Official scope information would help security teams avoid both complacency and unnecessary alarm.

Users can reduce residual risk with several supporting controls. Enable “ask where to save each file” so group attachments do not automatically land at predictable paths. Restrict group additions to contacts when that setting fits your communication needs.

Configure a strong local Telegram passcode as well. It does not block arbitrary file theft on an unpatched client, but it adds protection around locally stored session material. Avoid reusing an account password or device PIN.

Review Telegram’s active sessions and terminate entries you do not recognize. If compromise seems plausible, sign out other sessions, update the client, and authenticate again. Rotate exposed developer keys, browser credentials, or cloud tokens based on the files at risk.

Organizations should go further. Query software inventory for Telegram Desktop versions through 7.2.8, then verify successful upgrades. Examine unexpected Telegram uploads, suspicious group invitations, and browser launches of Telegram protocol links.

Security teams should also consider what the client could read. A developer workstation may hold SSH keys, package-registry credentials, cloud configuration, and source-code secrets. The same exploit would have different consequences on a kiosk or tightly restricted endpoint.

The broader lesson belongs in application reviews. Deep links should carry less trust than local commands, even when both use the same parser. Internal automation endpoints need authentication or explicit user confirmation whenever their actions expose data.

Serialized IPC messages should use structured formats with strict parsing, escaping, and schema validation. Privileged legacy handlers should disappear when their original workflow no longer requires them. Security boundaries need enforcement at the final sensitive action.

Most readers do not need to reproduce the exploit or inspect Telegram’s source. They need to answer three questions now: Is the desktop client current, was it vulnerable after disclosure, and could suspicious activity have exposed sensitive files?

Update first, then review sessions and recent group activity. If an older Telegram Desktop vulnerability affected a machine holding valuable credentials, treat the incident as possible file exposure, not only messaging-account risk. That response matches what the exploit could actually reach.