Quick Take
- Telegram Bot API contributor levlam confirmed general bots cannot use HTML widgets, including in private chats.
- The researchers say archived widget flaws are fixed in current builds; reported compromise scope varies across older clients.
- Durov asserts server-side remediation; the restriction confirmation leaves existing-widget rendering and restoration timing unspecified.
Telegram has blocked ordinary bots from sending its new interactive in-message apps, known as HTML widgets, even in private chats. A November 13 reply in its Bot API repository confirmed the restriction as researchers and Telegram disputed security flaws in the feature.
Responding to a developer's report of failed widget messages, Telegram Bot API repository contributor levlam confirmed the restriction: “Yes, currently, general bots aren't allowed to use widgets even in private chats.” The developer reported receiving the error INPUT_MEDIA_WIDGET_NOT_ALLOWED after previously sending widgets successfully.
Telegram's Bot API changelog dates the introduction of HTML-widget messaging to Bot API 10.4 on November 9. The widget guide still listed private-chat production availability on November 14, despite levlam's confirmation that general bots cannot use it. The confirmation concerns HTML widgets; it does not announce a shutdown of ordinary bot messages or all bot services.
Unlike Mini Apps, which open a web page on demand, widgets run inside the message itself. Telegram's widget documentation describes an isolated environment that runs their code on the user's device without direct internet access. Requests to the bot pass through Telegram instead.
The feature has a direct wallet connection in its documented design. Telegram's changelog describes widget queries involving a user's TON wallet card, wallet-signed data or notification of a wallet transaction. Those capabilities explain the relevance for crypto users, but do not themselves demonstrate unauthorized signing or asset theft.
Research findings depend on the client build
As of November 14, the tg-widget-rce researchers say in their research archive that its published vulnerabilities affected listed older clients and are fixed in current Telegram builds. The archive includes Android builds, Telegram for iOS 13.2, Telegram Desktop 7.4.0 and Telegram for macOS 13.1, with different findings across versions. It does not establish a definitive minimum safe version for every client.
The researchers say widget code can execute during chat layout without a tap, but delivery requires a bot permitted to send widgets and the reported vulnerabilities depend on the client build. Their technical index distinguishes app-level code execution on selected older Android builds from results contained in an isolated widget process on others. A widget-process result does not establish control of the whole device.
Two boundaries shape Telegram's widget risk
General-bot delivery is restricted. Archived client tests answer a different question: where reported code execution could reach.
Where the researchers' tested result reached
Researchers report app-level execution on these selected older Android builds; that is not a whole-device takeover.
In these archived tests, the result remained in an isolated widget process and app-level compromise was not demonstrated.
A sending restriction does not establish the status of existing widgets or prove every client secure.
No live sending test or exploit reproduction. Client examples are archived researcher reports, not current safe-version advice. The restriction confirmation does not specify existing-widget rendering or restoration timing.
Telegram founder Pavel Durov denied that merely receiving a message could compromise users. He said users first had to start a third-party service and asserted that the issue was fully patched server-side. Starting a service and tapping a delivered widget are separate steps. Durov's assurance is Telegram's stated position; the researchers' demonstrations do not establish stolen crypto assets or widespread malicious exploitation.
Levlam's confirmation gives no restoration timetable, explanation for narrowing access or policy for how previously delivered widgets render. His reply does not establish that security reports caused the change.


