Die lokale Datenverschlüsselungsarchitektur von Telegram ist theoretisch lückenlos konzipiert. Benutzer-Sitzungsdaten werden durch einen dedizierten Data Encryption Key (DEK) verschlüsselt, welcher seinerseits durch einen aus dem Passwort abgeleiteten Key Encryption Key (KEK) geschützt wird. Auf Windows-Desktops reichte jedoch ein einziger manipulierter Link aus, um diese gesamte kryptographische Verteidigungslinie zu durchbrechen. Sicherheitsforscher beaksec veröffentlichte Details zur Schwachstelle CVE-2026-107181 in Telegram Desktop: Verleitet ein Angreifer das Opfer zum Anklicken eines präparierten Links, lädt der Client die zentralen Sitzungsdateien des Opfers unbemerkt in eine festgelegte Gruppe hoch und ermöglicht so die vollständige Kontoübernahme.
VulnCheck vergab als autorisierte CNA einen CVSS-4.0-Score von 8.6, während der Basiswert nach CVSS 3.1 bei 8.1 liegt. Diese Differenz begründet sich vor allem darin, dass der neuere Standard weitreichende nachgelagerte Systemauswirkungen infolge minimaler Benutzerinteraktion stärker gewichtet. Die Angriffskette funktionierte, weil Telegram Desktop vertrauenswürdige interne Aufrufe und ungesicherte externe Eingaben über denselben ungeprüften Kommunikationspfad leitete. Wenn vorgelagerte Komponenten externe Eingaben nicht als potenziell bösartig behandeln, kann selbst das robusteste kryptographische Fundament den Zusammenbruch der Vertrauensgrenzen nicht verhindern.
Nicht maskierte Trennzeichen öffnen interne Hintertür
Das erste Glied der Angriffskette beruht auf der fehlerhaften Neutralisierung von Datensatztrennzeichen (CWE-143) über den lokalen Single-Instance-Socket. Klickt ein Benutzer bei bereits geöffnetem Telegram Desktop auf einen externen Link, übergibt das Betriebssystem die URL an einen neuen Prozess. Dieser verbindet sich über einen lokalen Socket mit der primären Instanz und übermittelt die URL im Format OPEN:<url>;. Die empfangende Hauptinstanz teilt den Datenstrom anhand von Semikolons in Befehle auf. Die entscheidende Schwachstelle: Das Semikolon in der übergebenen URL wurde an keiner Stelle maskiert. Weder die Zusammensetzung in sandbox.cpp:295-297 noch die Aufteilung in sandbox.cpp:453-463 überprüften oder filterten Sonderzeichen. Ein bösartiger Link wie tg://x?a=1;CMD:quit wurde daher in zwei unabhängige Befehle gespalten, wodurch unkontrollierte Eingaben direkt in den internen Steuerungsfluss gelangten.
Diagramm: Ablauf vom Klick auf den Link bis zum Abfluss der Sitzungsdateien. Quelle: beaksec.github.io
Der so eingeschleuste Befehl übernahm das zweite Glied der Kette: das interne URI-Schema interpret:. Nach der Implementierung in application.cpp:1162-1164 reiht der Client den entsprechenden Pfad in seine Ausführungswarteschlange ein. Die nachfolgende Funktion InterpretSendPath (in support_helper.cpp:673-680) liest die in der Befehlsdatei benannte lokale Datei aus und versendet sie an einen vordefinierten Kanal oder eine Supergruppe – völlig ohne Autorisierungsprüfung oder Bestätigungsdialog. Ursprünglich diente dieses Protokoll als interne Toolchain für Updates über das Build-Skript build/updates.py. Eine darin vorgesehene from:-Zeile sollte eigentlich das aktive Benutzerkonto verifizieren; fehlte diese Zeile jedoch, übersprang der Parser die Prüfung schlichtweg. Diese Nachlässigkeit öffnete externen Angreifern den direkten Zugriff auf privilegierte interne Kernfunktionen.
Automatische Downloads formen deterministische Exploit-Kette
Die Schwachstelle an sich bot lediglich ein Einfallstor; um daraus eine verlässliche Kontoübernahme zu konstruieren, bedurfte es präziser Zustandsmanipulation. Der Angreifer erstellt zunächst eine Supergruppe und fügt das Opfer hinzu – ein Vorgang, der unter den Standard-Datenschutzeinstellungen von Telegram ohne Zustimmung des Nutzers möglich ist. Anschließend sendet der Angreifer drei Anweisungsdateien im Klartext in die Gruppe, die interpret:-Leseanweisungen für vertrauliche lokale Dateien des Opfers enthalten. Da Telegram Dateianhänge unter 8 MiB standardmäßig automatisch herunterlädt, landen diese drei Dateien geräuschlos im Verzeichnis C:\Users\<user>\Downloads\Telegram Desktop\.
Das interpret:-Protokoll unterstützt relative Pfadangaben, ausgehend vom Windows-Arbeitsverzeichnis von Telegram (%APPDATA%\Telegram Desktop). Mittels ../../../Downloads/Telegram%20Desktop/instructions.txt kann der Exploit punktgenau auf die automatisch heruntergeladenen Dateien zugreifen, ohne den Benutzernamen des Windows-Kontos kennen zu müssen. Daraufhin postet der Angreifer einen HTTP-Link in den Chat, der per 302-Weiterleitung auf die manipulierte tg://-Adresse verweist. Klickt das Opfer darauf, wird die Befehlsinjektion sofort ausgelöst.
Die drei Dateien veranlassen den Client, die für die Kontoübernahme unverzichtbaren Artefakte zu übertragen: tdata/key_datas mit dem unverschlüsselten Salt, die Datei D877F783D5D3EF8Cs in einem standardisierten Unterordner sowie die Indexdatei maps. Der Verzeichnisname D877F783D5D3EF8C ist kein Zufallswert, sondern wird gemäß storage_file_utilities.cpp:241-250 deterministisch aus dem Standardnamen data abgeleitet und ist bei jeder Standardinstallation identisch. Wenn kein lokaler Passcode vergeben wurde, gilt dieser intern als Leerstring. Mit dem entwendeten Salt aus key_datas kann der Angreifer den KEK anhand bekannter Algorithmen nachberechnen, den DEK entschlüsseln und die MTProto-Sitzung des Opfers lokal vollständig wiederherstellen. Automatischer Download, relative Pfade und fehlender Standard-Passcode sind für sich genommen Komfortfunktionen; ihr Zusammenspiel im selben Kontext schuf jedoch eine verheerende Exploit-Kette.
Vier Quellcode-Patches restrukturieren die Kommunikationsgrenzen
Um diese Kette zu brechen, entschied sich Telegram für die vollständige Beseitigung der veralteten Logik. Im Git-Commit db3405699f vom 16. September 2026 setzte das Team vier gezielte Änderungen um: Zuerst wurden das interpret://-Schema und die Hilfsfunktion Support::InterpretSendPath restlos gestrichen. Zweitens versah man die Trennzeichen der Socket-Kommunikation mit einer Prozent-Hex-Maskierung, was Mehrfachbefehlsinjektionen unterbindet. Zudem wurden zwei Härtungsregeln eingeführt: Sobald OPEN: in einer Verbindung auftaucht, werden CMD:- und CTRL:-Einträge übersprungen, und nach Erkennung einer externen URL werden alle weiteren lokalen Pfadanfragen verworfen.
Das am Folgetag veröffentlichte Update auf Version 7.2.9 enthielt sämtliche Korrekturen. Die Versionshinweise erwähnten jedoch lediglich Rendering-Fehlerbehebungen und verschwiegen das Sicherheitsproblem vollständig. Der zeitliche Ablauf verdeutlicht die Intransparenz: Die Meldung an die ZDI erfolgte am 25. Juni 2026, der Hersteller behob den Fehler eigenständig am 16. September, die ZDI schloss den Fall am 30. September, woraufhin Forscher beaksec am 3. Oktober seine Analyse publizierte und die CVE erst am 7. Oktober vergeben wurde. Solche stillen Patches erschweren es Unternehmenssicherheitsabteilungen, Risiken für interne Clients einzuschätzen. Das CISA-SSVC-Modell stuft die Ausnutzung derzeit als “poc” ein; der Eintrag in den KEV-Katalog steht aus.
Drei Schutzmaßnahmen ohne Update zur Abwehr der Angriffskette
Obwohl die Analyse auf Windows unter Version 6.9.3 durchgeführt wurde, können Anwender, die Version 7.2.9 noch nicht installiert haben, das Risiko durch Anpassung bordeigener Einstellungen drastisch reduzieren. Unter den erweiterten Einstellungen bricht die Option „Speicherort für jede Datei nachfragen“ die Pfadabhängigkeit des Exploits, da die Schaddateien nicht mehr im erwarteten Ordner abgelegt werden. Wer die Berechtigung „Wer kann mich zu Gruppen hinzufügen“ auf „Meine Kontakte“ einschränkt, verhindert, dass Fremde das Opfer ungefragt in präparierte Gruppen einladen. Zudem sollten Browser-Aufforderungen wie „Telegram öffnen“ stets kritisch hinterfragt und die Liste aktiver Sitzungen regelmäßig auf unberechtigte Anmeldungen geprüft werden.
Die wirksamste und grundlegendste Sicherheitsmaßnahme bleibt jedoch ein lokaler Passcode. Der Exploit baut darauf auf, dass kein Passcode vergeben ist und die Entschlüsselung mit Standardwerten gelingt. Wurde ein lokaler Passcode gesetzt, erfordert die Ableitung des KEK zwingend die Eingabe des Passworts im Klartext. Selbst wenn key_datas und zugehörige Dateien entwendet werden, bleiben sie ohne das Kennwort unlesbar. Wenn Anwendungslogik an Vertrauensgrenzen scheitert, stellt eine kompromisslose Konfiguration die letzte wirksame Barriere gegen Kontoübernahmen dar.
Weiterführende Links:
- Analyse zur One-Click-Kontoübernahme in Telegram Desktop (beaksec)
- VulnCheck Bewertungsübersicht und Schwachstellendetails
