Telegram HTML Widgets Blocked for General Bots

General bots can no longer send Telegram HTML widgets, even in private chats. In a 13 November reply on the Telegram Bot API repository, the maintainer levlam wrote, at 18:55 GMT: “Yes, currently, general bots aren’t allowed to use widgets even in private chats.”

The confirmation answers a developer who said every sendWidget call had begun failing with the error INPUT_MEDIA_WIDGET_NOT_ALLOWED from about 15:50 UTC on 13 November, after the same bot had been sending widgets to a private chat since 10 November. Ordinary bot messages were not described as being switched off. The change is narrower than that: it is a block on this new in-chat format for general bots.

Telegram HTML widgets are blocked for general bots, even in private chats

The feature itself is only days old. Telegram’s Bot API changelog dates HTML-widget messaging to Bot API 10.4, published on 9 November 2026. In that release, bots gained a sendWidget method for messages that run an HTML interface inside the chat, rather than opening a Mini App on demand. The changelog said that, in production, widgets could be sent only to private chats, and that sent widgets automatically had protected content and could not be forwarded.

That private-chat path is what levlam has now narrowed. His reply does not say whether a smaller class of bots can still send widgets, why access was cut, or when, if ever, general bots will regain it. The GitHub issue remained open after his comment. No restoration date has been given.

The restriction sits in a familiar corner of messaging-app security, where a new client feature is turned on, then tightened, while claims about its safety are still in dispute. TSN has already treated that kind of gap carefully in other messaging software, including a Signal calling flaw recorded against the RingRTC library and formal verification work on Signal’s libsignal code. Those are different products and different bugs. They are the closest earlier TSN accounts of a messenger changing, or being asked to change, how a client feature behaves.

Durov said the alleged remote-code issue does not exist

Via @durov on X, Telegram’s founder Pavel Durov wrote at 16:08 GMT on 13 November: “Re alleged RCE in new TG Android/Windows widgets: The issue doesn’t exist. No one could be hacked just by receiving a message. You had to start a 3rd party service first. Even that is fully patched server-side.”

That is a denial, not a statement that anyone was compromised. It was posted earlier on the same day as levlam’s restriction confirmation, and neither official text ties the two together. levlam did not say the sending ban was a response to the security claims, and Durov’s post did not announce a change to sendWidget.

The disputed flaw claims themselves have not been confirmed by Telegram. CryptoSlate, in a 15 November report, said researchers publishing under the name tg-widget-rce describe vulnerabilities that, in their account, affected listed older clients and are fixed in current Telegram builds. CryptoSlate also said their archive covers a range of older Android builds as well as Telegram for iOS 13.2, Telegram Desktop 7.4.0 and Telegram for macOS 13.1, with different findings across versions, and that it does not establish a single minimum safe version for every client. Those are the researchers’ claims, as reported by CryptoSlate. They are not Telegram’s.

A sending restriction is a blunt control, and it has a cousin in other security write-ups where a vendor or a researcher tells operators to stop a live in-chat component. TSN has already reported SlowMist urging sites to pull a tampered Udesk chat script that, in that case, swapped cryptocurrency deposit addresses. The Telegram decision is not the same incident, and it has not been presented as a response to a confirmed theft. It is a useful reminder that blocking a widget, or pulling a script, is a delivery control, not by itself a verdict on what a flaw did or did not do.

A sending restriction is not a verdict on the flaw claims

Two official facts are now on the record, and they should be kept apart. General bots are not allowed to use the new widgets, even in private chats, and the published error for a refused sendWidget call is INPUT_MEDIA_WIDGET_NOT_ALLOWED. Separately, Durov says the alleged remote-code issue “doesn’t exist,” that receiving a message alone was not enough, and that a third-party-service path he described is “fully patched server-side.” The first fact is an access rule. The second is Telegram’s position on a security claim. levlam’s short reply does not convert one into proof of the other.

That matters because the public argument is easy to flatten. A restriction can be read as silent confirmation that the researchers were right. A founder’s denial can be read as proof that they were not. Neither reading is licensed by the texts TSN has. Telegram has not confirmed the researchers’ flaw claims. The researchers, as reported by CryptoSlate, say older listed clients were affected and that current builds are fixed. CryptoSlate’s account also leaves existing-widget rendering, and any return of general-bot access, unspecified. TSN has no restoration date to report, and nothing in the official texts supports a claim that any user was compromised.

The practical consequence, for now, is narrower and more solid. Developers who had begun to send HTML widgets from ordinary bots no longer can, including in the private chats that Bot API 10.4 had opened in production. Users still receiving ordinary bot messages should not take this story as evidence that Telegram chats as a whole have been switched off. The next official facts worth waiting for are a Telegram explanation of the sending rule, a date, if any, on which general bots might use widgets again, and any technical account from the company that goes beyond Durov’s denial.