PHP2Shell: Who the Critical PHP Flaw Affects

At about 23:00 Japan time on October 21, 2026, the PHP project released emergency fixes for PHP2Shell, a critical PHP vulnerability that attackers had already started probing. By then a long list of Japanese services had switched themselves off. The security blog piyolog had counted 54 organisations announcing shutdowns or maintenance by 22:00 (211 by the next morning; see the update below), including a Ministry of Health, Labour and Welfare care-services site. Codmon, the childcare app used by more than 25,000 facilities as of March 2026, stopped every service as a precaution. Sakura Internet, Cygames and pixiv announced emergency maintenance, and the shop builders makeshop, Color Me Shop and BASE posted maintenance windows that take admin logins, shop pages and checkout offline. Shopify’s status page, meanwhile, listed no incidents at all.

If your company site runs on WordPress, EC-CUBE or a custom PHP system, the question this week is how exposed you are. Here’s what the flaw is, who it reaches, and how much of the web in Japan and the US runs on PHP.

Update, October 22: how many sites went offline?

By early on October 22, piyolog’s running list had reached 211 organisations in Japan that paused or limited services for the fix, up from 54 the evening before. They include two ministries (Health, Labour and Welfare, and Finance), four city governments including Sapporo, seven financial institutions, 26 ecommerce and ticketing services and 29 hosting and IT companies.

Car marketplaces were hit hard. When I checked around noon Japan time on October 22, Goo-net, Goo-net Exchange and MOTA were all showing notices of precautionary maintenance for the PHP flaw, due to end at 12:00 or 14:00 that day, and each said no unauthorised access had been found. Nextage and Kurumaerabi were also in maintenance without naming a cause. niconico was still partly offline, and Xserver had paused its own website and control panels.

Not every outage is PHP. Carsensor has been offline since October 17, after its operator Recruit detected suspicious access to its systems, and the cause is still under investigation.

On attacks, watchTowr reports exploitation attempts against both flaws, but no successful break-in has been confirmed publicly, and CISA had not added them to its list of known exploited vulnerabilities by the morning of October 22. Most of these shutdowns were precautions taken while servers were patched. I’ll keep adding to this post as things change.

What is PHP2Shell?

PHP is the programming language that runs on the server behind most websites. When someone opens a page on a WordPress site, PHP is the program that builds it. PHP2Shell is a pair of bugs in PHP itself, the layer underneath every plugin and theme. The PHP security team rated both 9.2 on CVSS v4.0 and says they “can allow unauthenticated remote code execution.” Put simply, a stranger can send your site a crafted request and run their own code on your server, no password needed.

With that, they can do anything your site can: read the customer database, change prices, add a fake card form to the checkout. The PHP team rates the risk highest on Apache with mod_php, where a demonstrated exploit fires before any of your site’s own code runs. Your security plugin never gets a say.

The CVE numbers leaked on Hacker News on October 20, two days before the date researchers had been given, and the fixes shipped at around 14:00 UTC on October 21. Hours before that, Cloudflare’s CTO said the company was already seeing early attacks, and Patchstack reported exploitation attempts from several hosting companies. In Japan, IPA issued a warning the same day. No breaches had been confirmed publicly when I wrote this. The PHP team’s advice is blunt: there are no complete mitigations, and updating is the only safe choice.

Who is affected by the PHP vulnerability?

Every PHP installation that serves web pages, according to the PHP team, whether it runs as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. Updating WordPress or your plugins won’t fix it, because the bug sits underneath them. What matters is the PHP version on the server. On a rental server, check which version your site uses in the control panel, and whether your host says it patched that version.

Old versions are the bigger worry. PHP 8.1 and older no longer get releases from the PHP project. The team made an exception this time and published minimal patches for 7.4, 8.0 and 8.1, but those are source code that somebody has to build and install, and most small sites have nobody doing that. It’s a lot of sites. By my arithmetic from W3Techs’ version tables, about 48% of PHP websites that show their version run 8.1 or older.

In practice that covers most of what Japanese company sites and online shops are built on:

• WordPress, including WooCommerce and Welcart shops
• EC-CUBE
• Magento (Adobe Commerce), Drupal and Joomla
• Custom systems built on Laravel, CakePHP or plain PHP
• Hosted carts and business tools that run PHP on the provider’s servers, which only the provider can patch

How many websites in Japan and the US use PHP?

Japan leans on PHP much harder than the US. About five in six .jp domains run on the language this flaw lives in, against roughly one in two .us domains, where W3Techs puts 21% of sites on Ruby, the language Shopify is written in. These are its figures for October 21, 2026, out of the sites whose server-side language it could identify:

• All websites worldwide: 69.3% use PHP
• .jp websites: 83.5%
• Websites hosted on servers in Japan: 92.4%
• .us websites: 51.4%
• Websites hosted on servers in the US: 45.9%

Why Shopify stores didn’t need a patch

Shopify doesn’t run on PHP. Its core is one very large Ruby on Rails application, which Shopify’s engineers have written about for years, and store pages are built and served on Shopify’s own servers. Store owners never install or update a server language. Themes are written in Liquid, a template language built so that theme code can fill a page with your products but can’t run programs on the server. A flaw in PHP has nothing on a Shopify store to hit, and the store owner has nothing to do.

Being hosted isn’t what made the difference. makeshop, Color Me Shop and BASE are hosted services too, and they still needed maintenance windows for the PHP fix. What counts is what the platform runs on, and who patches it when something breaks. On Shopify, that’s Shopify.

One caveat. Shopify apps run on their developers’ own servers, and some are written in PHP. A hacked app server could expose whatever store data you let that app read. Go to Settings, then Apps and sales channels, uninstall what you don’t use and check what the rest can access. I’d do that on any store this week, and it often makes the store faster as well.

What to do now

Update PHP today, to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 depending on your branch, or get written confirmation from your host or developer that they’ve done it. If you’re on 8.1 or older, ask them this week for a backported fix or an upgrade plan. Bear in mind that 8.2 itself stops getting fixes on December 31, 2026.

Then find out who updates your server, and whether you heard from them before the fix came out on October 21. Every PHP site needs that person, and a night like this one is when you find out whether you have one.

Common questions