The recently disclosed Telegram Desktop vulnerability is a particularly interesting example of how security risks can emerge not during normal use of an application, but when trusted data crosses into a different execution environment. Researchers found that specially crafted text placed inside Telegram bot inline buttons could be written into an HTML chat export without proper escaping, allowing hidden JavaScript to become executable when the exported file was later opened in a web browser. Inside Telegram itself, the malicious message could appear completely ordinary, and the code did not execute while the user was simply reading the chat. The danger appeared only after the conversation was exported using a vulnerable version of Telegram Desktop and the resulting HTML file was opened with JavaScript enabled, at which point the script could read the contents of that export and transmit them to an attacker-controlled server. This creates an unusual form of delayed exploitation in which the malicious payload may remain dormant inside chat history for months or even years before the specific conditions required for execution are finally met.

What makes this vulnerability especially noteworthy is that the attacker did not necessarily need direct control over the target conversation. The researchers found that a bot-generated message containing specially crafted inline buttons could be forwarded into another group, allowing the malicious content to become part of that group’s normal message history. If that conversation was later included in an HTML export, the hidden script could become active when the export was opened. This demonstrates an important class of security problem in which content that is considered harmless in one context becomes dangerous after being transformed or interpreted by another system. The Telegram client treated the button content as data, but the export functionality eventually placed that same content into HTML, where a browser could interpret it as executable code. Whenever information crosses boundaries between formats such as messaging content, HTML, PDFs, spreadsheets or documents, developers need to consider not only whether the original data is safe but also how that data will be interpreted by the destination environment.

The technical root cause was deceptively simple: Telegram Desktop correctly escaped several other fields such as message text and sender names before writing them into HTML, but failed to apply the same protection to inline button text. Because special HTML characters were not encoded, attacker-controlled content could escape the expected presentation context and become active markup or JavaScript. This is a textbook example of why output encoding must be applied consistently at every point where untrusted input enters an executable document format. A single forgotten field can undermine security protections applied everywhere else, and complex applications frequently contain dozens or hundreds of these transformation points. The vulnerability reportedly remained present in stable Telegram Desktop releases from version 4.15.1 in March 2024 until the corrected releases appeared in July 2026, illustrating how small inconsistencies in data handling can survive for long periods when the vulnerable execution path is relatively uncommon.

Once the infected HTML export was opened, the JavaScript could read the messages contained in that individual export file, including message text, sender names, timestamps, information about the chat and even the local file path. The researchers demonstrated that this information could then be transmitted to an external server without requiring another click from the victim. Telegram Desktop splits large HTML exports into files containing up to 1,000 messages each, so the exposure was limited to the contents of the particular file in which the malicious message appeared rather than automatically providing access to an entire Telegram account. Even so, a thousand messages can contain extensive personal, business or operational information, particularly when the export belongs to a corporate group, customer conversation or private discussion containing sensitive material.

The ability to modify what the browser displayed introduces another significant concern beyond simple information theft. Researchers demonstrated that the injected script could replace the visible export with a fake Telegram verification page, while the same technique could theoretically alter displayed names, dates or message content. Importantly, these changes affected what was presented inside the browser and did not modify Telegram’s original copy of the conversation or permanently rewrite the export stored on disk. Nevertheless, this becomes particularly significant when exported conversations are being used as evidence, audit records, compliance material or historical documentation, because a user examining the file in a browser could be shown information that differs from the original record. It is a useful reminder that the visual appearance of an exported document should never automatically be considered evidence of its integrity when the format itself can execute active content.

The vulnerability also exposes a broader problem with archived data: patching the application does not necessarily neutralize artifacts that were created while the application was vulnerable. Telegram fixed the issue in the 6.9.4 beta and 7.0.1 stable releases by correctly escaping the affected field, preventing newly created exports from containing executable content through this path. However, HTML exports generated using earlier vulnerable versions are static files and are not modified when Telegram Desktop is later updated. This means an old export can remain dangerous even after the software that created it has been fully patched. Users and organisations therefore need to treat previously generated HTML exports differently from newly generated ones, because remediation may require recreating those files or opening legacy exports with JavaScript disabled rather than simply assuming that installing the latest client eliminates the risk.

This distinction is particularly important for organisations that preserve messaging exports for regulatory, legal, investigative or archival purposes. Files generated months or years earlier often sit in document repositories, backup systems, investigation folders or shared drives and are rarely reassessed when vulnerabilities affecting the software that produced them are later discovered. The Telegram case illustrates that security teams may occasionally need to think about vulnerable artifacts rather than only vulnerable applications. Similar risks can exist in exported HTML reports, saved dashboards, generated documents, email archives and other formats containing active content, because a vulnerability can effectively become frozen into the output itself. Asset inventories and vulnerability management programmes generally track installed software versions extremely well but are considerably less capable of identifying documents produced by those vulnerable versions, creating a blind spot that attackers can potentially exploit.

The conditions required for exploitation also deserve perspective. The malicious content needed to be present in the exported conversation, the HTML export had to be generated by a Telegram Desktop version predating the fix and the resulting file had to be opened in a browser with JavaScript enabled. Researchers stated that they had not identified exploitation against real users, so this should not be presented as evidence of a widespread active campaign. At the same time, the absence of known exploitation does not reduce the architectural lesson because the vulnerability demonstrates how stored content can become executable only after passing through a secondary workflow. Security teams frequently focus monitoring on the moment information enters an application, while attacks increasingly exploit what happens when that information is later rendered, exported, parsed or transformed by another component.

There is also an important secure-development lesson in Telegram’s response. The flaw was reported in early June and corrected in July, yet the fix was not prominently described in the normal release notes and no CVE had been assigned as of the disclosure. From an operational perspective, quietly fixing a vulnerability may reduce immediate publicity, but limited disclosure can make it more difficult for enterprises, incident responders and users to determine whether they possess affected software or potentially unsafe exported artifacts. Vulnerability communication is therefore part of security engineering itself because administrators need enough information to identify exposure, determine whether historical data requires remediation and understand whether additional action is necessary beyond installing the latest software version.

The broader cybersecurity lesson is that data should never automatically be considered passive simply because it appears to be text. The same message can be harmless inside a Telegram conversation, dangerous inside an HTML document and potentially weaponized when interpreted by a browser. Security therefore depends heavily on understanding context, controlling how untrusted input moves between systems and ensuring that every transformation treats data according to the rules of the destination environment. Organisations increasingly exchange information between messaging platforms, browsers, productivity tools, APIs and AI systems, which creates countless opportunities for content to cross from one trust boundary into another. In such environments, protecting information is not merely about checking what the data contains when it first arrives, but also understanding what that same data may become when another application eventually decides to interpret it.

A flaw in Telegram Desktop let a bot's message plant hidden JavaScript inside chats that users exported to HTML files, security researchers at ExPatch said in a writeup published on September 12. In Telegram, the message looked ordinary, with a link button, and the script ran only when someone opened the export file in a web browser. It could then copy every message in that file to

Source: Telegram Desktop Flaw Lets Hidden JavaScript Exfiltrate Messages From HTML Exports via The Hacker News — published 14 Sep 2026.