Critical PHP vulnerability php2shell explained and how to fix it

What happened

The two flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "php2shell", could let an attacker run their own commands on a web server without logging in. The UK's National Cyber Security Centre issued an alert the same day, encouraging UK organisations to take immediate action (NCSC, 2026).

Laravel is built on PHP, so every Laravel application was exposed until its server was updated. Laravel called the flaws "extremely serious vulnerabilities affecting every PHP application on the web" (Laravel, 2026). DigitalOcean emailed all its customers the same night, warning that an attack could result in "full compromise of the affected system" (DigitalOcean, 2026). For a business, that means customer data, payment flows and admin access sitting on a server someone else controls.

Researchers at the security firms Calif and Wiz found the bugs in August using advanced AI tools. Calif was part of an OpenAI programme called Patch the Planet, which gave researchers access to the company's AI models. The flaws had gone undetected for more than a decade (BBC News, 2026). Coordinated disclosure was set for 22 October, but the CVE identifiers circulated on forums and social media on 20 October, and the PHP project moved the release forward by one day (PHP Foundation, 2026).

"Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated." (NCSC, 2026)

Is anyone being attacked

Attack attempts are confirmed and widespread. Amazon recorded an attempt against its honeypot servers on 17 October, four days before disclosure, and Cloudflare's chief technology officer reported early attacks on 21 October (Amazon Threat Intelligence, 2026; BBC News, 2026). As of 22 October, no successful break-in had been publicly confirmed. The US agency CISA said it had not observed exploitation, and the PHP Foundation said it had found no working exploits at the time of release (CISA, 2026; PHP Foundation, 2026).

The technical detail

Both bugs start with PHP running out of memory mid-request. In CVE-2026-109618, PHP can be interrupted while internal request data is only partly set up, and the clean-up code then treats that broken data as valid. In CVE-2026-109619, internal state belonging to one request can survive after its memory has been freed, and a later request on the same worker may use it (NCSC, 2026).

Risk depends on how PHP is run. Apache with mod_php has a demonstrated attack that works before any application code runs. On PHP-FPM, exploitation depends on the application, and no complete FPM exploit had been shown for CVE-2026-109618 (PHP security advisory GHSA-w8hw-w9fx-j79w, 2026). PHP states that updating is the only complete fix, and the configuration workarounds in circulation only close specific attack paths (PHP, 2026).

Which versions to update to

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (PHP, 2026). PHP 8.1 and older get no official release. The PHP security team published source-code backports for 7.4, 8.0 and 8.1, and several vendors, including Ubuntu Pro, Debian's extended support and the widely used Ondřej Surý repositories, shipped patched builds for older branches (Digital Applied, 2026).

Many of those patched packages keep the old version number. Ubuntu 24.04's own fixed package still reports PHP 8.3.6, for example, so php -v alone does not prove a server is safe; check the package revision against your vendor's security notice (Ubuntu USN-8948-1, 2026). PHP 8.2 also reaches end of security support on 31 December 2026, so an 8.2 server patched today needs an upgrade plan within weeks (PHP, 2026).

What to do now

1. Find every copy of PHP you run, including second PHP versions on the same server, Docker containers, hosting control panels and appliances. Updating the host does nothing for PHP inside a container.

2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's patched package. On Laravel Forge, click "Update PHP" on each server; Vapor apps need a redeploy; Laravel Cloud patched running apps in place (Laravel, 2026).

3. Restart PHP-FPM or Apache, plus queue workers, Horizon and Octane, then confirm the running process started after the update.

4. On PHP 8.1 or older, use a vendor backport if one exists. If not, follow NCSC advice and take the system offline until it is fixed (NCSC, 2026).

5. Check logs for signs of compromise. Amazon advises starting from 17 October (Amazon Threat Intelligence, 2026).

What we saw on the night

As a Laravel Partner, Rocking Tech receives direct updates from the Laravel team, including guidance on this release. We patched our own and clients' servers over 21 and 22 October, and the update itself was the easy part.

On Ubuntu servers using the Ondřej Surý repository, apt offered PHP 8.2.34 for several hours after release, one version short of the fix, so a routine upgrade would have left a server restarted and still exposed.

Once the fix was published, Canonical's download servers buckled under worldwide demand. On one server, six of 16 packages failed to download on the first attempt, and one package failed ten times in a row before it came through. By the next morning the same downloads finished in under a second.

A version check before installing, and a check of the running process afterwards, caught both problems. Older servers were harder. Long-running PHP processes, unsupported Ubuntu releases and PHP pools reached through hidden proxy layers all turned a ten-minute patch into an audit. Our Laravel Support & Maintenance retainers apply framework and package security patches as advisories are released, not at month end, and keep every change committed, tested and traceable.

If you need help with your PHP or Laravel application, get in touch.