PHP php2shell RCE: Patch Your WordPress Site in 15 Minutes

Last checked: 27 October 2026. On 21 October 2026 the PHP project shipped emergency releases for two memory-safety bugs that allow unauthenticated remote code execution in PHP itself — CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell, both rated 9.2 Critical on CVSS v4.0. Amazon’s threat intelligence team traced an exploitation attempt back to 17 October, four days before any patch existed. Cloudflare pushed WAF rules at 03:02 UTC on release day.

If you run WordPress, none of that is fixed by a WordPress update. These are flaws in the PHP runtime underneath WordPress. Your dashboard can say “You are up to date” and your site can still be wide open. The only real fix is a patched PHP build on the server.

What actually broke

Both bugs live in the request lifecycle — the machinery every PHP request passes through before your theme or plugin code even runs.

CVE-2026-109618 (out-of-memory corruption): if PHP hits a memory limit mid-request while internal request data is only partly initialised, the cleanup routine can treat that half-built structure as valid. An attacker who can force the allocation failure — big multipart bodies and absurd POST fields are the usual lever — gets to shape what cleanup does next.

CVE-2026-109619 (stale global state): request-owned state can outlive the memory backing it. A later request handled by the same worker process can then read that stale pointer before normal initialisation overwrites it. On a busy server, “later request by the same worker” is a matter of milliseconds, not luck.

Per the PHP advisory, the affected range is effectively every PHP build serving web requests up to 8.5.11 — Google’s write-up puts it at 5.4 through 8.5.11. The at-risk SAPIs are PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Exposure is not identical across them, and this is where people misread the advisories in both directions:

• mod_php carries a demonstrated, over-HTTP exploit for both bugs, using default PHP input and memory limits. A request can trigger it before any application code runs. This is the worst case.
• PHP-FPM (what most WordPress hosts use) had the session-lifecycle path validated, but PHP states no complete FPM exploit has been demonstrated for the out-of-memory bug. That is a “not yet proven”, not a “safe”.
• FrankenPHP is called likely susceptible on source analysis alone. LiteSpeed and php-cgi are in scope.

The PHP team’s own framing is blunt: “There are no complete mitigations; updating is the only safe choice.” Everything below that isn’t “update” is a tourniquet.

Why your WordPress updates won’t save you

WordPress is a PHP application. The PHP interpreter is installed and maintained by your host, the operating system, or a container image — three layers below the WordPress updater. WordPress.org said so explicitly in its 21 October notice: “These vulnerabilities are not specific to WordPress… No WordPress update is required or planned for these issues.” Wordfence’s PSA repeats it: WordPress automatic updates will not fix these.

There is a second, unrelated thing you should also do while you’re in there: WordPress 7.1.3 (October 2026) shipped 7 security fixes and 4 bug fixes, including a stored XSS on the comments admin screen exploitable through pending comments, a second-order SQL injection in the WXR export, and an unauthenticated disclosure of comments on private posts. That is a dashboard update. Do both:

• Dashboard → Updates → run the WordPress core update (7.1.3 or later).
• Control panel → change the PHP branch/patch. Separate job, separate owner.

Step 0 — find out what you’re actually running

Four reliable ways, fastest first:

1. WordPress: Tools → Site Health → Info tab → expand Server. The PHP version is the first line.
2. Hosting panel: hPanel, cPanel, Plesk, Cloudways and friends all show the selected PHP version for the site or plan.
3. WP-CLI (SSH): wp --info and wp eval 'echo PHP_VERSION;'.
4. Shell: php -v for the CLI binary — remember the web SAPI can differ from CLI, so confirm what FPM/Apache is actually serving.

One trap: if your PHP comes from a Linux distribution or an LTS vendor, the version number may not change after patching. A hardened 8.2.30 with backported fixes still says 8.2.30. On Debian/Ubuntu check the changelog:

apt-get changelog php8.3-fpm | head -40
rpm -q --changelog php-fpm | grep -E "CVE-2026-1096"

If you see the CVE IDs, you’re patched even if the point release looks old. If you manage your own server and can’t confirm it, treat it as unpatched.

Step 1 — pick a branch you can defend

Branch choice matters more than the point release, because it decides how long you keep getting fixes. As of 27 October 2026:

WordPress itself recommends PHP 8.3 or greater. So: 8.4 if you want headroom, 8.3 if you’re cautious, 8.5 if you tested it, 8.1-and-below never. And if you land on 8.2 to get patched today, put “move to 8.4” in the calendar for December — after 31 December 2026 PHP 8.2 stops receiving security fixes entirely.

