GHSA-9g37-88p8-75j2: 
PHP vulnerability analysis and mitigation

The async task runner read a PHP-serialized work envelope from storage/framework/async/payload/<id>.task and passed it straight to unserialize(). Any writer of that file could make the app instantiate and run attacker-chosen classes in a background PHP interpreter. On a device the spool lives in app-private storage, so reaching it in practice needs a separate primitive to place a crafted file; it is the deserialization sink such a chain would land on. Fix. The payload is encrypted with the app key using Laravel's encrypter (which also authenticates it), bound to a purpose prefix and the task id. The runner runs only a payload this app sealed for that task, drops anything else, and only looks up UUID task ids. An app with no app key can no longer dispatch async tasks. Only affects 4.5.0+ (async tasks did not exist before then). Apps that don't use async tasks are not affected. 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