PHP Vulnerability 2026: What PHP2Shell Means for Your Website, and What to Do Today

If your website runs on WordPress, WooCommerce, Magento, Drupal, Joomla or Laravel, this one is for you. On October 21, 2026, the PHP team shipped an emergency security release for two critical flaws in PHP itself. Not a plugin. Not a theme. The language your site is written in.

We know “critical vulnerability” headlines get posted every week and most people scroll past them. This one deserves a proper read. It is being exploited, it needs no login to trigger, and the fix is not something you can click inside your WordPress dashboard. So let us walk through what actually happened, who is at risk, and what you should do, in plain language.

The short version

What: Two critical remote code execution (RCE) flaws in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”.
Severity: Both are rated 9.2 (Critical) on CVSS v4.0, and neither needs a username or password to attack.
Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026.
Who is affected: Any PHP installation that serves web requests. Wiz Research reports affected versions going back to PHP 5.4.
Is it being exploited? Yes. Attack attempts were seen before and right after the patch was published.
Your move: Make sure your server is running a patched PHP build, then check for signs of compromise and rotate secrets.

What is PHP2Shell, exactly?

“PHP2Shell” is the nickname the security community gave to a pair of vulnerabilities in the PHP runtime. The name says it all: an attacker sends a request to a server and gets the ability to run commands on it, a shell.

The PHP project itself refers to the flaws only by their CVE numbers. According to PHP’s advisory, they are two separate mechanisms:

CVE-2026-109618 (RCE via out-of-memory corruption). When PHP runs out of memory, it can be interrupted before it fully sets up internal request data. The cleanup step afterwards may then treat that half-built data as valid. Researchers note an attacker can force the out-of-memory condition using crafted multipart requests that look normal on the surface.
CVE-2026-109619 (RCE via stale global state). PHP keeps some internal state that points to memory owned by a single request. If that state survives after the memory is freed, a later request handled by the same worker can end up using it. This is a classic use-after-free bug.

Here is the part that makes this scarier than your average CVE. Because these flaws sit in the PHP core, exploitation does not depend on a bug in your application code. Wiz reports that a single unauthenticated request can trigger the attack before any application code even runs.

Plain-English analogy: imagine a restaurant kitchen where a cook is pulled away mid-recipe and the next shift trusts the half-finished dish on the counter. The ingredients were never the problem. The handover was.

How it came out: a leak, a rush, and a pulled-forward patch

The disclosure did not go as planned. Here is the sequence as reported by Help Net Security, Black Kite and other outlets:

Date (UTC)	What happened
Oct 17, 2026	Amazon Threat Intelligence says its MadPot honeypot network recorded a PHP2Shell exploitation attempt, four days before public disclosure. How the attacker got details early is still unknown.
Oct 20, morning	An anonymous-style post on Hacker News claims two PHP RCE flaws will be disclosed on October 22. The post is taken down, but screenshots spread. Kevin Beaumont and watchTowr indicate the flaws are real.
Oct 20, 19:33	The PHP team publishes an advance notice of an upcoming critical security release.
Oct 21, 14:00	Patched versions and the official advisories go live, a day earlier than planned. That is 7:30 PM IST.
Oct 21 to 22	Cloudflare, watchTowr and others report exploitation attempts. Public proof-of-concept code begins circulating.

The flaws are credited to multiple researchers, including Wiz Research and calif.io. Wiz says frontier AI models made a difficult exploit chain practical to build, and Google states that AI models, including Gemini, helped with discovery, exploit development and patch validation. That is worth sitting with for a moment. Bugs that stayed hidden for years because exploiting them was extremely hard are now getting found and weaponised faster.

Who is affected?

PHP’s own advisory says every installation serving web requests is at risk, whatever the setup: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk is on Apache with mod_php, where a working exploit was validated against a default configuration.

Patch status by PHP version

PHP branch	Fixed version	What it means
8.5	8.5.12	Official fix available.
8.4	8.4.27	Official fix available.
8.3	8.3.36	Official fix available.
8.2	8.2.35	Official fix available.
8.1, 8.0, 7.4	No official release	End of life. PHP published minimal source backports, and some vendors such as cPanel (EasyApache) ship their own fixed builds. Check with your host.
7.3 and older, 5.x	None	No official fix. Upgrade or take the site off the public internet.

