news
disclose.io - Latest topics
November 9th, 2026 at 1:26 AM

Would you rate this Android WebView/native-bridge vulnerability Low or High? Looking for an independent triage opinion

Hi everyone, I’m looking for an independent technical opinion on a bug bounty report that was accepted, fixed, and rewarded, but classified as Low. Here’s a sanitized summary of the vulnerability: A co-installed Android app required only the normal INTERNET permission. It could launch the target application’s trusted WebView wrapper. A third-party questionnaire integration allowed attacker-controlled localhost content to load inside a child iframe. The target Android application exposed a privileged JavaScript-to-native bridge to that iframe. Bridge authorization relied on the trusted top-level WebView URL rather than the actual calling frame’s origin. Testing on the production build confirmed privileged bridge callback execution, a non-empty session credential, and a successful authenticated read-only account API request. No root, instrumentation, or dangerous permissions were required. No additional tap inside the target application was necessary after launching the helper app. Important limitation: This was not a remote zero-click vulnerability. Exploitation required a co-installed application, an opportunity to launch it, and an authenticated target session. My proposed CVSS 3.1 vector was: AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N — 7.1 (High) The vendor rated the vulnerability Low, primarily because the attacker-controlled iframe delivery depended on a third-party integration and because exploitation required a local application. The vendor subsequently deployed a fix that blocked the demonstrated delivery path. I received the original bounty and initially withdrew my reconsideration request to finalize the payment. I’m now seeking to understand whether the technical classification was reasonable, rather than claiming an unpaid reward. I’d appreciate opinions on four questions: Would you consider the native bridge’s failure to validate the calling frame’s origin a separate vulnerability attributable to the Android application? Does Low seem reasonable given the demonstrated authenticated-session impact and exploitation prerequisites? Should severity reflect the complete exploit chain even when the initial delivery mechanism belongs to a third party? Is requesting an independent technical reassessment after accepting the original bounty considered reasonable in bug bounty practice? I’m intentionally withholding exploit code and identifying technical details while clarifying disclosure permissions. I’m primarily interested in technical reasoning and real-world triage experience. Thanks! 1 post - 1 participant Read full topic

#ai
#product
#open_source

Get stories like this every Monday

The week's most important AI news in one email. Free, unsubscribe anytime.

Score: 2.27

Engagement proxy: 0

Canonical link: https://community.disclose.io/t/would-you-rate-this-android-webview-native-bridge-vulnerability-low-or-high-looking-for-an-independent-triage-opinion/1111