Key details

  1. NativePHP security blog published October 25, 2026; independent Laravel News report October 26.
  2. Seven advisories: five high (CVSS 7.4–8.1) and two moderate.
  3. Fixed versions: nativephp/mobile 4.6.1 or 3.3.11, and nativephp/mobile-file 1.0.3 for 3.x.
  4. 4.x developers should remove the mobile-file plugin to prevent its old implementation shadowing core.
  5. Regenerate native projects, rebuild binaries and distribute new app-store versions; existing installed apps stay vulnerable.
  6. 1.x and 2.x are end-of-life and do not receive patches.
  7. Many bridge issues require hostile script execution in the app origin or an additional primitive, not automatically unauthenticated remote compromise.

What builders should take away

  1. Inventory deployed NativePHP apps and affected webview/plugin usage; prioritise apps loading untrusted or third-party script.
  2. Update the supported mobile package, remove or patch mobile-file as appropriate, regenerate native project and ship new app-store builds.
  3. Verify embedded PHP patch level separately from package versions, especially after October 21 PHP2Shell fixes.
  4. Regression-test custom event dispatchers for DispatchableFromNative, async tasks for required app keys and confined file paths.
  5. Monitor app-store uptake and require minimum client versions where sensitive workflows depend on native bridge security.

What changed

On October 25, 2026, NativePHP published seven security advisories affecting its mobile framework and plugin ecosystem: five high-severity and two moderate. Fixes are in nativephp/mobile 4.6.1 (or 3.3.11 for supported 3.x) and nativephp/mobile-file 1.0.3. Webview-origin scripts could reach inadequately guarded native bridges, enabling code injection, arbitrary PHP class construction, unconfined file operations or asset path traversal in vulnerable configurations; async task deserialization and Android logcat cookie exposure were also fixed. NativePHP 1.x and 2.x are end-of-life. Because mobile apps bundle their own PHP runtime and native bridge, developers must regenerate native projects, rebuild and publish new app-store releases; existing installed builds remain vulnerable until users update.

Why it matters

This is a direct security and distribution problem for teams shipping Laravel/PHP as mobile applications. A Composer update on a developer machine does not repair binaries already installed on devices. Some flaws require attacker-controlled JavaScript on the app origin or another primitive, so the advisories do not imply unauthenticated remote compromise of every NativePHP app. However, bridge-to-native trust failures can amplify an XSS or compromised bundled script into file manipulation and code execution. Teams must assess whether they use webview components, rebuild with fixed embedded PHP after the separate October 21 critical PHP CVEs, and get patched releases through app stores.

Five high and two moderate advisories

The high-severity issues cover async bridge task-ID code injection (GHSA-9884-fw9c-mq85, CVSS 8.1), unrestricted object instantiation in /_native/api/events (GHSA-83jv-8h7x-287p, 7.7), unconfined File.Move/File.Copy in core (GHSA-3w4w-cchh-qvrw, 7.7) and mobile-file plugin (GHSA-7927-vv5p-fv4f, 7.7), and unauthenticated deserialization of async task payloads (GHSA-9g37-88p8-75j2, 7.4). Moderate issues are /_assets path traversal (GHSA-76px-r497-93p9, 5.9) and sensitive Android session/XSRF cookies logged in release builds (GHSA-27jx-7m9x-fx5c, 4.1). These are maintainer-published severity ratings.

Exploit prerequisites and affected application modes

Most webview-bridge paths require script execution on the app's origin, such as an existing XSS flaw or compromised bundled JavaScript. They are not equivalent to unauthenticated internet-reachable server RCE. SuperNative screens that do not use a webview are unaffected by several of these particular bugs. Some chains require an additional filesystem-write capability. Risk depends on actual app mode, plugins, permissions and bundled content.

Patch the dependency, then regenerate and ship

Update nativephp/mobile to 4.6.1 on 4.x or 3.3.11 on 3.x. On 3.x, update nativephp/mobile-file to 1.0.3; on 4.x remove the plugin because core already supplies safe File.Move/File.Copy and the plugin may shadow them. Run php artisan native:install --force to regenerate the native project, rebuild and publish new app-store versions. 1.x/2.x have no fixes and require migration. Confirm the app bundle includes patched PHP after the separate October 21 PHP2Shell fixes; existing installations are not repaired by a server-side dependency update.

Compatibility and operational consequences

The event dispatch endpoint now requires a DispatchableFromNative marker interface on event classes; custom plugins using it may need code changes. File paths are canonicalised and restricted to app storage. Async tasks require an app key for authenticated encrypted payloads; apps without one can no longer dispatch them. Android release logging redacts sensitive values. Test file workflows, event bridges and async tasks after upgrading.

What to watch next

  • Any evidence of exploitation in deployed apps and additional advisories.
  • NativePHP follow-up fixes or app-store migration guidance.
  • Patch uptake and 3.x-to-4.x migration compatibility.
  • Independent reproduction of exploit prerequisites and affected webview configurations.

Still unclear

  • No broad in-the-wild exploitation or affected-installation count was established.
  • Practical exploitability varies by app origin scripting, bridge use, plugins and additional primitives.
  • NativePHP's own advisories provide severity and technical detail; independent Laravel News corroborates the release and rebuild requirement, not independent exploit testing.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment