PHP2Shell: The Critical PHP Vulnerability Hitting Websites Right Now, and How to Fix It Today

On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws, now widely called PHP2Shell, that can let an attacker take control of a website without a password. PHP runs a large share of the web, including WordPress, Laravel, Drupal, Magento, and countless custom business apps. If your site runs on PHP and nobody has updated it today, assume it is exposed.

As of October 21, 2026, 3:30 PM PT (22:30 UTC). This is a developing story and we will update this post as official guidance changes.

What Happened, in Plain Language

PHP is the programming language that runs the server side of millions of websites. The PHP project disclosed two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and rated both critical (CVSS 4.0 score of 9.2). In the PHP project's words, the fixes address "two critical vulnerabilities that can allow unauthenticated remote code execution."

"Unauthenticated remote code execution" means an attacker on the internet can make your server run their own commands, without logging in and without you clicking anything. From there they can steal customer data, plant malware, send spam from your domain, or use your server to attack others.

Three things make this one urgent:

• It hits PHP itself, not a plugin. The PHP project says the risk is highest for Apache with mod_php, where it has seen "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." Keeping WordPress and its plugins up to date does not protect you on its own.
• Details leaked before the fix. Reports indicate details surfaced publicly on October 20, ahead of the planned disclosure, and the PHP project moved its release up to October 21 at 14:00 UTC.
• Attacks have started. Security firms including watchTowr, Cloudflare, and Datadog report exploitation attempts in the wild as of October 21. Some firms had not yet seen successful attacks in their own customer bases at the time of their reports. The bugs are not yet listed in CISA's Known Exploited Vulnerabilities catalog, but a listing would not change what you should do today.

Am I Affected? A Five-Minute Self-Check

According to the PHP project, the at-risk group is "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." That covers nearly every way PHP websites are hosted. The question is really whether your server is already on a fixed version.

Step 1: Find your PHP version

• WordPress: go to Tools → Site Health → Info → Server. The PHP version is listed there.
• cPanel or shared hosting: look for "Select PHP Version," "MultiPHP Manager," or "PHP Settings" in your control panel.
• Managed WordPress or app hosting: check your host's dashboard and their status page or blog for a PHP2Shell notice.
• Your own server: ask your developer to check the version the web server actually uses, for example through a phpinfo page or the PHP-FPM service. Running php -v on the command line can show a different version from the one serving your site.
• Containers: check the base image tag in your Dockerfile and when each image was last rebuilt.

Step 2: Compare it to the fixed versions

If you're on	You need at least	Status
PHP 8.5	8.5.12	Official fix available
PHP 8.4	8.4.27	Official fix available
PHP 8.3	8.3.36	Official fix available
PHP 8.2	8.2.35	Official fix available (8.2 reaches end of life December 31, 2026)
PHP 8.1, 8.0, 7.x or older	A vendor backport, or an upgrade to 8.2+	No official release. Highest risk.

One catch: Linux distributions often keep an older version number and backport the fix. Ubuntu, for example, has published patched packages for its releases whose version numbers don't match the table above. If your server uses distribution packages, check your distribution's security notice instead of comparing numbers.

If you're on PHP 8.1 or older, the PHP project says those versions "no longer receive updates." Because of the severity, the PHP security team released minimal source backports for 7.4, 8.0, and 8.1, and some distributions and long-term-support vendors provide patched builds. If you rely on the popular Remi package repository, the PHP project advises switching to distribution packages or building from source for immediate updates.

What to Do Right Now

1. Update PHP. This is the only real fix.

The PHP project is blunt: "There are no complete mitigations, updating is the only safe choice." Depending on your setup:

• Managed host: confirm with your host that the patched version is live on your site. Don't assume it is.
• Shared hosting or cPanel: if your host offers a patched version, switch to it, then load your key pages to confirm nothing broke.
• Your own server: install the patched PHP packages from your distribution or vendor, then restart PHP-FPM or Apache so every running worker picks up the new version.
• Containers: rebuild your images on a patched PHP base image and redeploy every service. An old image that keeps running is still vulnerable.

