CVE-2026-47430 - Cordova InAppBrowser callback spoofing on iOS

On iOS, cordova-plugin-inappbrowser versions 3.1.0 through 6.0.0 passed the id field from a WKScriptMessage body into Cordova callback dispatch without validating that the callback id belonged to the InAppBrowser message channel. The Apache disclosure says any untrusted page loaded inside InAppBrowser could guess or enumerate pending callback ids and fire callbacks belonging to other installed plugins.

This is a trust-boundary failure between untrusted web content and the host application’s native plugin bridge. The right fix upgrades the plugin, treats InAppBrowser pages as untrusted input sources, and reviews app flows that keep high-value callbacks pending while third-party pages, OAuth redirects, or marketing content are open inside the embedded browser.

When to use it

Use this recipe when a Cordova iOS app uses cordova-plugin-inappbrowser for OAuth, external links, marketing pages, help content, deep links, or any third-party web content while native plugin callbacks may remain pending. It is designed for source-code remediation, mobile plugin upgrade review, browser-to- native trust-boundary hardening, and evidence that untrusted web content cannot spoof sensitive Cordova callbacks.

Inputs

  • Cordova app inventory, cordova-plugin-inappbrowser version, config.xml, package/lockfile state, generated plugins/ state, iOS platform artifacts, plugin forks/wrappers, and SBOM or dependency reports.
  • Source paths that call InAppBrowser.open, replace window.open, handle OAuth/deep-link/browser messages, register custom native plugins, or keep Camera/Contacts/File/Geolocation callbacks pending.
  • Regression fixtures or safe smoke tests for fixed plugin versions, generated iOS app state, external-browser flows, auth redirects, and callback-boundary assumptions without probing live callback ids.
  • Boundary evidence: external content sources, sensitive plugin callbacks, token/session review needs, mobile rollout owner, app-store release path, and operator cleanup requirements.

Affected versions

  • Vulnerable package: cordova-plugin-inappbrowser >=3.1.0, <=6.0.0
  • Fixed package: cordova-plugin-inappbrowser 6.0.1+
  • Affected platform: iOS
  • Affected condition: untrusted content is loaded inside InAppBrowser while other plugin callbacks remain pending
  • Impact examples: spoofed callback results for Camera, Contacts, File, Geolocation, or other installed Cordova plugins

Indicator-of-exposure

  • The repository depends on, vendors, or ships cordova-plugin-inappbrowser 3.1.0 through 6.0.0.
  • The iOS app opens third-party content, OAuth flows, marketing pages, deep-link targets, or network-fetched content inside InAppBrowser.
  • The app replaces window.open globally with cordova.InAppBrowser.open, increasing the chance that untrusted pages run in the embedded browser.
  • Sensitive plugin operations can remain pending while the browser is open: login callbacks, file selection, camera/media capture, geolocation, contacts, or custom native plugin actions.
  • The same codebase contains custom forks or wrappers around message handling, callback naming, or browser-bridge behavior.

Quick checks:

rg -n "cordova-plugin-inappbrowser|InAppBrowser.open|window.open = cordova.InAppBrowser.open|addEventListener\\('message'|WKScriptMessage|callbackId|Camera|Contacts|Geolocation|File" .
npm ls cordova-plugin-inappbrowser
cordova plugin ls
rg -n "oauth|redirect|deeplink|marketing|promo|browser|inappbrowser|window.open" src www hooks config.xml package.json package-lock.json plugins . 2>/dev/null

Windows:

rg -n "cordova-plugin-inappbrowser|InAppBrowser.open|window.open = cordova.InAppBrowser.open|addEventListener\\('message'|WKScriptMessage|callbackId|Camera|Contacts|Geolocation|File" .
npm ls cordova-plugin-inappbrowser
cordova plugin ls
rg -n "oauth|redirect|deeplink|marketing|promo|browser|inappbrowser|window.open" src www hooks config.xml package.json package-lock.json plugins .

Do not load attacker-controlled pages in a real app, guess live callback ids, or capture user data while validating.

Remediation strategy

  • Upgrade every controlled iOS Cordova app, lockfile, plugin manifest, and build artifact to cordova-plugin-inappbrowser 6.0.1+.
  • Rebuild the iOS app and any generated Cordova plugin state after the upgrade.
  • Treat InAppBrowser pages as untrusted. Avoid leaving privileged plugin callbacks pending while third-party content is loaded there.
  • Prefer the system browser for high-risk auth or external-content flows when product requirements allow, especially if the app currently relies on broad window.open replacement.
  • Review any custom message handlers or forks so only expected InAppBrowser callback ids can be dispatched across the bridge.
  • If the vulnerable build was used for sensitive auth or data flows, review whether tokens, profile data, contacts, media, or file paths could have been influenced by spoofed callback results.

The prompt

You are remediating CVE-2026-47430, a critical iOS trust-boundary issue in
`cordova-plugin-inappbrowser` where untrusted InAppBrowser content can spoof
Cordova plugin callbacks. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades the plugin, hardens
  browser/plugin trust boundaries, refreshes generated app artifacts, and
  documents operator cleanup, or
- TRIAGE.md if this repository does not control an affected Cordova iOS app,
  plugin fork, wrapper, or generated mobile build.

## Rules

- Scope only CVE-2026-47430 and directly related InAppBrowser callback-boundary
  hardening.
- Treat auth redirects, tokens, plugin callback payloads, files, contacts,
  geolocation, media, and user profile data as sensitive.
- Do not load attacker-controlled content, brute-force callback ids, or
  exercise live exploit flows on a real app or production backend.
- Do not weaken security by disabling plugin permissions globally or removing
  user-visible safeguards just to suppress the finding.
- Do not auto-merge.

## Steps

1. Inventory every repository-controlled Cordova app, plugin manifest,
   `config.xml`, `package.json`, lockfile, generated `plugins/` state, iOS
   platform code, wrapper modules, and build docs that reference
   `cordova-plugin-inappbrowser`.
2. Determine every resolved plugin version. A target is vulnerable if it
   resolves from `3.1.0` through `6.0.0`.
3. Search for high-risk browser flows:
   OAuth/login redirects, marketing pages, external content previews,
   deep-link destinations, third-party help content, and any global
   `window.open = cordova.InAppBrowser.open` replacement.
4. Search for sensitive plugin callbacks that may remain pending while
   InAppBrowser is open: camera, contacts, files, geolocation, custom native
   plugins, or app-specific browser-bridge handlers.
5. If this repository does not control an affected iOS Cordova app or plugin
   fork, stop with `TRIAGE.md` listing checked files, resolved versions, and
   the owning app team if another repository supplies it.
6. Upgrade all controlled references to `cordova-plugin-inappbrowser 6.0.1+`.
   Refresh lockfiles, generated Cordova plugin state, iOS platform artifacts,
   SBOMs, dependency reports, and docs.
7. Review trust-boundary design:
   - treat InAppBrowser content as untrusted;
   - avoid leaving privileged callbacks pending while third-party content is
     displayed;
   - prefer system-browser or lower-trust alternatives for external auth or
     high-risk flows when compatible with the product;
   - verify custom message handlers cannot dispatch arbitrary callback ids.
8. Add safe regression coverage:
   - vulnerable plugin versions are absent;
   - iOS builds regenerate successfully with the fixed plugin;
   - browser-driven flows still function after the upgrade;
   - code paths no longer assume embedded pages are trusted participants in the
     native plugin bridge;
   - logs do not disclose tokens, callback ids, or private user data.
9. Add a PR body section named `CVE-2026-47430 operator actions` that states:
   - plugin versions before and after;
   - whether global `window.open` replacement was used;
   - which external-content and auth flows were reviewed;
   - which sensitive plugin callbacks could have been exposed to spoofing;
   - whether token review, session invalidation, or mobile-app rollout urgency
     is required;
   - which validation commands passed.
10. Run available validation: dependency install, Cordova plugin refresh, iOS
    build, unit tests, lint/typecheck, app smoke tests, SBOM refresh, and
    dependency/security scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-47430 in cordova-plugin-inappbrowser`.

## Stop conditions

- No affected Cordova iOS app, plugin fork, or generated mobile artifact is
  controlled by this repository.
- A required upgrade path is blocked by an unrelated platform migration or
  deprecated Cordova stack outside repository control.
- Verification would require loading attacker-controlled pages or probing live
  callback ids against real user data.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades cordova-plugin- inappbrowser, refreshes generated mobile artifacts, hardens browser/plugin trust boundaries, and documents token/session/app-rollout operator actions.
  • Or a TRIAGE.md file that lists inspected Cordova files, owner, observed version, affected iOS/browser flows, sensitive callbacks, required fix, and residual risk.
  • The output must include exact validation commands and must not load attacker- controlled pages in production, brute-force callback ids, capture user data, or weaken mobile permissions to suppress the finding.

Verification - what the reviewer looks for

  • No controlled app or SBOM resolves cordova-plugin-inappbrowser from 3.1.0 through 6.0.0.
  • The iOS app is rebuilt with 6.0.1+ and generated plugin state is refreshed.
  • High-risk external-content flows are reviewed as untrusted browser contexts.
  • Sensitive plugin callbacks are not left exposed to arbitrary browser-side dispatch assumptions.
  • Operator notes cover token/session review if vulnerable builds were widely deployed.

Watch for

  • Updating package.json but leaving stale generated Cordova plugin state or lockfiles on the old version.
  • Assuming the issue is safe because the attacker must control a page already open in InAppBrowser; that is exactly the browser trust boundary this CVE breaks.
  • Keeping global window.open replacement for all links without reviewing what external pages can do while native callbacks are pending.
  • Treating this as iOS-only code and forgetting to refresh shared JS plugin metadata, SBOMs, and release notes.

References