Security Notice

Laravel Security Notice: Critical PHP Security Release ⚠️

[Notice #5] A Critical PHP Security Release is coming very soon - you need to be ready to patch your servers.

Two CRITICAL security vulnerabilities will be patched in PHP on Wednesday 21st October at 2pm UTC (Midnight AEST, 10am US Eastern, 7am US Pacific, 3pm UK) . No details have been provided beyond an announcement that the patches are coming - as per the official announcement.

The two vulnerabilities have been designated CVE-2026-109619 and CVE-2026-109618, nicknamed PHP2Shell by some.

The PHP security team would like to give advance notice of an upcoming security release.
It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.
It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.
All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.
We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
Full details, affected versions, and the fixed versions will be published with the release.
Thank you for helping us keep PHP secure.

No details have been released yet - to prevent exploitation until patches are available, so unfortunately all we can do wait and get ready to patch things. I don't know any details, but given they brought it forward due to the announcement leaking out early, this is likely to be a bad one. It affects version 5 onwards, so you unless you're still on PHP 4, you will be affected by this in some way. I'll update this article once the details are released.

The Laravel Team have already confirmed they are working on how best to deploy patches quickly to Cloud, Forge, and Vapor.

If you host your apps elsewhere, check in with your hosting providers and your ops teams to make sure they are aware and prepare your update procedures.

The PHP Supported Versions plan indicates that only PHP 8.2, 8.3, 8.4, and 8.5 will be patched. If you are running an older version (version 5 onwards!), you will still be vulnerable after patches are released.

Even if you're running a supported version of PHP, if your Operating System is no longer supported, then you may not receive patches. For example, if you're on Ubuntu, you need to be on 22.04 LTS or newer.

I would also recommend running updates now as a precaution (i.e. get everything else updated now), so if there are any issues with either your update process or specific updates, you can get them fixed before the PHP update drops. Once the update drops, you'll want to focus all of your attention on that alone.

I wish I could provide more information, but that's all I've got for now. I'll update this post as I learn more. Stay safe everyone!

Quick Checklist

Confirm your PHP version is 8.2 - 8.5 (older = no patch, plan an upgrade).
Check your OS is still supported (e.g. Ubuntu 22.04 LTS+) or you may not receive the patch.
Run all your other updates now, so the only thing to do when the patch drops is the patch.
Check in with your host / ops team and confirm your update procedure.
Watch for the release at 14:00 UTC and patch immediately.

Update #1

Sometimes security updates are applied to unsupported versions anyway, however Ben Ramsey has confirmed "The PHP project is only releasing patches for 8.2, 8.3, 8.4, and 8.5. Distros might backport the patches to earlier versions, so check with them."

Update #2

A ini config mitigation is going around that claims to protect against these vulnerabilities. While making the config change may prevent some of the attack from being effective, it won't stop the complete attack so applying the patches as soon as they are available is still essential.

I won't link to the source (they irresponsibly disclosed a PoC and details, so I won't give them credit), the php.ini / .user.ini / .htacess change you can make is:

session.upload_progress.enabled = Off

Update #3

Cloudflare have advised that they have deployed WAF rules to block known exploit vectors - which is available to all customers (including free). They are monitoring attacks and will keep updating rules as they see more vectors. This isn't going to be a perfect fix, but it's a good protection to have in-place until you have the patch installed. If your site isn't behind Cloudflare, maybe consider doing it temporarily until you've patched.

Also, The PHP Foundation have advised that the volunteer maintained package repository rpms.remirepo.net will not be updated immediately. They recommend switching to distro packages or building from source for now, until it is updated with the patches.

Update #4

2 hours until the patch drops...

Laravel have advised:

At 14:00 UTC two critical security vulnerabilities will be patched in PHP.

These are extremely serious vulnerabilities affecting every PHP application on the web.

Laravel Cloud customers: we will begin automatically patching your applications as soon as the patch is released. No manual action is required.

Laravel Forge customers: you will need to manually update your server’s PHP version via the server’s Forge dashboard. If you are unable to update your server, it should be powered down.

Laravel Vapor customers: we will begin automatically re-deploying applications running on PHP 8 as soon as the patch is released. No patch is being released for PHP 7 – immediately update all applications to PHP 8.

Note, only PHP 8.2 and above will receive patches.

Update #5

30 minutes until the patch drops...

Kath Young has a trick that may be useful for updating PHP on your Forge servers, especially if you have a lot of servers and sites!

The Forge API has an endpoint that allows you to push patches for PHP versions, which you should be able to use to iterate through your fleet and push updates for everything via a script. Which should save you a lot of time clicking around!

You can find the docs here: https://laravel.com/forge/docs/api-reference/servers/update-installed-php-version

PUT https://forge.laravel.com/api/orgs/{organization}/servers/{server}/php/versions/{phpVersion}

Kath notes that there is potential confusion when identifying the PHP version to update, so has provided these instructions:

