NativePHP Mobile Security Advisories: Update to 4.6.1 and Rebuild
NativePHP published seven mobile advisories and rebuilt PHP binaries for the October CVEs. Here is what changed in 4.6.1 and how to ship the fix to users.
If you ship a NativePHP Mobile app, updating Composer is not enough this week. Your users only get the fixes when they install a new build of your app.
On October 26, 2026, Laravel News reported that NativePHP published its first security advisories: seven of them at once, all for NativePHP for Mobile. Five are rated High, with CVSS scores from 7.4 to 8.1. The same NativePHP post covered how the team handled the critical PHP releases from October 21.
This post is a short field guide: what was fixed, what might break when you upgrade, and the exact steps to get a patched app into the stores.
Why a package update is not enough
A NativePHP app bundles its own copy of PHP. That is the whole point of the framework, and it is why this is different from patching a server. You can run composer update on your laptop all day, but the PHP binary and the native project inside the app your users installed do not change until you rebuild and release.
So there are two things to deliver: the fixed nativephp/mobile package, and a PHP binary built on the patched PHP versions. According to Laravel News, the PHP releases that matter here are 8.5.12, 8.4.27, and 8.3.36, which fix CVE-2026-109618 and CVE-2026-109619 (both CVSS v4.0 9.2). If you want the server-side view of those CVEs, I wrote a patch checklist for them.
The update steps
Here is the sequence from the Laravel News write-up, with the commands in one place:
# 4.x apps: move to the fixed release
composer require nativephp/mobile:^4.6.1
# 4.x only: the core package now has its own File.Move and File.Copy,
# and the plugin's versions can override the patched ones
composer remove nativephp/mobile-file
# regenerate the native project, then rebuild
php artisan native:install --forceApps still on the 3.x line should update nativephp/mobile to 3.3.11 and nativephp/mobile-file to 1.0.3 instead of removing the plugin. Then comes the step that is easy to forget: submit the new build to the App Store and Google Play. Until your users install that update, they are still exposed.
Versions 1.x and 2.x of nativephp/mobile are end-of-life and will not receive patches. The NativePHP team recommends moving to v4.
What was actually wrong
Most of the issues come from the internal /_native/api/* routes the web view uses to talk to the native side. Those routes had no middleware, and some bridge functions accepted input without enough checks. Here is the summary, based on the advisory table in the Laravel News article:
| Advisory | Severity | Issue | Fixed in |
|---|---|---|---|
| GHSA-9884-fw9c-mq85 | High (8.1) | Web view pages could call the async task bridge and inject PHP code through a non-UUID task ID | 4.6.1 |
| GHSA-83jv-8h7x-287p | High (7.7) | /_native/api/events instantiated any autoloadable class named in the request | 3.3.11, 4.6.1 |
| GHSA-3w4w-cchh-qvrw | High (7.7) | File.Move and File.Copy accepted any absolute path in the app sandbox | 4.6.1 |
| GHSA-7927-vv5p-fv4f | High (7.7) | Same unrestricted paths in the mobile-file plugin | 1.0.3 |
| GHSA-9g37-88p8-75j2 | High (7.4) | Async task files passed to unserialize() without authentication | 4.6.1 |
| GHSA-76px-r497-93p9 | Moderate (5.9) | Path traversal in /_assets could read files outside public/, including the SQLite database | 3.3.11, 4.6.1 |
| GHSA-27jx-7m9x-fx5c | Moderate (4.1) | Android release builds wrote the session cookie and XSRF token to logcat | 3.3.11, 4.6.1 |
The links to each GitHub advisory are in the Laravel News article.
One important piece of context: most of these attacks only work if an attacker already has JavaScript running in your app’s web view, for example through an XSS bug or a compromised third-party script. Most of the CVSS scores list attack complexity as high. That lowers the urgency a little, but it does not remove it. A web view that loads any third-party script is a web view that can run someone else’s code.
Two changes that can break your app
Two of the fixes change behavior, and both are worth testing before you submit a build.
Native events need an interface. Events dispatched through /_native/api/events must now implement Native\Mobile\Events\Contracts\DispatchableFromNative. If you maintain a plugin that dispatches its own events through that endpoint, add the interface to those event classes. A minimal sketch of what that looks like:
<?php
declare(strict_types=1);
namespace App\Events;
use Native\Mobile\Events\Contracts\DispatchableFromNative;
final class TicketScanned implements DispatchableFromNative
{
public function __construct(
public readonly string $badgeId,
) {}
}I show only the interface because that is the part the advisory describes. Check the package documentation for how events are dispatched in your setup.
Async tasks now need an app key. Async task payloads are now encrypted and authenticated with your app key. Apps without an app key can no longer dispatch async tasks. Apps that do not use async tasks were never affected by that issue. If you use async tasks, which I covered in NativePHP Mobile async tasks, confirm that APP_KEY is set in the environment your release build uses.
How the issues came to light
The disclosure story is part of this news, so it is worth a paragraph. Per Laravel News, one researcher reported the logcat issue privately. The other six were found by a second researcher and passed on through RedEye Security, and they were published with working exploit chains after RedEye posted its write-up. NativePHP says it did not receive any notice through the channel the researcher named.
NativePHP’s position, quoted in the article, is that it supports responsible disclosure: a private heads-up and a reasonable window to fix things before details go public. The team asks researchers to report issues in any NativePHP package by email to the address in its security policy, or through the “Report a vulnerability” button on a repository’s Security tab.
Public exploit chains mean you should not wait on this.
Binary verification and desktop
NativePHP rebuilt every PHP binary it distributes on the fixed PHP releases and removed the vulnerable builds from distribution. The binaries now ship with published hashes and signatures, and the tooling checks them on download. According to Laravel News, that check is in nativephp/desktop 2.4.0 and nativephp/mobile 3.3.11, with nativephp/mobile 4.7.0 expected in the coming days. I could not confirm a release date for 4.7.0, so check Packagist before you plan around it.
On the desktop side, 2.4.0 no longer needs the nativephp/php-bin package, which is now deprecated. After upgrading you can drop it:
composer remove nativephp/php-binA release checklist you can paste into a ticket
If you are the person who has to tell the rest of the team what to do, this is the short version I would paste into a ticket:
- Pin
nativephp/mobileto 4.6.1 (or 3.3.11 on 3.x) and remove or updatenativephp/mobile-fileas described above. - Run
php artisan native:install --forceand rebuild both iOS and Android. - Run your event and async task flows on a real device, since those are the two behavior changes.
- Confirm the app key is present in the release environment.
- Submit to both stores and track the rollout. Consider whether you need a forced update prompt for users on old builds. That is a product decision, not something the advisories dictate.
- Audit every third-party script your web view loads. Most of these issues need script execution inside the web view first, so reducing what can run there shrinks your exposure.
Item 6 is my own advice, not from the advisories, but it follows from how the attacks work.
Takeaways
NativePHP Mobile now gets real security scrutiny, which is a good sign for a framework people ship to app stores. The cost is that mobile patching is slower than server patching: you rebuild, submit, wait for review, then wait for users to update. Start today.
Sources
- Laravel News, NativePHP Mobile Security Advisories: Update to 4.6.1 (October 26, 2026)
- NativePHP, Our first security advisories, and this week’s PHP CVEs (linked from the Laravel News article; I relied on Laravel News’s summary of it)
- Laravel News, PHP critical RCE security releases (linked from the same article)