Telegram's HTML widgets got RCE within a week: a timeline of fixes and Durov's response

⚡ The gist in 5 seconds

• HTML widgets were opened to all bots on November 9 in Bot API 10.4 — and within the first week, the QuickJS-ng engine was patched twice due to code execution.
• Fixes came in waves: engine v0.6.1 (November 6) and v0.6.4 (November 10), Telegram Desktop client 7.4.2 and 7.4.3 (November 13, overnight Moscow time).
• The attack required the user to launch the bot themselves; Telegram says the scenario was closed server-side, but there is no independent confirmation of this in the story.

🔍 What happened

On November 5, the Telegram Desktop 7.4.0 changelog featured exactly one line — "HTML widgets in bots." Four days later, on November 9, widgets were opened to all bots in Bot API 10.4, and that same day Andreas Røsdal published an audit of the QuickJS-ng engine with 27 findings. By November 13, Telegram had released 7.4.3.

Here's the mechanics: a widget is a message with HTML and JavaScript, up to 4 KB. The script runs in a sandbox with no network and no keyboard input, but underneath sits QuickJS, an engine written in C, and a memory-handling bug throws the script outside the sandbox. The first bug is a use-after-free in replace: the regex was rebuilt in the middle of an operation, the old bytecode was freed, and the engine kept reading it at the same address. The second is a use-after-return: await using inside a regular function — the engine accepted code it should have rejected, the function finished, and closures reached into its former memory. In the changelog, the RCE entry is dated November 6 — three days before widgets were opened to all bots.

On November 11, the day after the author's write-up on Habr was published, V12 posted a video: a widget launches a calculator on Android. Then Pavel Durov responded with a post — "There is no problem. Nobody could be hacked by merely receiving a message" — and closed the topic with the offer "Try hacking my account: t.me/monk."

🧠 Our take

The timing looks bad. The feature was rolled out to all bots on November 9, even though the RCE entry in the engine's changelog had appeared three days earlier. Our assessment: this isn't malice, but the usual race that comes with fast-rolling features — access first, holes patched later, and outside researchers move faster. But that's exactly why the phrase "there's no vulnerability, and we fixed it" in a single post sounds like a meme.

What this fundamentally changes: the messenger now has its own runtime for someone else's code. Previously, the risk from a message boiled down to phishing; now it's code execution on a JS engine. The "press Start on the bot first" requirement narrows the scenario, but people don't open a chat for that: under the pretext of login verification, "Start" gets pressed without a second thought. This is reasoning, not evidence of a specific attack.

It seems both sides win at once. Røsdal's audit was written with the help of Claude Fable 5.1, the memory bug on November 11 was found by Mythos 5.2, and Connor Sheath confirmed the result. Neural networks have sped up bug-hunting in someone else's C code — and, at the same time, sped up the race for those shipping that code to production. Who loses depends on how many more such findings are sitting in the report without a PoC.

⚠️ What we don't know

Røsdal verified all 27 findings against the code and did not attempt to reproduce them — that's his own caveat. It's unknown which specific bug V12 used and whether there was any real incident beyond the calculator demo. Telegram is an interested party, and its "fully closed server-side" claim has not been confirmed by anyone in the story. The list of fixes in the changelogs also doesn't guarantee it's complete.