2. If you can't update in the next few hours, reduce exposure

The PHP project lists interim measures. They lower the risk but, in the project's words, they are not complete fixes. Have your developer or host review the official advisory and apply the ones that fit your site:

• Turn off session.upload_progress.enabled and restart every PHP worker.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Keep post_max_size low: 8M if your site has no file uploads, 32M if it does.
• Follow the advisory's memory-limit guidance exactly, including the settings it says not to use, and keep request size limits at your web server or proxy.
• If you're behind Cloudflare, make sure its managed firewall rules are on. Cloudflare says it deployed rules for known attack patterns and is updating them as attackers change tactics. Treat this as a seatbelt, not a fix.

For sites on end-of-life PHP with no backport available, consider taking the site offline or restricting access until it's patched. Reports indicate some organizations pulled services offline preemptively.

3. Check whether someone already got in

Because attacks reportedly began before many sites were patched, updating alone isn't enough if your site was exposed. Warning signs include:

• PHP error logs showing "Allowed memory size ... exhausted" errors that point to "Unknown on line 0", or crashes (segmentation faults) in PHP workers, especially since October 20
• Your web server or PHP processes starting shells, download tools, or other programs they normally never run
• New or recently modified PHP files you don't recognize, especially in upload folders
• New administrator accounts, unfamiliar scheduled tasks (cron jobs), or changed passwords
• Unexpected outbound traffic, spam sent from your domain, or a sudden traffic or CPU spike
• Browser or Google warnings about your site, or customers reporting strange redirects

If you see any of these, don't just patch and move on. The attacker may have left a back door that survives the update. Preserve the logs, rotate credentials (database, admin, API keys, hosting), and have the server checked properly or rebuilt from a known-good state.

How Much Work Is the Fix? Realistic Estimates

Here is what this fix typically takes, by setup. These are hands-on hours for someone who knows the stack, and they include testing that the site still works afterward.

Your setup	What's involved	Typical effort
Managed host that patches PHP for you	Confirm the patched version is live, restart if needed, review logs since October 20	0.5–1 hour
Shared hosting or cPanel, supported PHP	Switch to the patched version, apply mitigations if the host lags, smoke-test the site	1–2 hours
Single VPS or cloud server, upgraded in place	Install patched packages, restart PHP-FPM or Apache, apply mitigations, test, check logs	1–3 hours
Multiple servers or containerized apps	Inventory every PHP runtime, rebuild images, redeploy each service, verify nothing old is still running	4–8 hours for a handful of services; 1–3 days for larger fleets
App stuck on PHP 8.1 or older	Same-day: apply a vendor backport or mitigations and lock down access. Then: upgrade the app and its dependencies to a supported PHP version	2–6 hours same-day; 2–10+ days for the upgrade, depending on the codebase
Suspected compromise	Preserve evidence, investigate, remove back doors or rebuild, rotate credentials, harden	4–8 hours triage per server; 1–5 days for cleanup and rebuild

What makes the job bigger: no staging environment to test in, no current backups, PHP versions several years out of date, abandoned plugins or libraries that break on newer PHP, many sites spread across different hosts, and nobody on the team who knows how the server was set up.

Don't Wait for This One

Most security advisories can sit in a queue for a week. This one shouldn't. The details are public, attackers are already probing for it, and the fix for most sites takes hours, not weeks. The cost of patching today is small. The cost of cleaning up a breached server, notifying customers, and recovering a blacklisted domain is not.

Sources

• PHP project security announcement, October 21, 2026
• PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• Ubuntu: php2shell fixes available
• Datadog Security Labs: PHP2Shell detection and remediation
• Huntress: Rapid response to php2shell
• The Hacker News: PHP issues emergency patches
• USA Today live coverage