GHSA-3w4w-cchh-qvrw: 
PHP vulnerability analysis and mitigation

The File.Move and File.Copy bridge functions are exposed in the JS bridge, so pages may call them, and they took absolute from/to paths with no confinement; an existing destination is deleted before the write. A page can rename or overwrite files anywhere in the app sandbox (the SQLite database, caches, the app bundle), and it can copy a readable in-sandbox file into public/ and read it back through /_assets/ if it knows the app's absolute container path. The concrete target is the SQLite database. On a device the app key is held in the Keychain/Keystore, not .env, so credential theft is a lesser concern than data loss and tampering. No code execution was shown with core primitives alone. Fix. Paths are canonicalised (symlinks and .. resolved) and confined to the app's real persistent storage (storage_path('app')), with public/, .env, the database, bootstrap/cache, storage/framework and storage/logs refused. Legitimate capture-to-storage moves still work. The native File.Move/File.Copy sink exists only in the 4.x core line. On 3.x core a page call is a no-op. Apps on the 3.x line that installed the separate nativephp/mobile-file plugin get the same flaw from that package, which is addressed under its own advisory. Note. This includes native (Swift/Kotlin/C) changes, which only reach an installed app after native:install --force and a rebuild. Update the Composer package and rebuild the app.

Acknowledgments

Discovered by the researcher acd421 and reported in good faith by RedEye Security. Write-up: https://threat-intelligence.redeyesecurity.com/blog/php2shell-part-two-surviving-php-flaws-2026