Matching PHP versions in Laravel Forge’s API

I ran into a small annoyance while scripting PHP updates through the Forge API: the server tells you which PHP version it uses, but that isn’t the identifier you need to patch it.

Ask Forge for your servers and you’ll get data that looks something like this:

Illuminate\Support\Collection {#10570
    all: [
        68 => Laravel\Forge\Resources\Server {#10606
            +attributes: [
                "id" => 1226812,
                // ... other attrs
                "php_version" => "php84",
                "php_cli_version" => "php84",
            ],
            // ... other attrs
        }
    ]
}

PHP 8.4 is reported as php84. Fair enough.

Except the endpoint to update an installed PHP version wants Forge’s internal identifier for that installed version.

To get that, you need another request:

https://forge.laravel.com/api/orgs/{organization}/servers/{server}/php/versions

Which returns PHP version resources like this:

Laravel\Forge\Resources\PHPVersion {#10468
    +attributes: [
        "id" => "1289424",
        // ... other attrs
        "version" => "8.4",
        "binary_name" => "php8.4",
    ],
    // ... other attrs
}

So now we have php84, 8.4, php8.4, and 1289424 referring to the same installed PHP version.

There’s no direct match between the server’s php_version and the ID the update endpoint expects, so we need to join the dots ourselves...or, as it happens, remove one.

My solution was to create a DTO for the installed PHP version data, with a calculated matchVersion attribute. That’s just binaryName with the dots removed: php8.4 becomes php84, matching what the server reports.

Using a DTO also lets me serialise and unserialise the collection for caching, saving repeated API calls.

Then my patch method fetches the installed versions for the server, finds the matching matchVersion, and uses its internal ID to build the update request:

public function patchPHP(string $serverId, string $phpVersion)
{
    $versions = $this->phpVersion($serverId);
    $currentVersion = $versions->where('matchVersion', $phpVersion)->first();

    if (!$currentVersion) {
        throw new \Exception('No matching server version');
    }

    $phpVersion = $currentVersion->id;
    $uri = "orgs/{$orgId}/servers/{$serverId}/php/versions/{$phpVersion}";

    $response = $this->forgeApp->guzzle->request('PUT', $uri);

    if ($response->getStatusCode() == 202) {
        return true;
    } else {
        return false;
    }
}

With that little translation in place, I can pass in the server’s reported php84 and have the method resolve the installed version ID Forge actually wants. It's a bit more fiddly than I expected, but it does the job.

Update #6

20 minutes until the patch drops...

Wiz Research have published an information page about the vulnerabilities over at https://www.php2shell.com/, and mitigation steps if you cannot update immediately.

Update #7

The patches are live over at https://www.php.net/!

The fixed versions are: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Full details published:

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Both vulnerabilities require a patch to fully fix, although there are some mitigation steps you can take to slow down attackers and minimise some of the risks.

I'll update again when I've confirmed patches are updated in the repos for Ubuntu.

Update #8

30-ish minutes after... (12:14 am AEST)

It's important to note that Cloudflare's one-click mitigation might not be automatically enabled if you have a non-free Cloudflare account.

Head over to https://dash.cloudflare.com/?to=/:account/:zone/security/security-rules to check if you need to enable it.

Update #9

12:29 am AEST

Ubuntu have released their security advisory: https://ubuntu.com/security/notices/USN-8948-1

I don't think the Forge packages are available as yet. Will update once I confirm.

Update #10

12:50 am AEST

As per the Forge advisory:

It looks like the patches are available Ubuntu 26.04 LTS but not 24.04 and 22.04. Still waiting for more details regarding those.

Update #11

1:00 am AEST

The PPA updates are currently building:

Update #12

1:17 am AEST

Instead of waiting for the 22.04 and 24.04 updates to land in the Launchpad PPA, you can switch repos to the version here: https://packages.sury.org/php/README.txt

This is confirmed by the Laravel team as safe for Forge servers.

Update #13

1:51 am AEST

The Laravel team are working through Cloud patches, with most of the regions done. Check out https://twitter.com/laravel for their progress updates.

Forge is still struggling under the load - the team is working on it.

The PPA packages are still building:

Update #14

3:07 am AEST

As per the Laravel upate:

The final Laravel Cloud regions are being patched.

Vapor packages are ready, you can either trigger a redeploy now (if you haven't already), or wait for the the team to automatically deploy your apps. Docker runtime customers need to monitor their images for updates.

Forge is still in progress, the server is seeing a large number of queued update jobs. The PPAs for 22.04 and 24.04 are still pending. If you want to apply the patch now, SSH onto the server and swap over the repo to https://packages.sury.org/php/README.txt. Check out their guide here: https://laravel.com/forge/docs/knowledge-base/php-security-release-october-2026

It's 3:11 am here in Brisbane and I need to do the school run in a couple of hours, so I'm signing off for the night. Will pick this back up tomorrow. Night all!

You can find my wrap-up post here: