Telegram Desktop vulnerability allowed any user's file to be stolen

Original Article ↗ Hacker News Discussion ↗

A recently patched flaw in Telegram’s desktop client allowed a single clicked link to exfiltrate any user-accessible file on the machine and hijack the victim’s Telegram account, raising fresh alarms about the app’s security posture. Commenters contrast Telegram’s polished UX and powerful group/channel features with its lack of default end-to-end encryption, phone-number-based identity, and opaque infrastructure, often favoring alternatives like Signal or WhatsApp for privacy. The incident also fuels broader criticism of desktop OSes that let apps read all user files by default, and prompts calls for stronger sandboxing and more cautious threat models, especially given suspicions about Telegram’s ties to Russian interests.

Scope and severity of the Telegram Desktop bug

  • Commenters emphasize that beyond account takeover, the bug allowed exfiltration of any user-accessible file (SSH keys, browser stores, cloud creds, etc.).
  • Root cause discussed as a hidden internal URL scheme that could upload arbitrary files, built to ease Telegram’s own release publishing.
  • Some find this “feature” astonishingly reckless; others note that exploiting it required a somewhat convoluted chain.

OS design, sandboxing, and blame

  • One view: this reflects a broader desktop OS issue where any user process can read any user file; apps should be isolated to per-app directories.
  • Counter-view: this is clearly a Telegram-specific vulnerability; most apps don’t secretly upload arbitrary files.
  • Multiple sandbox mechanisms are mentioned: OpenBSD unveil, Linux bubblewrap, SELinux, Flatpak, macOS and Windows Store sandboxes, FreeBSD jails, Qubes-style VMs.
  • Several users already sandbox browsers/Telegram via firejail, VMs, separate users, or Flatpak, but note that opt-in sandboxes only help when apps use them.

Telegram’s security posture and design choices

  • Many reiterate that Telegram has long been criticized as “insecure by design”: no E2EE by default, phone-number identity, closed server, odd crypto choices, and controversial past bugs.
  • Criticism that desktop clients still don’t support secret chats properly, and that settings allegedly get silently re-enabled.
  • Some argue Telegram should not be considered a “secure messenger” at all; others say all complex clients have bugs.

Why people still use Telegram

  • Strong praise for Telegram’s UX: powerful group tools, bots, formatting, voice transcription, multi-platform parity, and effectively unlimited cloud storage.
  • Some accept security trade-offs because they see intelligence agencies as a lesser threat than ad-tech data brokers, or because everyone they need to reach is there.
  • Others say they use it mainly for public channels, clubs, and makerspaces where lack of E2EE matters less.

Threat models, geopolitics, and trust

  • Deep distrust of Telegram’s ties to Russia and Dubai; some see it as a likely or de facto intelligence honeypot.
  • Others push back on judging purely by country of origin but still worry about centralized retention of all content/metadata.
  • Contrast with Signal and, to a lesser extent, WhatsApp: E2EE by default, open clients (for Signal), and different business models are seen as materially better.

E2EE, web apps, and updates

  • Long subthread debates whether true E2EE is possible in web apps:
    • One side: browser-based clients can’t be independently pinned or audited per user; the server can silently swap code, undermining the whole point of not trusting the server.
    • Other side: native apps with automatic updates face a similar risk; real security also depends on update/signing models and device compromise.
  • Some note Electron-style desktop wrappers can at least be hash-checked and reproducibly built, unlike live web code.

Broader lessons on app permissions

  • Repeated calls to stop letting arbitrary apps, by default, read the whole home directory and make unrestricted network connections.
  • Suggestions: OS-level user-friendly controls over filesystem/network access, default-deny models with clear opt-outs, and treating commercial closed-source apps (Zoom, Steam, Dropbox, Telegram) as untrusted and always sandboxed.