When an Export File Turns Hostile: Telegram Desktop’s HTML Trap

A chat export is supposed to freeze a conversation in time. In this case, the danger was that the exported document could behave less like an archive and more like a web page with teeth. The vulnerability at the center of the issue sat in Telegram Desktop’s HTML export feature, where untrusted content could cross into a format that browsers interpret, not just display.

Fast Facts

• The flaw was a stored cross-site scripting issue in Telegram Desktop’s HTML chat export path.
• Exports made before Beta 6.9.4 and stable 7.0.1 were affected.
• If unescaped content reached the HTML export, it could execute as script when the file was opened in a browser.
• No CVE was assigned to the issue in the material reviewed here.
• The available evidence does not confirm real-world exploitation or confirmed theft.

The mechanics behind the risk

Stored XSS is dangerous because the payload survives in a saved artifact and triggers later, when someone renders it. In a chat export, that means the risk is not in message delivery itself, but in the output layer that turns messages into HTML. If the exporter fails to encode user-controlled fields in the correct context, a harmless-looking export can carry executable markup or script into the browser.

That distinction matters. A local file is often treated as safe by users and by some security controls, yet HTML is not inert text. Once a browser opens it, the file enters a code-execution model governed by the same parsing rules that make web pages interactive. From a defensive perspective, this is why export engines deserve the same scrutiny as public-facing web templates.

The technical pattern also explains why this class of issue can be subtle. The vulnerable path may not involve messaging servers, account takeover, or network interception at all. Instead, the weak point is the renderer that serializes the data into HTML. A dedicated export writer is useful for product design, but it also creates a place where escaping, sanitization, and regression testing must be exact.

For defenders, the lesson is straightforward: context-aware encoding is non-negotiable. Every field that can carry user input should be escaped for the HTML sink it lands in, and any rich content that truly needs markup should pass through strict allowlisting. Security review should also include malicious test cases such as angle brackets, quotes, inline scripts, and crafted button text.

At the time of writing, public information has not fully established the technical root cause beyond the export path, the complete scope of affected users, or whether downstream systems were compromised. The available information supports a risk analysis, not a definitive claim of broader theft.

Conclusion

The broader lesson is not just about one desktop client or one export format. Any feature that converts stored data into HTML can quietly become a live attack surface if output handling is imperfect. In practice, the safest backups are the ones treated like code: encoded correctly, tested aggressively, and assumed dangerous until proven otherwise.

WIKICROOK

• Stored XSS: A vulnerability where malicious input is saved first and only runs when the data is later rendered.
• HTML export: A feature that converts application data into an HTML document for viewing or archiving.
• Context-aware encoding: The practice of escaping data differently depending on where it appears in HTML, such as text, attributes, or scripts.
• Sanitization: The removal or neutralization of unsafe markup before content is displayed or exported.
• Regression testing: Repeating targeted tests after a fix to make sure the same bug does not return in later builds.