Step 2 — ten minutes of pre-flight

Switching PHP is a one-click operation and a five-minute outage if you skip this part.

• Back up files and database — a full host backup or a plugin export, downloaded off-server if possible. Verify the archive opens; a backup you can’t restore is a rumour.
• Do it on staging first if your host offers one (Hostinger, Kinsta, WP Engine, SiteGround and Cloudways all do). Switch staging, click around, then switch production.
• Write down the old PHP version so rollback is one click, not an archaeology project.
• Look at your plugin list for the abandoned ones. A plugin with no update in three years is the #1 cause of “PHP upgrade broke my site”.
• Turn on error logging before you switch, not after. In wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

That writes to wp-content/debug.log instead of printing errors to visitors. Remove or set to false once you’re happy — leaving WP_DEBUG on in production is its own problem.

Step 3 — switch the branch

Hostinger (hPanel): Websites → Dashboard for the site → PHP Configuration → pick the PHP version → Update. It applies within a couple of minutes and to every site on the plan, except AI Builder sites. Hostinger applies patch releases inside a branch automatically, so you choose 8.4 or 8.5, not 8.4.27. Versions below 8.2 are already removed from the selector for security reasons — which is a useful signal in itself.

cPanel: MultiPHP Manager → tick the domain → select PHP version → Apply. If the version you want isn’t listed, ask the host to build it (EasyApache 4 usually has it).

Managed WordPress hosts (Kinsta, WP Engine, Pressable, WordPress.com Business): you often can’t pick the patch yourself — the host rolls it out, or it’s on a support ticket. Check the status page and open a ticket asking, literally, “are we on 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or a patched equivalent?”

Self-managed servers — the part people get wrong: installing the new package does not change what’s running. The vulnerable libphp.so or php-fpm binary stays resident in the worker processes already serving traffic until you restart the SAPI:

sudo apt-get update && sudo apt-get install --only-upgrade php8.4-fpm php8.4-cli
sudo systemctl restart php8.4-fpm && sudo systemctl restart apache2
# or, on LiteSpeed / FrankenPHP
sudo systemctl restart lsws
sudo systemctl restart frankenphp

Then confirm the running binary, not the package: php-fpm8.4 -v, or a phpinfo() page you delete immediately after. Google’s guidance adds one more thing worth stealing: if a host shows signs of active probing, capture worker memory before you restart — a restart destroys the volatile evidence you’d need for forensics.

Step 4 — verify, don’t assume

1. Tools → Site Health → Info → Server shows the new version.
2. wp-content/debug.log has no new fatals in the last ten minutes.
3. Log in, log out, open the customizer, save a post.
4. Submit every form on the site (contact, newsletter, checkout if you sell).
5. Trigger a cron run (wp cron event run --due-now) and check scheduled posts still publish.
6. Run a page-speed or uptime check — a broken opcode cache usually shows up as a slow first byte, not an error.

Step 5 — when the switch breaks something

Ninety percent of post-upgrade breakage is one of these:

• White screen or “There has been a critical error” — PHP now fatals where it used to warn. WordPress emails you a recovery-mode link; use it, then read debug.log for the file and line.
• Deprecation notices flooding the page — a plugin using dynamic properties or ${var} string interpolation. Turn off display, log it, and update or replace the plugin.
• Fatal on activation of one specific plugin — rename its folder over SFTP (wp-content/plugins/plugin-name → plugin-name-off) and the site comes back instantly. That’s your culprit.
• Broken images, uploads or PDFs — usually a missing extension (gd, imagick, intl) in the new PHP build. Ask the host to enable it; this is a build problem, not your code.

If you can’t identify it in ten minutes, switch the PHP branch back, restore the backup if needed, and debug on staging. A patched site that’s down helps nobody, but a vulnerable site that’s up is worse — so treat “rolled back” as a same-day problem, not a next-week one.

If you’re stuck on PHP 8.1 or older

You are not getting a fix. PHP 8.1 and older are end-of-life; the project shipped only minimal source backports for 7.4/8.0/8.1 to help people who build PHP themselves or have an LTS vendor. Some distributions and commercial LTS vendors (SUSE, Ubuntu Pro, CloudLinux) backport the patches, so ask your host whether they have before you assume.

WordPress will still run on PHP 7.4+ — and that’s precisely the trap, because “it works” is not “it’s supported”. Meanwhile a third of the web is in the same position: W3Techs’ 27 October 2026 survey still shows ~26.6% of PHP sites on version 7 and ~7.7% on version 5.

If you genuinely cannot move the PHP version this week, these are the mitigations from the PHP advisory. Read the caveat first: they reduce specific attack paths and do not make you safe.

