Clipboard Unauthorized Write / Integrity Tampering

← Improper Platform Usage

clipboard_unauthorized_write_integrity   MEDIUM

Description

Untrusted content (a page loaded in the app’s WebView, or another app) can OVERWRITE the system clipboard through the app with no user gesture / origin check, so what the user later pastes is attacker-controlled - a clipboard integrity failure distinct from clipboard read/leak (Lenovo Android web-to-clipboard CVE-2026-7516 class).

How it works

Untrusted content, a page loaded in the app WebView or another app, overwrites the system clipboard with no user gesture and no origin check. The user copies their own wallet address, but before they paste, attacker-controlled content silently swaps the clipboard for the attacker’s address, so the user pastes the wrong value (a clipboard-hijack or address-swap). The attacker address is written to the real system clipboard; the origin and gesture decision is the offline contrast. The secure path requires a trusted origin plus a genuine user-gesture token and refuses untrusted writes, preserving what the user copied.

How to exercise it. DVMA is the harness - open this module from the home index and tap the demo action. The screen ships the malicious input and simulates the attacker (e.g. the companion app, crafted intent, or scanned payload) in-process, and the evidence panel prints the proof. The Tools (optional) and Attack inputs below are only needed to reproduce the exploit end-to-end on a real device.

Exploit steps

1. Set up. Build DVMA with a flavor that enables the Improper Platform Usage category (e.g. --dart-define-from-file=config/flavors/dev.json) and run on an emulator/simulator you control. The demo needs no external tooling; for the optional on-device reproduction the relevant tools are: Android: adb · iOS: idb.
2. Locate the target. From the home index, open Clipboard Unauthorized Write / Integrity Tampering (clipboard_unauthorized_write_integrity). The How it works section above describes this module’s specific weakness; the screen states the intended-secure behavior and exposes the vulnerable action.
3. Exploit. From a co-resident/attacker context (adb shell am start/drozer, or a crafted deep link / QR), send the untrusted input to the exported component or WebView and confirm the app performs the unsafe action (navigation, JS execution, file/URI access) with no validation.
4. Observe the evidence. Trigger the vulnerable action and read the evidence panel - it prints the concrete proof (leaked value, accepted replay, executed payload, or unauthorized result).
5. Contrast with the secure path. Run the module’s secure/hardened action (where provided) and confirm the same attack is rejected - this is what a correct implementation should do.

Tools (optional)

Android

• adb

iOS

• idb

Real-world references

Concrete public disclosures that match this vulnerability class:

• CVE-2026-7516 (Lenovo Android: web page overwrites system clipboard)