What happens if the wrong side gets access?
Android browsers are designed to process content from the open web. That means webpages should generally be treated as untrusted.
But modern Android browsers also contain native functionality, userscript engines, WebViews, JavaScript interfaces, and APIs that allow web code to communicate with the application itself.
That creates a boundary.
EinkBro supports userscripts. Those userscripts can interact with application functionality through a JavaScript interface: window.einkbroGM.
The interface is backed by a native component called UserScriptBridge.
That is useful functionality. A userscript needs a way to communicate with the Android application. The security question, however, is: who should be allowed to communicate with that bridge?
The expected model is fairly simple:UserscriptDuring testing, we found that the same interface was also accessible from an ordinary webpage.
↓
window.einkbroGM
↓
Native Android functionality
That changes the security boundary.
Think of a browser as having two worlds.
On one side: Web contentWebsites can come from anywhere and should generally be considered untrusted.
On the other: Native application functionality
This is where the Android application can perform operations that ordinary webpage JavaScript cannot normally perform.A security boundary exists between those worlds.
The problem appears when the boundary looks like this:Trusted userscriptbut ordinary web content can use it too:
↓
window.einkbroGM
↓
Native bridgeNormal webpageThe issue isn't that EinkBro has a JavaScript bridge.
↓
JavaScript
↓
window.einkbroGM
↓
Native bridge
The issue is that the bridge isn't sufficiently restricted to the context that was supposed to use it.
The GitHub advisory describes this as improper origin validation / insufficient authorization of a WebView JavaScript bridge, classified under CWE-749: Exposed Dangerous Method or Function.
The first thing we checked was whether:window.einkbroGM was accessible from a normal webpage.
It was.The page wasn't installed as a userscript.It wasn't a trusted application component.It was simply webpage JavaScript running inside EinkBro.That by itself is interesting, but it doesn't necessarily prove a security impact.So we went one step further.We tested whether the exposed interface could actually invoke a native function.One function we successfully tested was:window.einkbroGM.gmSetClipboard(...)The value supplied by the webpage was subsequently observable in the Android clipboard.
That gave us a complete path from:Web JavaScript
↓
Native bridge
↓
Native function
↓
Android system state
At first, seeing: window.einkbroGMmight not look particularly serious.
A JavaScript object being visible doesn't automatically mean an application is vulnerable.
The clipboard test provided something much more useful:a real native-side effect.The webpage controlled the value.The native bridge processed it.And Android's clipboard was changed.So the demonstrated flow becomes:Attacker-controlled webpageThe GitHub advisory confirms this exact behavior and identifies the resulting impact as unauthorized clipboard modification.
↓
JavaScript
↓
window.einkbroGM
↓
gmSetClipboard()
↓
UserScriptBridge
↓
Android Clipboard
Show the bridge as a gateway crossing a security wall.
The interesting part isn't really the clipboard.
The clipboard gives us a simple way to demonstrate that the webpage isn't merely seeing a JavaScript object.It is actually reaching native functionality.
The bigger question is what else sits behind the same bridge.
If a native bridge exposes multiple functions, then the security boundary shouldn't be evaluated based on one function alone.The relevant questions become:
- Which methods are exposed?
- Which methods can ordinary webpages call?
- What does each method do?
- Does it access sensitive Android functionality?
- Can attacker-controlled input influence that functionality?
Those are research questions rather than confirmed impacts.Our research confirmed the bridge exposure and the clipboard modification.
We did not establish arbitrary file access, account takeover, remote code execution, device compromise, privilege escalation, or access to other applications.
This is where WebView security becomes particularly interesting.A native JavaScript bridge isn't just an API.It is a privilege boundary.
Consider:
The clipboard path is the one we confirmed.The other branches require independent investigation.
That's an important distinction in security research:confirmed behavior is not the same thing as theoretical impact.
The underlying problem is familiar from application security:data and privileged functionality are being connected without enough separation.
A normal webpage is external content.A userscript is an application-controlled execution context with a specific purpose.Those two contexts shouldn't automatically receive identical privileges.
Once a native interface is exposed to arbitrary web content, the application has to answer questions such as:
- Which origin is calling?
- Which execution context is calling?
- Is that context authorized?
- Which native methods is it allowed to invoke?
Without those checks, the bridge becomes an unexpected path from web content into native code.
There isn't a reason to remove userscript functionality altogether.The important thing is to restrict the privileged interface.The GitHub advisory suggests several approaches.
Restrict the bridge : The native GM bridge should only be available to the appropriate userscript execution context.
Validate the origin : The application should verify that the caller is coming from an authorized context before privileged native methods are exposed.
Avoid global exposure : Privileged JavaScript interfaces shouldn't simply be registered globally on WebViews that can display arbitrary websites.
Authorize individual methods: Authorization should be enforced consistently across native GM functions, including functions such as gmSetClipboard().
Isolate userscripts: A separate or isolated WebView/context can provide stronger separation between trusted userscript functionality and ordinary webpage JavaScript.
The goal isn't complicated:Untrusted web content should remain untrusted.
The EinkBro issue demonstrates something broader about WebView security.Whenever JavaScript is allowed to communicate with native code, the JavaScript bridge becomes part of the application's security model.It's no longer just a convenience API.
It's a boundary.
And boundaries need authorization.The web is intentionally designed to process content from sources that the application does not control.
So giving that content access to native application capabilities requires careful isolation.Otherwise, a website can become an unexpected client of APIs that were designed for trusted application functionality.
The interesting security boundary in EinkBro wasn't between a browser and a website.
It was between: Web JavaScript and Native Android functionality.
The research demonstrated that an ordinary webpage could reach:window.einkbroGMand invoke:gmSetClipboard(...)resulting in attacker-controlled data being written to the Android clipboard.
The vulnerability was assigned CVE-2026-94560.EinkBro versions 16.3.1 and earlier are listed as affected, with 16.3.2 listed as patched.
The GitHub advisory rates the issue 5.3 / Moderate under CVSS 3.1.But the most important lesson isn't the CVE number.It's the boundary.
A native bridge should never assume that every webpage running inside its WebView is trusted.
Native JavaScript bridges are useful because they allow web code to interact with native applications.That's also exactly what makes them dangerous.In EinkBro, the demonstrated path was:Normal WebpageWe confirmed one concrete native-side effect: attacker-controlled clipboard modification.We did not claim broader impacts that weren't demonstrated.
↓
JavaScript
↓
window.einkbroGM
↓
Native UserScriptBridge
↓
Android functionality
That distinction matters.Good security research isn't about assuming the worst possible outcome.
It's about finding the boundary, testing what crosses it, proving the impact, and then asking what else needs to be investigated.
In this case, the important question is simple:If ordinary web content can reach the native bridge, what other functionality is sitting behind that door?That's where the next layer of research begins.
.png)
