PHP2Shell: The Critical PHP Security Flaw Every Website Owner Should Patch Now

On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell". Both are flaws in PHP itself, the engine that runs a very large share of the web, including Laravel applications, WordPress sites, online shops and custom business software.

If your website or application runs on PHP, this one is worth your attention today. Here is a plain-English guide to what happened and what to do about it.

What happened

Security researchers found two related weaknesses in how PHP handles web requests. Both are rated critical (security vendors report a score of 9.2 out of 10 on the CVSS v4.0 scale) because of what an attacker can achieve:

• No login is required. The attack can be started by an unauthenticated visitor sending requests to your site.
• Remote code execution. A successful attack lets the attacker run their own code on your server, with the permissions of the web server account.
• It happens inside PHP, not inside your application. That means a well-written, fully updated app can still be exposed if the PHP underneath it is not patched.

How it works, without the jargon

The two flaws share a root cause: PHP can be left with its internal memory in a damaged state when a web request ends abnormally.

• CVE-2026-109618: if PHP runs out of memory part-way through setting up a request, some of its internal data is left half-built, and the cleanup code afterwards wrongly trusts it. Attackers can chain this with other weaknesses to take control.
• CVE-2026-109619: some information that belongs to a single request can survive after the memory behind it has been released. In servers that keep PHP workers running between requests, a later request can then touch memory it should not, which can leak data and lead to code execution.

You do not need to follow the technical detail. The practical point is that an attacker can deliberately trigger these conditions, and the consequences are severe.

Who is affected

Any PHP installation that serves web requests is in scope. That includes PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed and FrankenPHP. The PHP team considers Apache with mod_php the highest risk, because an attack can fire before any of your application code even runs.

Whether you are exposed comes down to the PHP version your server is actually running:

• PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, and 8.2 before 8.2.35 are vulnerable. Update to those releases or newer.
• PHP 8.1, 8.0 and 7.4 no longer receive official releases. Minimal source backports have been published, and some Linux distributions and long-term-support vendors ship patched packages that keep the old version number.
• PHP 7.3 and older are affected and have no fix. They need to be upgraded.

This applies regardless of the software on top. Laravel, WordPress, Magento, custom code and admin tools such as phpMyAdmin all depend on the PHP runtime underneath. Updating a framework or plugin is not a substitute for updating PHP.

What to do right now

1. 1Make a list of everything that runs PHP: production sites, staging servers, old projects, admin panels and anything on shared or managed hosting. Start with what is reachable from the internet.
2. 2Update each one to the fixed release for its branch, or install your operating system's patched PHP package. If you use containers, rebuild your images and redeploy.
3. 3Restart PHP-FPM, Apache or whatever serves PHP. The fix does not take effect until old workers are replaced.
4. 4Verify. Check the PHP version actually running on each server, not only what you intended to install. Where a distribution keeps the same version number, look in the package changelog for the CVE numbers.
5. 5Upgrade anything on PHP 8.1 or older to a supported version, or use a vendor that provides backported security fixes.

If you cannot patch immediately

The PHP team has published interim settings that reduce exposure, such as raising or removing the memory limit where applications cannot override it, lowering the maximum request size, and turning off session upload progress. A web application firewall with emergency rules can also help.

Be clear about their limits, though. The PHP team states that these measures do not fully protect you, and that patching is the only permanent fix. If a system cannot be updated yet, restrict who can reach it and plan the update as the very next task.

Are you on shared or managed hosting?

Then your provider updates PHP for you, but do not assume it has happened. Ask them to confirm in writing that the October 21 fixes are installed and the workers have been restarted. If your host cannot give you a clear answer, that is useful information too.

Check for signs of a break-in

If a server was running an unpatched, internet-facing PHP version since October 21, it is sensible to look for signs of compromise rather than assume it is clean. Things to check include:

• Unfamiliar or recently changed PHP files, especially in upload and cache folders
• New administrator accounts or unexpected changes to existing ones
• Unusual scheduled tasks (cron jobs) or background processes
• Unexpected outbound connections or sudden spikes in traffic or CPU use
• Strange entries in web server and PHP error logs, such as repeated crashes or out-of-memory errors

If you find anything suspicious, take the system offline, restore from a known-clean backup, and rotate passwords, API keys and any secrets stored in configuration files.

Lessons worth keeping

• Run a supported PHP version. Branches that no longer get security releases leave you waiting for someone else's backport. PHP 8.2 itself reaches end of life at the end of December 2026, so plan its replacement now.
• Make patching routine. Automated updates for the operating system and runtime, with a quick staging test, turn emergencies like this into a normal Tuesday.
• Keep layers of defence. A firewall, least-privilege server accounts, monitoring and tested backups limit the damage when something slips through.
• Know what you run. You cannot patch what you do not know exists, and forgotten staging sites and old microsites are common weak points.

“Security is rarely about one dramatic fix. It is about knowing what you run, keeping it current, and being able to respond quickly when something like this is announced.”

Need a hand?

If you would like help checking which PHP versions your sites are running, applying the update, upgrading an older application to a supported version, or hardening your setup afterwards, our team works with Laravel and PHP every day. Get in touch and we will point you to the quickest safe route.

This article reflects information published up to November 5, 2026. Security advisories can change as researchers learn more, so check the official PHP security announcements for the latest guidance.

Written by

BrandBuilders Team

Editorial Team