• For CVE-2026-109618: set memory_limit=-1 at the FPM pool or Apache level (php_admin_value) so applications can’t override it back to a finite value; keep post_max_size at 8M for sites without uploads (32M with), and upload_max_filesize below it. Cap request size, field count, multipart parts and header count at the proxy or WAF too.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, an FPM pool or server config — not via ini_set() or .user.ini — then restart every worker. On PHP 8.5 also set fatal_error_backtraces=0.
• Put a WAF in front. Cloudflare shipped managed rules for these on 21 October; hosts and CDNs followed. A WAF is a speed bump, not a patch.

The PHP team added a follow-up on 23 October for an unlikely vector (CVE-2026-115560, session upload progress): leave session.upload_progress.enabled=0 until the next regular release. If you applied it, keep it.

Were you already hit? (17 October onward)

Amazon’s MadPot telemetry caught an exploitation attempt on 17 October from an IP tied to a commercial anonymisation network, and told customers to investigate activity “from at least starting on 17th”. So the question isn’t only “can I be attacked” — it’s “was I”.

Signals worth a look, cheapest first:

• PHP error log: out-of-memory fatals, or requests that die inside request parsing, especially with huge multipart bodies.
• Access log: bursts of very large POSTs to endpoints that shouldn’t accept uploads; odd PHPSESSID cookies in traffic you don’t recognise.
• WordPress users: any admin account you didn’t create. Check wp_users and wp_usermeta for wp_capabilities edits.
• Files: anything new in wp-content/uploads that ends in .php, new files in mu-plugins, modified timestamps in core.
• Cron: unknown events in wp_cron or wp_options → cron.
• Outbound: connections from the web user to hosts you don’t use.

If something matches, assume the worst and work in this order: preserve logs and disk image → take the site offline → restore core, plugins and themes from clean sources → rotate the database password, WordPress salts (api.wordpress.org/secret-key/1.1/salt/), and every API key the site holds → audit users and scheduled tasks → only then put it back.

Make this the last time you do it manually

Three habits turn this from a fire drill into a checkbox:

1. Know your PHP version without logging in. Add it to your uptime or monitoring check, and put “PHP version” on the monthly maintenance list next to “backup restore test”.
2. Choose your branch deliberately. 8.4 or 8.5 today, and diarise the security-support end date — not the release date. Branches die quietly, and 8.2 dies on 31 December 2026.
3. Keep staging switchable. If trying a new PHP branch is a five-minute job on staging, you’ll do it on time. If it’s a weekend project, you’ll do it after the next CVE.

FAQ

Does updating WordPress to 7.1.3 fix this? No. It fixes seven WordPress vulnerabilities. PHP is patched at the server level.

My host says PHP is up to date — do I need to do anything? Check the number: 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a distro build with the CVE in its changelog. If the number is lower and the host claims a backport, ask for the advisory reference.

Is WordPress itself supported on 8.5? WordPress recommends 8.3+ and works on 8.5, but plugin-level support is the real constraint. Test before switching a revenue site.

Do I need to change my code? Only if it was already broken: this release doesn’t remove functions, but 8.4/8.5 deprecations that used to be warnings can become noise in logs.

I’m on mod_php. How urgent? Most urgent. The demonstrated, over-HTTP exploit targets mod_php specifically, before application code runs. Move today, and consider FPM while you’re at it.

Sources

• PHP.net news archive, Security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026, updated 23 and 26 Oct 2026) — php.net/archive/2026.php
• PHP supported versions and end-of-life dates — php.net/supported-versions.php
• WordPress.org, Critical PHP Security Release (21 Oct 2026) — wordpress.org/news
• WordPress.org, WordPress 7.1.3 Maintenance and Security Release (Oct 2026) — wordpress.org/news
• Wordfence, PSA: PHP Security Updates Available for Two Critical Vulnerabilities (21 Oct 2026) — wordfence.com
• Google Cloud, Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (22 Oct 2026) — cloud.google.com
• InfoQ, PHP Patches Two Critical RCE Flaws That Were Already Under Attack (25 Oct 2026) — infoq.com
• Hostinger Help Center, How to change the PHP version of your Hostinger hosting plan (updated Oct 2026) — hostinger.com
• W3Techs, Usage statistics of PHP for websites (27 Oct 2026) — w3techs.com

Written and fact-checked on 27 October 2026 against the PHP advisory text, the WordPress.org security notice, and vendor PSA published the same week. If a newer PHP security release is out — check php.net/supported-versions.php before acting on the numbers above.