PHP Vulnerability (php2shell): What WordPress Stores Must Do

On October 21, the PHP project patched the PHP vulnerability now known as php2shell: two flaws that let an attacker run code on a PHP website without logging in. PHP runs about seven in ten websites, and every WordPress, WooCommerce and Magento store is one of them. OpenAI, whose partner found one of the flaws with an AI model, called it "one of the most impactful security issues in recent memory".

Our take, before the detail. For the first time at this scale, the finder was a machine working for the defenders. OpenAI says that, to its knowledge, AI found the flaws before attackers did, and that bought two months of quiet preparation: fixes for four PHP versions, firewall rules at Cloudflare and others, and briefings to governments. Then the details leaked a day early, and attack traffic started hours before the patch was out. That is the new shape of a critical flaw, and OpenAI itself expects "similar findings to increase sharply in the coming months". The lesson for a store is not about AI. It is that the time between "a fix exists" and "the fix is on my server" is the one variable you control, and it has to shrink from weeks to a day. As a note, we checked while writing this and none of our systems runs PHP.

What the PHP vulnerability is

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619. The project's advisory is blunt: all PHP installations serving web requests are at risk, and updating is the only complete solution. CISA told organizations to patch immediately and, if they cannot, or if they run PHP 8.1 or older, to take those systems offline until they can. Parts of Wikipedia, several large forums and a few Dutch government sites did exactly that for some hours. Nothing in this needed an employee to click anything, which is the pattern we described in the zero-click article.

Who is affected

If your store runs on WordPress with WooCommerce, or on Magento, it runs on PHP, and the flaw sits underneath your store's code. Sansec, who specialize in store security, put it plainly: stores are affected even when their own code is clean, and the attack was demonstrated against current WordPress and Magento. Other platforms built on PHP are in the same position, and so is the WordPress blog sitting next to a store that runs on something else. Hosted platforms that run their own servers owe you a one-line confirmation that they have patched, and you have nothing to update there yourself.

One thing changes nothing: updating WordPress, a theme or a plugin. WordPress said so itself. No WordPress update is required or planned, because the fix is in PHP.

What to do first

• Find your PHP version. In WordPress: Tools, Site Health, Info, Server. In Magento or in your hosting panel, the PHP selector. You want 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
• If your host manages PHP, which is most stores, read their notice or ask in writing. Hostinger, for instance, is rolling the fix to managed plans while leaving VPS customers to update themselves.
• If you are on PHP 8.1 or older, this is the forced upgrade. A third of PHP websites still run versions the project no longer fixes. Some hosts backported the patch; ask which build they use.
• Keep the firewall on. Cloudflare's rules were live before the patch and block known attempts, free plan included. Cloudflare's own advice is to patch anyway.
• After patching, look for signs. New admin users, changed checkout or payment pages, redirects, plugins you did not install. One of the two flaws can leak server memory, passwords and keys included, so Patchstack advises rotating credentials on any server that sat exposed.

About "take your site offline"

CISA, the UK and the EU all said that organizations unable to patch should consider taking systems offline, and some did. We are not telling you to close your store. We are pointing out what it means that serious agencies said it at all: this is the level of flaw where an hour of lost sales was judged cheaper than an hour of exposure. By October 22, Sansec reported that mass exploitation looks less likely than feared, because the public exploits need specific conditions on the target, and said in as many words: "You do not need to take your store offline. Update PHP anyway."

The scam that follows every big flaw

Within days, expect emails and WhatsApp messages impersonating your host: your site is vulnerable to php2shell, log in here to apply the update. The real update never asks you to log in through a link someone sent you. The right move is the one from our last article: go to your host's own site, not the link, and tell whoever runs IT. If you want to know who on your team would click the fake update, run a free phishing test for employees.

Frequently asked questions

Is this a WordPress flaw? No. It is a flaw in PHP, the language WordPress, WooCommerce, Magento and many other platforms run on. That is why updating WordPress does nothing and updating PHP fixes it.

My host says it patched. Am I safe? Check the version yourself in Site Health. If the host was slow, or if you cannot tell when it patched, rotate the store's admin passwords and API keys and look for the signs above. The memory-leak flaw means a patched server can still be carrying a stolen secret.

Is it being exploited? Cloudflare saw attack traffic hours before the patch. Patchstack's telemetry on October 21 showed probing with no confirmed breaches. CISA had observed no exploitation when it published. On October 22, Sansec judged mass exploitation less likely than first feared. All four can be true at once, and none of them changes what you do.

Does AI make this better or worse? Both, and that is the point. The same capability that found the flaw for the defenders is what we watched turn on bystanders this summer. The window between discovery and attack is now measured in hours, so your patching has to be, too.

For your IT team. Inventory PHP beyond the web servers; CISA notes it ships inside other software. Target the four fixed releases; for 8.1 and older, use a vendor backport from Sansec's table or upgrade. The interim settings in PHP's advisory reduce exposure but do not make an install safe. Keep WAF rules on. Watch for PHP worker processes spawning shells or fetching tools, review logs from October 20 on, and rotate secrets on anything that was exposed. See what we'd check →

---

The PHP version a site announces is the first line of every exposure report we write. If you'd rather have the security team you don't have to hire create and read yours, talk to us.