GHSA-rvm3-566m-v7fv Capacitor Android and iOS: remote content can be loaded at the app origin via the internal HTTP proxy path

• npm @capacitor/android: >= 6.0.0, < 6.2.2 → fixed in 6.2.2 • npm @capacitor/android: >= 7.0.0, < 7.6.9 → fixed in 7.6.9 • npm @capacitor/ios: >= 6.0.0, < 6.2.2 → fixed in 6.2.2 • npm @capacitor/ios: >= 7.0.0, < 7.6.9 → fixed in 7.6.9 • SwiftURL github.com/ionic-team/capacitor-swift-pm: >= 6.0.0, < 6.2.2 → fixed in 6.2.2 • SwiftURL github.com/ionic-team/capacitor-swift-pm: >= 7.0.0, < 7.6.9 → fixed in 7.6.9 • Maven com.capacitorjs:core: >= 6.0.0, < 6.2.2 → fixed in 6.2.2 • Maven com.capacitorjs:core: >= 7.0.0, < 7.6.9 → fixed in 7.6.9 • npm @capacitor/android: >= 8.5.0, < 8.5.1 → fixed in 8.5.1 • npm @capacitor/ios: >= 8.5.0, < 8.5.1 → fixed in 8.5.1 • SwiftURL github.com/ionic-team/capacitor-swift-pm: >= 8.5.0, < 8.5.1 → fixed in 8.5.1 • Maven com.capacitorjs:core: >= 8.5.0, < 8.5.1 → fixed in 8.5.1 • Maven com.capacitorjs:core: >= 8.3.5, < 8.4.3 → fixed in 8.4.3 • npm @capacitor/android: >= 8.3.5, < 8.4.3 → fixed in 8.4.3 • npm @capacitor/ios: >= 8.3.5, < 8.4.3 → fixed in 8.4.3 • SwiftURL github.com/ionic-team/capacitor-swift-pm: >= 8.3.5, < 8.4.3 → fixed in 8.4.3 • SwiftURL github.com/ionic-team/capacitor-swift-pm: >= 8.0.0, <= 8.3.4 (no fix yet) • Maven com.capacitorjs:core: >= 8.0.0, <= 8.3.4 (no fix yet) • npm @capacitor/android: >= 8.0.0, <= 8.3.4 (no fix yet) • npm @capacitor/ios: >= 8.0.0, <= 8.3.4 (no fix yet)

Impact Capacitor's WebView navigation guard validated only the host and scheme of a target URL, not its path. Because the internal HTTP proxy path (`/_capacitor_http_interceptor_`) is served at the application's own origin, a frame navigation to it was always treated as in-app navigation and allowed. Loading that path as a document caused the native layer to fetch an arbitrary, caller-specified URL and return the response body to the WebView at the app's own origin. Script in that response then ran with full same-origin trust: access to `localStorage`, cookies, and every native capability the application exposes through its registered Capacitor plugins. The proxy handler was additionally served regardless of whether the `CapacitorHttp` plugin was enabled, so applications that never enabled `CapacitorHttp` were also affected. Exploitation requires a victim to activate a link inside the application's WebView. Any Capacitor application that renders user-controlled or unsanitized links (chat messages, comments, rich-text content) is a viable delivery surface. Both Android and iOS are affected. Patches Two changes on each platform: 1. The navigation guard now blocks frame navigations whose path is the internal proxy path. 2. The proxy handler is served only when `CapacitorHttp` is enabled, and never for a document (main frame) request. Legitimate `CapacitorHttp` usage is unaffected. `fetch` and `XMLHttpRequest` are subresource requests and do not pass through the navigation guard. Upgrade to a patched version, then rebuild and redistribute your application. Workarounds If you cannot upgrade immediately, note first that disabling `CapacitorHttp` is not sufficient on affected versions, because the proxy path is served regardless of that setting. Registered plugins are consulted before the navigation guard runs, so a small plugin can block the path. On Android, override `shouldOverrideLoad(Uri url)` and return `true` when `url.getPath()` starts with `/_capacitor_http_interceptor_`. On iOS, implement `shouldOverrideLoad(_:)` and return `true` for the same path. Returning `true` cancels the navigation; return `null`/`nil` for all other URLs so normal navigation is unchanged. Independently, sanitize user-controlled link targets before rendering them in the WebView.