Ionic Capacitor CVE-2026-103922

The victim must be running a mobile app built on an affected Capacitor release (6.0.0 up to but not including 6.2.2 / 7.6.9 / 8.3.5 / 8.4.3 / 8.5.1) on Android or iOS, and must activate an attacker-supplied untrusted link inside the app's WebView (UI:R is the primary limiting factor). No authentication and no special configuration are required: critically, the app remains exploitable even when the CapacitorHttp plugin is DISABLED, because affected releases serve the /_capacitor_http_interceptor_ proxy path regardless of that setting - so disabling CapacitorHttp is NOT a mitigation. The realistic limiters are therefore only (1) the one required user interaction and (2) the app not yet being updated to a fixed version; there is no dependency on a non-default feature flag.

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N, 9.3) describes a network-reachable, low-complexity, unauthenticated flaw whose only gating factor is a single user action (UI:R). The scope change (S:C) is well-justified: the native proxy renders attacker-fetched content inside the application's own origin, crossing the WebView security boundary, which is exactly what grounds the High confidentiality and integrity impacts (same-origin storage, cookies, and registered plugin capabilities). The CWE-346 (origin/scheme validation gap) is corroborated by the source-code evidence - the fix adds a path check in Bridge.launchIntent and gates WebViewLocalServer on request.isForMainFrame()/CapacitorHttp being enabled - so the technical mechanism is confirmed, not merely described. Exploitation status: no public exploit identified at time of analysis; there is NO EPSS score, NO CISA KEV listing, and NO POC provided in the input, so real-world exploitation signals are absent and cannot be asserted. The combination is 'high theoretical severity, unproven in-the-wild activity': treat as a priority to patch (broadly deployed framework, default-config exposure, aggravating fact that CapacitorHttp being disabled does NOT mitigate), but there is no evidence of active or automated exploitation at this time. One nuance worth verifying: the flaw is delivered over the network but ultimately abuses a locally-served proxy path, so AV:N is appropriate (attacker supplies a remote link/URL) even though the trigger is a client-side navigation.

An attacker crafts a malicious link and lures a user of a Capacitor-based mobile app into activating it (e.g. via a message, ad, or compromised page rendered in-app). Activation navigates a frame to the app's own-origin /_capacitor_http_interceptor_ path, whose native proxy fetches an attacker-chosen URL and returns the response as a document at the app's origin, letting the attacker's script read same-origin storage and cookies and invoke registered Capacitor plugins. No public exploit code is identified in the provided data, but the GitHub security advisory and fix commits confirm the mechanism.