GHSA-83jv-8h7x-287p: 
PHP vulnerability analysis and mitigation

DispatchEventFromAppController constructed the class named in a request (new $event(...)) with constructor arguments from the request, gated only by class_exists(). Because the api routes carry no middleware, script on the app's own origin could POST any autoloadable class name and have the app instantiate it. Confirmed with SplFileObject (always present in PHP core): a page can truncate an existing file to zero bytes or create an empty file at any writable path (the SQLite database, compiled config/views, logs) — a reliable integrity and denial-of-service primitive. Broader impact depends on which classes the app and its plugins autoload. Fix. A marker interface, Native\Mobile\Events\Contracts\DispatchableFromNative, is now required; the endpoint refuses any class that doesn't implement it. The device-event classes implement it. A plugin that dispatches its own non-global event class through this endpoint must add the marker to that class. Older lines. 1.x and 2.x are end-of-life and will not be patched; upgrade to v4 (>= 4.6.1). Workaround. Until upgraded, avoid shipping untrusted or third-party JavaScript in the app's web view.

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