← research

1SEAL-2026-008: Telegram iOS Web App bridge exposed to third-party iframes via all-frame injection and missing main-frame validation

medium
CWE-863 CWE-346 TelegramMessenger/Telegram-iOS fix commit c5a0ad267cbd2a61a0d4548490f6af5521fa55df fixed in release-12.4 2026-03-29

summary

Telegram iOS exposed its privileged Web App bridge to subframes inside mini apps. the client injected the bridge script into every frame of the WKWebView with forMainFrameOnly: false, and handleScriptMessage processed bridge messages without checking whether they originated from the main frame.

as a result, a third-party iframe embedded by a Telegram Web App could access TelegramGameProxy and dispatch privileged web_app_* events that were intended to be callable only by the trusted top-level mini app frame.

the accepted report demonstrated the core trust-boundary break with an iframe-triggered web_app_request_phone dispatch. the public fix landed on 2026-02-04 in commit c5a0ad267cbd2a61a0d4548490f6af5521fa55df, and the corrected implementation is present in tagged state release-12.4.

severity

MEDIUM — accepted by Telegram with a USD 500 reward offer, declined by the researcher.

researcher assessment: MEDIUM.

classification: CWE-863 (Incorrect Authorization) and CWE-346 (Origin Validation Error).

affected versions

confirmed vulnerable in checked tagged releases release-11.15, release-12.0, release-12.3.1, and release-12.3.2.

builds before release-12.4 that still carried the same bridge implementation should be treated as affected.

patched versions

fixed by c5a0ad267cbd2a61a0d4548490f6af5521fa55df and confirmed fixed in tagged state release-12.4.

root cause

the bridge trusted the wrong execution boundary in two places:

  1. the bridge script was injected into all frames, so subframes inherited TelegramGameProxy
  2. the native message handler accepted script messages without binding them to the main frame

that combination turns any embedded iframe into a deputy with main-app bridge privileges. the mini app developer may intentionally embed third-party content, but Telegram still has to preserve the boundary between untrusted iframe content and the privileged Web App bridge.

exploitation chain

  1. a user opens a Telegram mini app that embeds a third-party iframe
  2. because the bridge is injected into all frames, the iframe can access TelegramGameProxy
  3. the iframe dispatches a privileged web_app_* event
  4. handleScriptMessage accepts the message without verifying message.frameInfo.isMainFrame
  5. native Telegram iOS logic handles the request in the privileged mini app context

impact boundaries

the preserved evidence supports the following public statement:

  • a third-party iframe could invoke privileged Web App bridge events from a context that should not have had bridge access
  • the demonstrated example was web_app_request_phone
  • the overall risk is a confused-deputy problem across sensitive mini app capabilities, with user attribution tied to the host mini app rather than the iframe origin

fix

the public fix used defense in depth on both sides of the boundary:

  • restrict bridge injection to the main frame
  • reject incoming WKScriptMessage objects from non-main frames

timeline

date event
2026-01-30 report emailed privately to Telegram
2026-02-04 public fix commit c5a0ad267cbd2a61a0d4548490f6af5521fa55df lands
2026-02-04 tagged state release-12.4 contains the main-frame-only injection and main-frame check

credit

discovered and reported by Oleh Konko (1seal).

user guidance

users should move to release-12.4 or later, or to any build that includes commit c5a0ad267cbd2a61a0d4548490f6af5521fa55df.

developers embedding third-party content inside Telegram mini apps should not rely on iframe containment alone if they support vulnerable client builds.

references