One detail catches people out. Distributions like Ubuntu, Debian and Red Hat often patch security bugs without changing the PHP version number. So a version number alone does not always tell you whether you are safe. Check your distribution or host’s security notice instead of guessing.

How big is the exposure?

PHP is used by roughly 69.7% of websites whose server-side language is known, according to W3Techs data cited by Infosecurity Magazine. Numbers on how many servers are exposed vary by who is counting, so treat them as indicators and not a final tally:

Palo Alto Networks (Unit 42) reports its telemetry found over 22.6 million exposed instances that are potentially vulnerable.
Black Kite’s Shodan analysis found about 1.9 million internet-facing PHP hosts (honeypots excluded). Of the roughly 1.37 million that reveal their version, 72.5% run end-of-life branches that no longer get regular fixes.
VirusTotal data cited by Black Kite counts about 538,000 internet-facing WordPress instances on PHP hosts.

It is not only websites. Palo Alto Networks confirmed that all versions of PAN-OS and Panorama are affected, and as of October 22 it had not shipped fixed PAN-OS releases. Fortinet and Cisco were still checking their products. If a device has a web interface, it may be running PHP behind the scenes.

What does this mean for WordPress and WooCommerce sites?

This is where most of our readers will land, so let us be direct.

Updating WordPress or your plugins does not fix this. PHP is not updated from wp-admin. Your host, or whoever manages your server, has to install the patched PHP and restart it.
Switching PHP version in cPanel is not the same as patching. That menu only changes which version your site uses. It does not install the security fix.
Hosts are moving at different speeds. On October 21, GoDaddy said it had patched all PHP versions on its Managed Hosting for WordPress, was still waiting for vendor packages for some other plans, and that VPS customers must update PHP themselves. Other providers have published their own statuses, so ask yours.
Self-managed VPS or dedicated server? This one is on you. Patch first, ask questions later.

Wiz also reports demonstrating unauthenticated code execution against WordPress, Drupal and Joomla deployments, on the grounds that these are representative PHP targets and not because of any flaw in those platforms themselves.

Is it really being exploited?

Yes, and the signals come from several independent sources. Amazon recorded an attempt on October 17. Black Kite, citing public reporting, says Cloudflare saw the first attacks at 07:43 UTC on October 21, more than six hours before the patch. watchTowr reported active exploitation attempts on October 22, and Singapore’s Cyber Security Agency says it is aware of widespread exploitation attempts. At the time of writing, no confirmed breach of a named organisation had been reported.

Cloudflare has deployed WAF rules for the known exploit paths to all customers, including free plans. That is useful as an extra layer. But Cloudflare’s own CTO stressed that only updating PHP fully protects a site. A WAF also only helps if attackers cannot reach your origin server directly.

What to do right now: a practical checklist

Find out who is responsible for PHP on your site. Shared or managed hosting means your provider. VPS or dedicated means you.
Ask your host in writing. Have they installed a patched PHP build, and have they restarted the PHP workers? Get a clear yes or no.
If you manage the server, update PHP. Go to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. Patch internet-facing systems and Apache mod_php setups first.
Verify the right binary. The PHP version your command line reports (php -v) can differ from the one actually serving your website, such as PHP-FPM. Check the web-serving one.
On PHP 8.1 or older, plan an upgrade. A vendor backport is a bandage, not a strategy. These versions no longer receive regular security fixes.
Rebuild containers. If you use Docker, Cloud Run or Kubernetes, rebuilding and redeploying images with patched PHP is on you. The host patch does not reach inside your images.
Check for compromise. Because attacks started before the patch, being patched and not being hacked are two separate questions.
Rotate secrets. More on this below.

If you cannot patch immediately, the UK NCSC and CERT-EU both advise considering taking the affected system offline or isolating it from the public internet until it is fixed.

Temporary measures PHP recommends (only if you cannot patch yet)

PHP’s advisory is blunt: there is no complete mitigation, and updating is the only safe choice. These settings only reduce exposure to specific attack paths, and they must be set in php.ini, the PHP-FPM pool or the server config (not via ini_set or .user.ini), followed by a restart of every PHP worker:

