A stored cross-site scripting vulnerability could allow a malicious Telegram message to remain dormant in chat history until someone exports the conversation as HTML – turning an ordinary compliance or investigation task into a potential data-exfiltration event.
Security researchers have disclosed a stored cross-site scripting (XSS) vulnerability in Telegram Desktop’s HTML export functionality that can turn specially crafted inline-button text into executable JavaScript when an exported conversation is opened in a browser.
The unusual part is where the attack waits.
The malicious content can remain buried inside a Telegram conversation for months. The attacker does not necessarily need to join the target group, read its history or interact with the eventual victim. A poisoned message can be forwarded into another conversation and sit there until somebody performs an entirely legitimate task: exporting the chat to HTML.
Once the resulting HTML file is opened, the injected script can execute in the context of the exported document.
According to the researcher who disclosed the issue, the proof of concept demonstrated the ability to read messages and metadata rendered in the export and manipulate the page displayed to the victim.
That makes this more than another browser-based XSS bug. It is a reminder that data exports are themselves part of an organization’s attack surface.
The vulnerability sits in an unexpected place
The flaw was identified in Telegram Desktop’s HTML export pipeline.
When Telegram Desktop creates an HTML export, it converts message data into an HTML document. Most user-controlled fields are passed through a sanitization function called SerializeString(), which escapes characters that could otherwise be interpreted as HTML.
The researcher found that inline-button text followed a different path.
The vulnerable code wrote button text directly into the generated HTML rather than applying the same escaping routine.
In practical terms, HTML supplied as button text could therefore become HTML markup in the exported document.
That distinction is invisible inside Telegram’s normal desktop interface. The application displays the button text as text. The browser opening the exported file, however, interprets the generated HTML.
This is the classic problem behind XSS: data that should remain data is accidentally treated as executable code.
The difference here is that the dangerous interpretation happens during an export operation rather than while viewing the original Telegram conversation.
Telegram’s official bug-bounty programme confirms that its applications and services handling private user data are within scope for security research, and that reports should be submitted directly to its security team.
The attacker does not necessarily need to be in the group
This is the part that makes the vulnerability particularly interesting.
According to the ExPatch research, an attacker can create a Telegram bot capable of generating a message containing a malicious inline keyboard. If that message is forwarded into another conversation and the button markup survives the forwarding process, the malicious content can travel with it.
The bot itself does not need to become a member of the destination group in the forwarding scenario.
That creates an unusual delivery mechanism:
An attacker creates the poisoned message.
The message is forwarded into another Telegram group.
It becomes part of the group’s history.
Months later, somebody exports the conversation.
The victim opens the HTML file.
The embedded JavaScript executes.
The attacker’s code can then interact with the contents rendered in that export.
This is why the researcher describes the flaw as a “time bomb.” The malicious content does not need to trigger when the original message is viewed. It can simply wait for the right workflow.
For businesses, that workflow could be routine compliance archiving. For investigators, it could be evidence collection. For journalists, it could be research. For developers, it could be preserving an engineering conversation.
The security boundary is crossed at the moment the Telegram data becomes active HTML.
What could be exposed?
The proof of concept described by the researcher demonstrated access to information rendered in the exported page, including message content, sender information and timestamps.
The researcher also demonstrated access to chat metadata and the ability to manipulate the document’s DOM — the structure of the page displayed by the browser.
That distinction matters.
The vulnerability does not mean that an attacker automatically gains access to every Telegram conversation belonging to a victim. The attack depends on a victim exporting a conversation containing the malicious content and opening the resulting HTML document.
But once that condition is met, the JavaScript runs inside the page and can interact with information available to that page.
The researcher demonstrated collection of the messages rendered in the export and showed that the document could be replaced with a fake verification-style interface.
The same browser-side control could potentially be used for phishing or social engineering.
There is another less obvious risk: integrity.
If an exported Telegram conversation is being used as a record for an investigation, compliance review, internal dispute or legal process, malicious JavaScript capable of changing what the browser displays could create a misleading representation of the original conversation.
That does not mean Telegram’s server-side history has been altered.
It means the copy being viewed in the browser can no longer automatically be treated as trustworthy simply because it came from an apparently legitimate Telegram export.
Why the export function matters
Data export tools rarely receive the same security attention as authentication systems, APIs or network-facing services.
That needs to change.
An export function is effectively a translator. It takes structured application data and converts it into another format — in this case, HTML.
Every translation creates an opportunity for data to cross a security boundary.
Telegram Desktop’s export pipeline illustrates the danger clearly. Text that was harmless inside the application’s own interface could become executable once serialized into HTML and opened by a browser.
This is not unique to Telegram.
Organizations should apply the same thinking to:
- Email exports
- Help-desk ticket exports
- CRM reports
- Security investigation dashboards
- Chat archives
- Log viewers
- PDF and HTML reporting tools
- Collaboration-platform exports
- Digital evidence packages
Whenever untrusted data is transformed into an executable or browser-rendered format, sanitization has to be treated as a security control rather than a formatting detail.
A two-year-old code path
According to the ExPatch analysis, the vulnerable export code was introduced in 2024 as part of Telegram Desktop’s support for inline markup in HTML exports.
The researcher says the vulnerable implementation reached stable Telegram Desktop builds in March 2024 and remained present until the 2026 fix.
Telegram’s public source history confirms that Telegram Desktop releases continued through the relevant period, including version 7.0.1 on July 14, 2026.
The vulnerability was reportedly discovered on June 1, 2026 and submitted to Telegram on June 3.
The researcher says Telegram subsequently prepared a fix and that the corrected implementation applies the existing HTML escaping function to inline-button text.
The fix also addresses another JavaScript-string injection issue involving copy-callback buttons, according to the disclosure.
For defenders, the most important point is simpler: updating the Telegram client protects future exports, but it does not magically sanitize HTML files that were already generated.
That is an important distinction.
Telegram’s fix does not make old exports safe
The researcher specifically warns that HTML exports generated before the fix may still contain malicious content.
This is an important operational issue for organizations that archive exported conversations.
Imagine a company has thousands of Telegram HTML exports stored on a shared investigation server or document-management platform.
Updating Telegram Desktop today does not rewrite those historical files.
If one of those documents contains attacker-controlled JavaScript, opening it later could still present a risk.
The safest approach is to treat older HTML exports as untrusted active content.
Where historical exports are required, organizations should consider regenerating them from a patched Telegram Desktop version or opening legacy files in an appropriately isolated environment with JavaScript disabled.
Telegram Desktop’s release history shows version 7.0.1 was published on July 14, 2026, while the preceding 6.9.4 release was published on July 3.
Organizations should therefore establish their own software inventory rather than assuming every installed Telegram client is current.
The CVSS question
The researcher rates the vulnerability at CVSS 3.1 8.2, or High, using:
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
The scoring deserves some explanation.
The researcher deliberately uses Attack Vector: Local rather than Network because the vulnerable component is the local HTML export serializer. The malicious content can arrive through Telegram’s network infrastructure, but exploitation occurs when the local application creates the HTML document and the user opens it.
That interpretation is consistent with guidance from FIRST, which notes that vulnerabilities in a local component can remain classified as Local even when malicious data is delivered remotely, particularly when the vulnerable functionality processes locally stored content.
The researcher also assigns Scope: Changed because the vulnerable Telegram Desktop component ultimately affects a separate browser context in which the exported HTML is rendered.
The exact CVSS score should not distract from the operational risk.
CVSS is a useful common language for severity, but FIRST itself cautions that a comprehensive risk assessment should consider factors beyond the Base Score, including exposure and threat context.
For an organization that routinely exports sensitive conversations, the practical risk can be considerably more important than whether a vulnerability is labelled High or Critical.
Why this matters to businesses and governments
Telegram is widely used for business communications, community coordination, media activity, government communications and informal operational discussions.
That makes the export workflow particularly relevant.
Consider a government department exporting a Telegram group for an investigation.
Consider a financial institution preserving communications for compliance.
Consider an energy company archiving an engineering group.
Consider a security team collecting a conversation during an incident response investigation.
In each case, the exported document may contain information far more sensitive than the person opening it realizes.
An engineering conversation could include credentials, internal URLs, architecture diagrams or cloud configuration details.
A financial-services group could contain customer information, transaction discussions or internal operational data.
A government conversation could contain sensitive planning information.
The Middle East and Africa are not isolated from this risk. Telegram and other messaging platforms are routinely used alongside formal enterprise collaboration tools, particularly where teams span multiple countries and where informal communications need to move quickly.
CyberCory has previously examined how Telegram can become part of sophisticated attack infrastructure, including campaigns targeting organizations in the Middle East. Telegram, Trusted Tools and a Hidden Payload: Inside the New Attack Targeting Middle East Governments
The broader lesson is consistent: a trusted communications platform can become part of an attack chain without the platform itself being the attacker’s ultimate objective.
The disclosure debate
There is also a wider security-industry discussion around the disclosure of this vulnerability.
The researcher says Telegram was notified before public disclosure, supplied with proof-of-concept material and given time to ship a fix.
According to the disclosure, the researcher declined a $500 bounty and asked that it be redirected to charity.
The researcher also says Telegram declined to approve public disclosure after the issue had been fixed.
Telegram’s published bug-bounty policy states that vulnerabilities disclosed publicly or to third parties before they are addressed are not eligible for a bounty.
The distinction is important.
Responsible disclosure is ultimately about reducing risk to users while giving vendors enough time to fix serious vulnerabilities. Once a fix is available, public advisories can also help organizations understand whether they were exposed, identify vulnerable versions and decide what historical data needs additional review.
In this case, the public source code and release history provide evidence that a fix was shipped, but the researcher argues that the absence of a dedicated vendor advisory leaves users without clear guidance about potentially dangerous pre-patch HTML exports.
That is a legitimate operational concern.
For enterprise security teams, silent fixes can create an awkward question: “What exactly should we search for?”
10 actions security teams should take now
1. Update Telegram Desktop
Ensure corporate endpoints are running a fixed Telegram Desktop release. Do not rely on employees to update the application manually if Telegram is used for sensitive business communications.
2. Identify old HTML exports
Search shared drives, investigation repositories, evidence stores and employee workstations for Telegram HTML exports created before the fix.
3. Treat old HTML exports as untrusted
Do not open legacy Telegram HTML files directly in a normal browser unless they have been appropriately assessed.
4. Regenerate critical exports
Where historical conversations are required for compliance, legal or investigative purposes, consider regenerating them using a patched client.
5. Disable JavaScript when inspecting legacy HTML
If an old export must be opened, use a controlled environment where active scripting is disabled or otherwise isolated.
6. Separate evidence collection from everyday browsing
Security investigations should use dedicated analysis environments rather than opening potentially hostile HTML files on an analyst’s normal workstation.
7. Monitor unusual outbound connections
If a suspicious export has already been opened, review endpoint and network telemetry for unexpected outbound connections immediately after the file was accessed.
8. Review sensitive Telegram groups
Identify groups used for engineering, finance, administration, incident response and executive communications where historical exports may contain sensitive information.
9. Add export formats to security reviews
Application security teams should explicitly test export functionality for XSS, HTML injection, template injection and other output-encoding failures.
10. Train users not to trust familiar documents
Security awareness should cover more than email attachments. HTML exports, reports and archived conversations can also contain active content.
Organizations looking to strengthen their technical defenses, cybersecurity awareness and professional capabilities can also review Saintynet Cybersecurity services and cybersecurity training programmes.
The bigger lesson: exports are not passive files
The Telegram case is a useful reminder that the word “export” can create a dangerous mental shortcut.
An exported file is often treated as a snapshot — something inert that simply contains information.
HTML is different.
An HTML document can contain scripts, links, forms and other active elements.
That means an HTML export should never automatically be considered safe simply because it originated from a trusted application.
For software developers, the lesson is straightforward: every user-controlled field must be encoded correctly for its output context.
For security teams, the lesson is equally important: test the edges of applications, not only their obvious attack surfaces.
And for users, the message is simple.
If an old HTML export contains sensitive information, treat it like an untrusted document until you know exactly how it was generated and whether it contains active content.
What organizations should remember
The Telegram Desktop XSS issue is unusual because the malicious payload can hide in plain sight, survive inside legitimate conversation history and wait for an apparently harmless administrative action.
The attacker does not necessarily need to break into the group.
They do not necessarily need to steal the Telegram database.
They may not even need the victim to click a suspicious link.
They need the right message to reach the right export — and someone to open the resulting HTML.
Telegram has shipped a fix, with version 7.0.1 released on July 14, 2026 and later releases continuing from there.
For organizations, however, patching the application is only half the job.
Historical HTML exports deserve attention too.
The deeper security lesson goes beyond Telegram: whenever sensitive application data is transformed into HTML, PDF, JavaScript, XML or another rich format, the transformation itself must be treated as a security boundary.
A message can look harmless inside a trusted application.
That does not mean the same message remains harmless after it leaves the application.
And in cybersecurity, that difference can be where the attack begins.
Source and methodology
This article is based primarily on the ExPatch technical disclosure supplied for this report, including its proof-of-concept description, technical analysis, disclosure timeline and remediation details. Telegram’s public bug-bounty policy and Telegram Desktop’s public release history were independently checked for context. CVSS methodology was cross-checked against FIRST’s official CVSS 3.1 documentation.
The technical disclosure describes proof-of-concept testing conducted on researcher-controlled accounts and test environments. CyberCory has not independently reproduced the exploit and therefore does not present the researcher’s demonstration as evidence of widespread exploitation in the wild.
