Telegram Desktop vulnerability allowed any user's file to be stolen
A critical vulnerability in Telegram Desktop allowed one-click arbitrary file theft and account takeover, stemming from an IPC injection and an unauthenticated internal URI scheme. This deep technical dive into a severe exploit, affecting a widely used messaging app, resonated with HN's security-conscious audience. The story highlights the dangers of internal 'developer tools' becoming external attack vectors and rekindles debates about Telegram's long-standing security reputation.
The Lowdown
A recently disclosed vulnerability in Telegram Desktop (CVE-2026-107181) revealed a one-click method for attackers to steal any user-accessible file and potentially achieve full account takeover. The attack chain, active until version 7.2.9, leveraged two key defects:
- IPC Injection: When a
tg://link is clicked and Telegram Desktop is already running, a new process passes the URL to the existing instance via a local socket. This communication used a simple format with semicolons as instruction separators, but crucially, it failed to escape semicolons within the URL itself. This allowed a crafted URL containing semicolons to inject arbitrary commands into the running Telegram instance. - Unauthenticated Internal URI Scheme (
interpret:): One of the commands Telegram accepted wasOPEN:, which took any URL without scheme filtering. Hidden within Telegram's internal code was aninterpret:URI scheme, originally designed for automating release publishing. This scheme could read any file off disk and send it to a specified chat without user confirmation or authorization checks.
By combining these, an attacker could craft a link that, when clicked, would instruct Telegram to automatically download malicious instruction files (e.g., to Downloads/Telegram Desktop/) and then exfiltrate sensitive files, such as the tdata directory containing session authorization details. If no local passcode was set, stealing tdata/key_datas alone was sufficient to decrypt the session and take over the account.
The vulnerability was silently fixed in version 7.2.9, which removed the interpret:// scheme entirely and implemented proper escaping for the IPC separator. Users are strongly advised to upgrade, enable 'ask where to save each file,' limit who can add them to groups, and set a local passcode.
The Gossip
Semicolon Scapegoat: The "Bobby Tables" of Telegram
The core injection vulnerability, arising from unescaped semicolons in URI handling, reminded many commenters of classic input sanitization failures, drawing direct parallels to SQL injection and the infamous "Bobby Tables" comic. The discussion highlighted the fundamental principle that any sufficiently complex input format, if not properly validated and escaped, can be indistinguishable from executable code, creating unintended and dangerous execution environments.
Telegram's Trust Troubles: A Perennial Problem
This vulnerability reignited long-standing skepticism about Telegram's security practices, particularly its lack of default end-to-end encryption (E2EE) and perceived ties to certain governments. Many contrasted it negatively with Signal, criticizing Telegram's marketing as deceptive and its security posture as inherently weak. Others, however, defended Telegram's superior user experience (UX) and rich feature set, arguing that for many users, these benefits outweigh the security concerns, or that different threat models apply. The quiet timeline of the fix also drew criticism, seen by some as an attempt to downplay the severity.
Desktop's Dilemma: The Need for Deeper Defense
The incident sparked a broader discussion about the inherent security model of traditional desktop operating systems, where applications often have broad access to user files by default. Commenters advocated for stronger sandboxing and application isolation, pointing to solutions like Flatpaks, Firejail, or Qubes OS on Linux, or the sandboxing capabilities of macOS. The general sentiment was a desire for more granular permission models, akin to mobile OSes, but with the critical caveat of maintaining user control and avoiding vendor lock-in.
Encrypted Escapades: Web vs. Native E2EE
A tangent emerged regarding the feasibility and trustworthiness of End-to-End Encryption (E2EE) in web applications versus native desktop applications. A core argument against E2EE in web apps was the inherent requirement to trust the server to deliver the correct, uncompromised client-side code, which fundamentally undermines the E2EE principle of not trusting the server itself. While some argued it was an isomorphic problem to native apps with auto-updates, others highlighted the distinct trust models and the practical difficulties of verifying web client integrity.