Setting	Why it is suggested
session.upload_progress.enabled = 0	Blocks the confirmed session path used for CVE-2026-109619. Session upload progress will stop working.
fatal_error_backtraces = 0 (PHP 8.5)	Removes a confirmed attack path for CVE-2026-109619 on PHP 8.5.
memory_limit = -1	Removes the memory-limit failure that CVE-2026-109618 depends on. The trade-off is that a single request can use all of the server’s memory, so apply with care.
pm.max_requests = 1 (FPM pool)	Recycles the worker after each request to stop state carrying over. Costs performance.

Please do not treat that table as a fix. If your sysadmin is unsure about any of these, the safest path is still the update.

After patching: check for compromise and rotate secrets

Besides code execution, PHP’s advisory confirms that these flaws can leak PHP worker memory. That memory can contain passwords, tokens, API keys, and even TLS private keys. So if your server was reachable before it was patched, take these steps:

Look inside wp-content/uploads. That folder is for images and documents. A .php file there is a red flag.
Scan your error logs. A burst of “Allowed memory size exhausted” fatal errors around October 21 is worth a closer look, since forcing an out-of-memory error is the trigger for CVE-2026-109618.
Watch for odd processes. PHP or web server processes launching shells or download tools (sh, bash, curl, wget) are a warning sign.
Check persistence. New cron jobs, unfamiliar SSH keys, recent unusual logins and strange outbound connections.
Rotate what lives on the server. Database credentials, third-party API keys, WordPress salts and application keys, and origin TLS keys.

Security firm Searchlight Cyber has also released an open-source scanner, php2shell-scanner, that tests whether a host is exposed to both CVEs. Use scanners only on systems you own or are authorised to test.

PHP2Shell is not the only PHP security story of 2026

It dominates the headlines, but PHP’s own security advisory page shows a steady flow of other fixes this year. A few examples, using the titles from the php-src advisories:

May 2026: a use-after-free in SOAP involving the Apache map type with remote code execution (rated High).
July 2026: a remote denial-of-service when TLS setup with a remote server fails (High), plus a SQL injection issue in ext-pgsql through a backslash breakout in E’…’ strings (High) and an out-of-bounds write in bccomp() (High).
September 2026: an out-of-bounds read in the HTTP stream wrapper when following a redirect with an empty Location header (Moderate).

The lesson is boring but true. Running a supported PHP version and applying security releases promptly is worth more than any single clever tool.

Lessons for website owners

Know your stack. Many business owners cannot say which PHP version their site runs or who updates it. That gap is where incidents breed.
Retire old PHP. Black Kite’s data suggests most version-disclosing PHP servers online run end-of-life branches. Do not be one of them.
Have a patch owner and a patch window. When a critical fix drops on a Wednesday afternoon, someone should already know it is their job.
Layer your defences, but patch first. WAFs, backups, least-privilege file permissions and monitoring all help. None of them replace the update.
Keep a rebuild-ready setup. If you use containers or infrastructure as code, a patched rebuild should be routine, not an emergency.

Need a hand?

At Fotoplane, we build and look after websites for NGOs, e-commerce brands, institutes and advisory firms, so we see how often basics like PHP versions and hosting hygiene get overlooked. If you are not sure which PHP version your site runs, whether your host has patched, or whether you need a technical audit, get in touch with our team and we will help you find out.

Frequently asked questions

What is CVE-2026-109618
It is a critical remote code execution vulnerability in PHP core, caused by how PHP handles out-of-memory errors. It carries a CVSS v4.0 score of 9.2 and is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
What is CVE-2026-109619?
It is a critical remote code execution vulnerability caused by stale global state, where request data survives after its memory has been freed. It also scores 9.2 and shares the same fixed versions.
Is my WordPress site affected by the PHP vulnerability in 2026?
If your site runs on PHP, which WordPress does, it is potentially affected until the server’s PHP is patched. The fix comes from your host or server administrator, not from a WordPress update.
Which PHP version should I use now?
Use a patched, supported release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. If you are on 8.1 or older, plan an upgrade to a supported branch.
Can a firewall protect me instead of patching?
It can reduce risk. Cloudflare, for instance, has rolled out WAF rules for the known exploit paths. But PHP and Cloudflare both say updating is the only complete protection.
Do I need to change passwords and keys?
If your server was reachable before patching, yes, it is wise. The flaws can expose worker memory, which may hold credentials, API keys and TLS private keys.

Sources

This post is built from primary and reputable secondary sources, checked on October 23, 2026. The story is still developing, so check the PHP advisory for the latest.

Primary (PHP aur researchers)