On October 21, 2026, around 22:40 Japan time, fixes for two critical PHP vulnerabilities shipped, nicknamed "php2shell." Most of the writeups that followed assume you administer your own server: set this directive, restart these workers, update this proxy config. If you run WordPress on shared hosting, the kind where you don't get to edit php.ini and can't update the PHP binary yourself, none of that is actually available to you.
I run seven sites on shared hosting for a small company. This post sorts out, based on the official advisories and the hosting providers' own incident reports, what shared hosting users can do themselves, what they cannot do no matter what, and what just has to be waited out.
What happened
- PHP's official announcement: https://www.php.net/ (security advisory for 2026-10-21)
- Advisories: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
- An alert from Japan's IPA (in Japanese): https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
- A writeup from GMO Flatt Security (in Japanese): https://blog.flatt.tech/entry/php2shell
Two unauthenticated remote code execution vulnerabilities, CVSS v4.0 score 9.2. The flaw is in PHP itself, not in WordPress or Laravel code, so a well written application is not protected just because it's well written. The official advisory names mod_php as the highest risk, with PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed also affected. Fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and earlier are outside the official support window, so only a minimal fix is available for people who build PHP from source. Attacks were observed before the public disclosure: Cloudflare says it saw attack traffic on the morning of October 21.
Checking the claims that were circulating
| Claim | Verdict | Evidence |
|---|---|---|
| PHP powers 80% of the web | Overstated | W3Techs puts server-side language share at 69.3% among sites where it's known. Wiz, who discovered the bug, says "70%" |
| The real danger starts right after the patch ships (a 1-day attack) | Correct | True in general, and in this case attacks started even before disclosure |
| AI can reverse engineer an exploit in minutes | Overstated | Wiz wrote that "a frontier AI model" built exploit code for multiple applications "in a few hours," not minutes |
| CVSS 10.0 | Wrong | The official score is 9.2. A member of the PHP security team corrected an earlier 10.0 figure that had leaked out |
Setting session.upload_progress.enabled=0 fixes it |
Only partly | That mitigates one path in CVE-2026-109619. It does nothing for the other vulnerability, CVE-2026-109618 |
The last row matters most. The single mitigation that spread the widest before disclosure, the one-line fix, only covers part of one of the two CVEs. Alexandre Daubois, a member of the PHP security team, wrote a correction from the inside: https://daubois.dev/blog/cve-2026-109618-php2shell-rumors/
What shared hosting users cannot do
The official mitigations are mostly out of reach if you're on shared hosting. Setting memory_limit=-1 in a way the application can't override, the first mitigation the advisory lists, assumes you control the FPM pool configuration or can set php_admin_value in Apache, neither of which a shared hosting account gives you. Making session.upload_progress.enabled=0 actually take effect requires restarting every worker process, and the advisory explicitly says not to rely on ini_set() or .user.ini instead, both of which are the only levers a shared hosting user actually has. Limiting request size or multipart bodies at the web server or proxy level is also the hosting company's job, not something you can configure from a control panel. In practice, the only real fix for a shared hosting site is the hosting company updating PHP itself. There is no patch a user can apply.
At major Japanese shared hosting providers, the response to that constraint played out two different ways. One provider announced by 6:45 on October 22 that it had already applied the official patch to every server running PHP 8.2 through 8.5, was rolling out its own patches for older versions as they became ready, and had temporarily disabled its control panel and server panel as a precaution. Another provider went further: starting on October 21 it began emergency maintenance, and from around 3:09 on October 22 it took down public access to sites on some of its servers entirely, including sites that weren't even running a vulnerable PHP version, choosing to protect everyone quickly over patching server by server. According to its report (in Japanese, https://lolipop.jp/info/news/8239/), it restored access around 13:00 on October 22 after applying the official patches for 8.2 through 8.5, equivalent fixes for the already end-of-life 7.4 through 8.1, and its own custom patch for 5.3 through 7.3, and it disabled session.upload_progress across every version as a blanket measure. It said it had seen access attempts that looked like they were targeting the vulnerability, but had not confirmed any unauthorized access or data leak. WordPress core doesn't use PHP sessions, so that last change doesn't affect a stock WordPress install, but a custom upload form or a plugin that relies on sessions is worth checking.
What you can do
1. Move PHP to 8.2 or newer
This is the single most effective step. As providers' own announcements show, patches land for 8.2 through 8.5 first. A site still sitting on 7.4 or 8.0 is both last in line for a fix and on a version with no official patch at all. Check your PHP version setting in your hosting control panel; some providers let you set it per domain. If an older plugin assumes an old PHP version, as happened on one of my own sites with a plugin built for PHP 7.4, update the plugin before you switch.
2. Check for signs of compromise
A patch doesn't undo damage done before it was applied, and attacks were already happening before disclosure. For WordPress, check the following.
# After SSHing in and moving to the WordPress root
wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name '*.php'
find . -name '*.php' -mtime -3 -not -path './wp-content/cache/*'
Look for new administrator accounts (filter the users list by the administrator role), for .php files inside wp-content/uploads/ (a PHP file in an image directory is almost always a sign of compromise), for core or plugin files that don't match the official checksums, and for PHP files modified in the last few days. If you don't have SSH access, sorting the uploads directory by date in an FTP client already tells you a lot.
3. If you find anything, rotate every credential
Wiz's writeup notes that this vulnerability can, in some cases, expose other requests or the server's own memory, which can include passwords, auth tokens, and API keys. If you find any sign of compromise, rotate all of the following: your WordPress admin password, the database password and the authentication keys in wp-config.php (AUTH_KEY and the others; WordPress's generator is at https://api.wordpress.org/secret-key/1.1/salt/), your server's FTP and SSH passwords, and any API keys for external services your site uses, such as payment processors, email delivery, or Google. Even without a confirmed compromise, if you're storing API keys in wp-config.php or in plugin settings, rotating them is worth considering.
4. If you're already behind Cloudflare, you're covered
Cloudflare says WAF customers, including on the free plan, have been protected by default since 3:02 UTC on October 21 (https://blog.cloudflare.com/php-vulnerabilities-waf-protection/), as long as your DNS is proxied through Cloudflare. That doesn't replace updating PHP.
What you don't need to do
- Update WordPress core or plugins expecting that to fix this. The flaw is in PHP itself, so a fully updated WordPress install is still vulnerable. Keeping WordPress updated is good practice regardless, just not a fix for this issue.
- Add
session.upload_progress.enabled = 0to.htaccessor.user.ini. The official advisory explicitly says not to rely on.user.inifor this, and believing it worked when it didn't is worse than not trying at all. - Panic and delete the site. Checking for compromise and rotating credentials comes first. Deleting the site destroys the evidence you'd need to investigate.
Takeaways
php2shell is a flaw in PHP itself, so on shared hosting the only real fix is the hosting company updating PHP, something users cannot do on their own. What a user can do comes down to three things: move to PHP 8.2 or newer, check for signs of compromise, and rotate every credential if any sign turns up. The widely shared one-line fix only covers part of one of the two CVEs, and writing it into .user.ini doesn't even apply it. Hosting providers were updating their advisories every few hours, so check your own provider's announcement rather than anyone else's.
This post was drafted on the morning of October 22 and updated on October 23 after one provider's incident report. Response details from hosting companies keep changing, so treat official advisories as the current source, not this post.
I wrote this with help from Claude, Anthropic's AI model. It drafted the post from PHP's own security advisories, the GHSA entries for CVE-2026-109618 and CVE-2026-109619, and the hosting providers' incident reports, and I reviewed it before publishing.
Top comments (0)