On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, each scored 9.2 out of 10, that can allow unauthenticated remote code execution. The PHP security team's own advice is to update immediately: there are no complete mitigations. PHP 8.1 and older get no new release from the PHP project.
Every Laravel application runs on PHP, so this one reaches every Laravel app whatever the framework version. This is the plain-English version for owners and the people who look after the app: what was fixed, who is exposed, a five-minute check, and what to do when the server runs a PHP version that no longer gets releases.
What was released
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), "RCE via OOM corruption": out-of-memory handling can interrupt PHP while internal request data is only partly set up, and the clean-up step can then treat that invalid data as valid.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), "RCE via stale global state": internal state belonging to one request can outlive its memory, and a later request handled by the same worker can use it before it is reset.
Fixed versions, one per supported branch:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
Source: the php.net security advisory.
Who is at risk
According to the advisory, all PHP installations that serve web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates the risk highest for mod_php, where it has demonstrated an exploit that an unauthenticated request can trigger before any application code runs. That last point matters for Laravel owners: your app's own security does not help, because the attack happens in PHP before Laravel starts.
How to check in five minutes
Which Laravel version is your app on?
Paste your composer.json into the free audit. Within 24 hours you get the end-of-life dates, the abandoned packages, and a fixed price for bringing it current.
- Find the PHP version the production server runs. Ask whoever has access to run
php -von the server, or look at the PHP selector in your host's control panel (Forge, Cloud, cPanel, Plesk). The"php"line incomposer.jsonis only the oldest version the app allows; it says nothing about what the server runs. - Check the web server's PHP, not just the command line. PHP-FPM can be a different build from the CLI. A temporary
phpinfo()page, removed straight after, or the host panel shows the one serving requests. - Compare against the fixed versions above. On 8.2 to 8.5, anything below the listed release is exposed. On 8.1 or older, read the next section.
Or paste your composer.json into the free Laravel audit and we will tell you in writing within a day what the app needs to move to a supported PHP version.
What to do on PHP 8.2 to 8.5
Update PHP to the fixed release for your branch, then restart every PHP worker (PHP-FPM, Apache, FrankenPHP, LiteSpeed) so the old code is no longer in memory. On managed hosting, check your provider's notices: Linux distributions and long-term support vendors received the patches in advance. If the app runs in containers, rebuild on the patched base image and redeploy. PHP 8.2 itself stops receiving security fixes on 31 December 2026, so an 8.2 server needs a second move before the end of the year.
What to do on PHP 8.1 or older
PHP 8.1 stopped receiving security fixes on 31 December 2025 and PHP 8.0 on 26 November 2023. The PHP project has published no new 8.1, 8.0 or 7.4 release. What exists instead:
- Vendor backports. Some Linux distributions and long-term support vendors provide backported fixes for older PHP. If your server's PHP comes from one of them, ask which package version carries the fix, install it, and restart the workers.
- Minimal source backports. Given the severity, the PHP security team published minimal source-code backports for PHP 7.4, 8.0 and 8.1, for people who build PHP from source or have no vendor. That is a stop-gap, not a supported release: nothing guarantees the next advisory gets the same treatment.
- Move to a supported PHP version. The only lasting fix. How hard it is depends on the Laravel version, because each Laravel version supports a fixed range of PHP versions.
Where Laravel versions land:
- Laravel 9 runs on PHP 8.0–8.2, so it can move to the patched PHP 8.2 without a framework upgrade, though PHP 8.2 itself ends on 31 December 2026.
- Laravel 10 runs on PHP 8.1–8.3, so it can move to PHP 8.3 without a framework upgrade.
- Laravel 8 or older tops out at PHP 8.1 or earlier, so there is no supported PHP version it can run on. Getting a fix means upgrading Laravel first.
Our PHP 8.2 end-of-life guide and the Laravel 11 and 12 end-of-life guide cover the routes in more detail.
If you cannot update today
The advisory lists measures that reduce exposure to specific attack paths but, in its words, do not make an installation safe. In summary: lower post_max_size, set limits at the web server or proxy, set session.upload_progress.enabled=0 in php.ini or the FPM pool and restart every worker, and follow the memory-limit guidance in the advisory exactly as written. Read the advisory itself before changing anything; some of the settings have side effects, and a wrong one can make the problem easier to trigger.
After you update
Now that the details are public, attempts to use these flaws are likely. Once patched, it is worth a look for anything that should not be there: unexpected PHP files in public/ or storage/, admin users nobody created, files changed outside a deploy, and unusual outbound connections from the server. If you find something, treat it as an incident and take advice on your reporting duties.
What it costs with us
- Upgrade Sprint, £1,900 or €2,300, 7–10 working days. One or two Laravel majors and the move to a supported PHP version, test suite green, staging sign-off before production.
- Full Upgrade, £3,400–£4,500 or €4,100–€5,500, 2–3 weeks. For apps on Laravel 8 or older: several majors, abandoned packages replaced, tests written where they are missing.
Start with the free audit. You get the PHP and Laravel versions, what applies to you, and a fixed price in writing.
Frequently asked questions
Is Laravel itself affected?
The flaws are in PHP, not in Laravel. But every Laravel app runs on PHP, and the advisory describes an attack that can start before any application code runs, so the framework cannot protect you. Update PHP.
Does composer update fix this?
No. Composer updates the app's packages. PHP is the runtime installed on the server, and only updating it, or the server image, fixes this.
We are on Laravel Forge or Laravel Cloud. Anything to do?
Check the provider's notices for patched PHP versions or images, and redeploy or restart if they ask you to. Then confirm with php -v that the server reports the fixed version.
Our host says it will patch PHP 7 for us. Is that enough?
For this advisory it can be, if the host applies a backported fix: ask which build carries it and confirm the workers were restarted. It does not change the bigger picture: the PHP project no longer releases fixes for that version, so every future advisory depends on the host doing the same again.
