Zero-Click Plugin Sandbox Escape in Android Collaboration App
The Risk
A malicious third-party plugin, published to this collaboration platform's marketplace, silently runs three actions on every Android user's phone the moment they open a shared board. The victim sees nothing out of the ordinary. Within six seconds: the phone's copy-paste buffer is overwritten with whatever the attacker wants, a file is silently downloaded to the phone's storage, and the phone's browser opens an attacker-controlled page. The copy-paste swap alone is enough to redirect cryptocurrency transfers or overwrite a banking details paste. The file download can be any file type, including an app installer. No credentials are entered, no permissions are requested, no clicks are made.
The Vulnerability
The Android app renders third-party plugins inside a WebView. It registers a native-to-JavaScript bridge object on that WebView using Android's addJavascriptInterface. Android exposes any object registered through that method to every frame loaded in the WebView, including cross-origin iframes, unless those iframes are explicitly sandboxed. The desktop version of the same app wraps plugin iframes with a sandbox attribute, which blocks bridge access entirely. The Android version omits that attribute, so any JavaScript running inside a plugin iframe can call the bridge freely.
The bridge exposes several command handlers. Three of them translate into device-level actions that execute with no further user gesture.
The Attack
Any party that can publish a plugin on the platform's marketplace can weaponize it. A legitimately functional plugin, a board timer, a vote counter, a meeting template, passes the platform's review process because the review validates functionality and policy compliance, not bridge command abuse. Once published, every Android user who opens any board where the plugin is installed becomes a target, with no additional attacker effort.
Primitive 1: Clipboard Poisoning
One bridge command writes arbitrary text directly to the Android system clipboard. The victim receives no notification. Their next paste, in any app on the device, produces the attacker's string. Real-world consequences include substituting a cryptocurrency address so funds go to the attacker's wallet, swapping an OAuth link, or injecting commands into a terminal paste.
Primitive 2: Silent File Download
A second bridge command triggers Android's system download manager to fetch any attacker URL and write the result to the app's download folder. No user prompt. No visible notification during the transfer. The file size is attacker-controlled, and multiple parallel downloads multiply the impact. Consequences include silently dropping any file type to the device, consuming the victim's mobile data allowance, exhausting storage, or leaving an app installer on the device that a single tap on the system download notification will start installing.
Primitive 3: Forced Browser Navigation
A third bridge command opens an attacker-controlled URL in a Chrome Custom Tab. The tab opens automatically the moment the board loads. The landing page can display phishing content, trigger further browser-side attacks, or simply demonstrate to the victim what was just done to their device.
Combined Flow
All three fire within about six seconds of the board loading. A proof-of-concept plugin, an attacker-controlled HTTPS server, and a shared test board reproduced the sequence consistently on a mid-range Samsung device running the latest Play Store build. A desktop browser with no bridge available saw none of the primitives, confirming the vulnerability is specific to the Android WebView rendering path.
The Impact
Three device-level primitives fire automatically against any Android user who opens a board where a malicious plugin is installed. The attack requires no interaction beyond opening a shared board link, which is the standard usage pattern for the platform. The marketplace escalation is the critical path. Any attacker who publishes a plausible plugin reaches every Android user globally who opens any board where the plugin is installed. The platform has tens of millions of registered users and the Android app is the primary mobile tool for enterprise collaboration. There is no user-visible signal distinguishing this attack from normal app behavior.
Remediation
- Add a sandbox attribute with
allow-scriptsonly to plugin iframes in the Android rendering path. This is the same control the desktop app already applies. A single attribute eliminates all three primitives and every other bridge command abuse from plugin iframes. - Replace
addJavascriptInterfacewith the modernWebMessageListenerAPI, which supports origin filtering so messages from third-party origins are rejected before any handler runs. - In every bridge command handler, validate the calling frame's origin against a vendor allowlist before executing anything. Reject unknown origins at the handler level as a defense in depth.
- Remove or restrict any URL parameter that disables origin checks in the postMessage protocol handler. Such a flag should be limited to internal vendor origins only.
- Run a marketplace-wide detection scan for plugins that call any of the three primitives unconditionally at load time, as a one-time cleanup after the fix ships.