A helper for posting Telegram's own software builds gave a clicked link a route to files on a user's computer. The desktop client's release script could tell the app to upload a file with a prepared caption. A newly disclosed vulnerability exposed that publishing machinery to outsiders through the way two Telegram processes exchanged URLs.
The CVE record, published on October 7, describes file theft and possible account takeover in Telegram Desktop versions before 7.2.9. For developers, the consequential detail is the connection between an ordinary link and an internal tool with permission to send files. The old client treated text arriving through that connection as instructions it could act on.
The fix arrived under a rendering note
Telegram Desktop 7.2.9 was released on September 17. Its public release note contains one bullet about incorrect tlottie rendering. Someone scanning that page for a reason to prioritize a security update would find no description of file theft, session exposure, or the affected URL handling.
The previous day's code commit tells a different story. Titled "Remove legacy interpret path helper", it deletes the upload helper and its build scripts, while changing the protocol used between desktop instances. Those changes address both the powerful operation an attacker could reach and the parsing error that made it reachable.
Researcher BeakSec published the attack explanation on October 3, reporting a Windows demonstration on version 6.9.3. The account-theft example used small instruction files delivered through a group and an external web link that redirected back into Telegram. Browser confirmation could add a prompt, depending on the browser and previous protocol-handler use. "One click" describes the demonstrated route, with those conditions attached.
Where a URL became instructions
The 7.2.8 single-instance code shows the first mistake. When a second Telegram process connects to the running instance, it sends startup URLs through a local socket. Each URL is prefixed with OPEN: and followed by a semicolon. The receiving process splits the incoming text at semicolons and handles each resulting record separately.
A semicolon inside the URL could therefore become a command boundary. The sender used Qt's fully encoded URL representation, but it didn't apply an escaping rule for its own message format. The receiver then reconstructed URLs from the pieces without checking their schemes at that stage. One supplied URL could turn into several open requests. The socket was local, but the data it carried could originate outside the computer.
Telegram's startup URL handler supplied the next connection. Alongside local file paths, it recognized an internal scheme named interpret: and passed its path to file-handling code. That branch ran when the active primary window wasn't locked. Reading the two files together shows why reviewing only the public tg: link handler would miss the operation waiting further along the startup path.
The publisher inside the messaging client
The build script explains the helper's intended use. It assembled a changelog from Git history, inserted an archive path and caption into a command file, and launched Telegram with an interpret: path. It also checked that the archive existed and limited the caption length. These were checks for a publishing workflow whose operator already controlled the build directory.
Inside the client, InterpretSendPath read the named instruction file. Its fields selected a destination channel and a local file, with an optional caption. The function prepared that file and called the messaging API to send it. There was no user approval step between parsing the instructions and requesting the upload.
One field looked like an identity check: when a from: line was present, the helper compared its value with the current user's ID. Leaving the line out avoided the comparison. The file check established that a path existed, rather than limiting it to a build archive or an approved directory. The destination also needed to resolve to a loaded chat history. These details explain both the helper's authority and why delivery through a group mattered to the reported attack.
Why encrypted session files were enough
Telegram did encrypt the stored authorization. Its account storage code serialized the account's MTProto authorization and wrote it using a local encryption key. On startup, the corresponding reader decrypted the file with that key and applied the stored settings. The sensitive material was an existing session, so the attacker sought the client's saved authorization rather than a fresh login code.
The protection of that local key depended on another secret. In storage_domain.cpp, Telegram generated a random local key and encrypted it with a key derived from a passcode and salt. When creating storage without a local passcode, the code passed an empty byte array into that encryption step. The salt and encrypted key were stored together for later recovery.
That design explains why encrypted files could still be useful to a thief: an empty passcode supplies no secret the thief must discover. The storage reader derives the passcode key from the supplied value and stored salt, then unwraps the local key. A strong local passcode changes that calculation. It protects the key material, although it can't prevent a separate file-upload flaw from reading other accessible documents.
BeakSec's proof of concept collected the session-related files and opened the victim's account in another desktop installation. The researcher says the group's default automatic downloads supplied the instruction files. The suggested exposure reductions include asking where to save each file, restricting group invitations, and setting a strong local passcode. Updating closes the reported chain. Those settings address particular steps or consequences.
What changed at the process boundary
The 7.2.9 socket code introduces escaping for semicolons and percent signs, along with characters outside its chosen text range. The receiver splits records before decoding their values. A semicolon belonging to a URL can consequently stay inside that URL instead of creating an extra record. This is the encoding rule the earlier sender lacked.
The same receiver also refuses CMD: and CTRL: records when the parsed batch contains an OPEN: record. Once a connection has carried a non-file URL, it drops local file paths from that connection. The code comment states the expected distinction: a link launch carries a non-file URL, while a file-sending launch carries local paths. Mixing the two is treated as suspicious.
Deleting the interpret helper removes the operation used in this attack. Changing the socket handling addresses how hostile text could reach other operations. For someone reviewing a desktop app, this patch is a concrete reason to follow an external URL through every handoff, including communication between copies of the same executable.
Update, then review active sessions
The CVE entry sets 7.2.9 as the fixed version and rates the flaw High, with CVSS 3.1 scoring it 8.1. Its CISA enrichment records proof-of-concept exploitation. That documents an available demonstration, without establishing a campaign against users. The published Windows example also shouldn't be stretched into a claim that every Telegram app has been tested and found vulnerable.
If you're checking a desktop installation, confirm its version and install a current release containing the fix. For suspected session exposure, Telegram's account-security guidance points to Settings > Devices, or Privacy & Security > Active Sessions, where sessions can be terminated. Reviewing those authorizations addresses access that may already exist. An update repairs the client code.
Telegram's FAQ describes two-step verification as an additional password for logging in, and separately recommends a passcode to lock the app. The local storage code makes that distinction relevant here: the passcode protects saved key material, while the reported attack targets authorization already held by the desktop client. You should keep both protections, without treating either as a substitute for the patch.
Watch for a security-specific explanation attached to the 7.2.9 release, including clearer platform testing and exposure guidance. The existing rendering note leaves users to connect a routine-looking update with a file-theft disclosure weeks later. Until that documentation improves, the useful check is concrete: which desktop version is installed, and which sessions remain authorized?