PHP2Shell and WordPress: what site owners should check and ask now

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of critical flaws in PHP itself, the runtime under every WordPress site, whatever its plugins. WordPress updates cannot fix it. Check your PHP version in Site Health, get whoever runs your server onto PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then verify the site and look for signs of tampering.

Our PHP2Shell explainer covers the two bugs and the disputed exploitation picture. This post is for people who own WordPress sites but may never log into the server under them: shop owners, agencies with dozens of client sites, marketing teams. Who patches, how do you check, what do you ask your host, and what do you check afterwards?

What happened, seen from a WordPress site

The fixes shipped on 21 October 2026, about a day earlier than planned, after details leaked.

Exploitation status is disputed. Cloudflare says it "observed attack traffic targeting our customers." Patchstack relayed partner reports in the morning, then said its telemetry showed "only probing attacks, with no hard evidence of breaches yet." Wordify says no attempt it saw got through. The practical reading: scanning is happening, so treat an unpatched site as at risk today.

Why updating WordPress does not patch PHP

A WordPress site is a stack of layers, and each layer has its own owner and its own update path. PHP2Shell sits in the PHP layer, below WordPress.

WordPress's own Update PHP page says PHP is installed on your server and your hosting company controls which versions you can use. Search Engine Journal puts it plainly for this incident: "Updating WordPress or its plugins will not update PHP."

Plugins also do little for exposure. PHP's advisory says that on Apache with mod_php, a demonstrated attack fires during request startup, before any application code runs. A security plugin is PHP code inside WordPress, so it sits above the bug, not in front of it. An edge firewall can filter known attack shapes, but Cloudflare itself calls its rules defence in depth and says customers should still patch PHP.

Who has to act, by hosting type

If you pay for a server rather than a "plan", you are probably in one of the self-managed rows.

GoDaddy's pre-release post makes the split explicit: if you manage your own server, you restart PHP and the web server yourself.

How to find your PHP version

You need two facts: the PHP version that serves web requests, and whether that build contains the fix.

1. Site Health in the WordPress dashboard

1. Log in to wp-admin as an administrator.
2. Go to Tools > Site Health, then open the Info tab.
3. Expand the Server section.
4. Note the PHP version line, for example 8.3.36. On current WordPress versions the same section also shows the PHP SAPI, which tells you whether you are on FPM, Apache's module or something else.
5. Use Copy site info to clipboard to send the details to your host or developer.

Site Health reads these values from inside a web request, so it reports the PHP that actually serves visitors. Its Status tab flags outdated PHP in general, but that is not a PHP2Shell check.

Read the result like this:

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher on the same branch: an upstream fixed release.
• A lower number on a supported branch: possibly unpatched, or your host uses distribution packages that backport fixes without changing the version, as The Hacker News notes Debian and Ubuntu do. Only your host can confirm.
• 8.1, 8.0, 7.4 or older: PHP published only minimal source backports for 7.4, 8.0 and 8.1. The lasting fix is a supported branch; WordPress recommends "PHP version 8.3 or greater."

2. WP-CLI on the server

If you have SSH access, WP-CLI gives a fast read, but check what it measures.

# WordPress core version
wp core version

# The PHP that WP-CLI itself runs under (this is the CLI, not the web server)
wp cli info

# Same thing in one line, including the SAPI name
wp eval 'echo PHP_VERSION . " " . PHP_SAPI . PHP_EOL;'

The WP-CLI docs note that its php.ini is typically different from the web server's. Command line PHP and PHP-FPM or the Apache module are often separate packages. If wp eval prints cli, you are seeing the command line runtime only. Confirm the web side in Site Health, or check the package:

# Debian / Ubuntu: which PHP packages are installed, and does the FPM changelog name the CVE?
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'
apt changelog php8.3-fpm | grep -m1 CVE-2026-109618

# RHEL family
rpm -q --changelog php-fpm | grep -m1 CVE-2026-109618

If the changelog names the CVE, the backported fix is in, whatever the version number says.

3. Your hosting panel

On cPanel, PHP usually lives in MultiPHP Manager, or Select PHP Version on CloudLinux servers; on Plesk, in each domain's PHP settings. Managed WordPress hosts have their own page; Wordify points customers to Hosting > PHP.

Panels usually show the branch (8.3), not the build (8.3.36). Picking 8.3 in a dropdown does not tell you the host installed the fixed build. Search Engine Journal makes the same point: confirm the version you pick includes the patch.

4. If your WordPress runs in containers

The official WordPress Docker image defaults to an Apache variant, and the official php image docs say that variant runs PHP "as mod_php" with prefork, the setup PHP rates highest risk. Check the PHP inside the image:

docker run --rm --entrypoint php your-registry/wordpress-site:prod -v
docker build --pull -t your-registry/wordpress-site:prod .

A running container does not change because an upstream tag moved. Rebuild with --pull, redeploy, and confirm in Site Health.

What to ask your host

A vague "are we safe?" ticket gets a vague answer. Ask questions that need facts:

1. Which PHP build serves my site now? The full version, or the distribution package plus confirmation its changelog includes both CVEs.
2. When was it deployed, and were workers restarted? A fixed file on disk does not protect a worker that started yesterday.
3. Does the fix cover every PHP version you offer? Some hosts patch only the newest.
4. What did you do before the fix? WAF rules, disabled features, request limits.
5. Any signs of exploitation on my account? Hosts see logs you cannot.
6. What about staging and my other sites? They may sit on different servers.
7. If I am on 8.1 or older, what is your plan?

A message you can paste into a ticket:

Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619) status for my sites

Hello,

Please confirm, for each site on my account (including staging):
1. The exact PHP version and build serving web requests now.
2. Whether that build includes the fixes for CVE-2026-109618 and
   CVE-2026-109619, and when it was deployed.
3. Whether PHP workers and the web server were restarted afterwards.
4. Any interim protections you applied before the fix.
5. Any signs of exploitation you have seen on my account.

If any site is on PHP 8.1 or older, please tell me your plan and timeline.

Thank you.

What managed WordPress hosts have said

We list only statements we read on the provider's own page. Each was written at a point on 20 or 21 October and may have changed since.

Two statements differ from PHP's guidance. GoDaddy lists .user.ini as one place to disable session upload progress; PHP's advisory says not to rely on FPM .user.ini or ini_set(). CloudLinux says not to rely on disabling session upload progress at all; PHP says it blocks the confirmed session paths but not other variants. All agree with PHP's conclusion: "There are no complete mitigations, updating is the only safe choice."

Patchstack also reported emergency maintenance at Sakura Rental Server in Japan and expected Xserver to follow; we could not read their own notices. If your host is not listed, ask it.

Plugin-heavy sites

A WooCommerce store with forty plugins faces the same bug as a five-plugin blog. Plugin count does not change exposure. It changes how hard the fix is.

Same-branch patch releases are low risk. Going from 8.3.35 to 8.3.36 is a security patch, not the kind of jump that breaks plugins. Take it now.

Branch jumps are where plugins break. On 8.1 or older, the fix means moving to 8.2 or newer, where old plugins and abandoned themes fail. WordPress's Update PHP page suggests updating core, plugins and themes first, then running a compatibility checker, which can miss problems or flag false ones. Wordify suggests 8.3 or newer if your plugins support it, since 8.2 support ends on 31 December 2026.

Interim settings can affect plugins:

• Turning off session.upload_progress.enabled can break upload progress bars, as GoDaddy notes. Test forms, media and importers.
• A lower post_max_size (PHP suggests 8M, or 32M with uploads) can block big media, backup restores and product imports.
• PHP says no pool, directory or application setting should re-apply a finite memory_limit. On WordPress, check WP_MEMORY_LIMIT in wp-config.php and plugins that raise memory, and set it with php_admin_value so runtime calls cannot override it. On shared hosting, leave this to the host.

Do not install "fix" plugins. Patchstack warns against unofficial fix plugins and copied snippets. A plugin cannot patch the PHP binary that runs it.

Staging sites

Patchstack's checklist explicitly includes staging in the inventory.

1. List every copy. Staging, development, the old pre-redesign copy, the forgotten "test" subdomain.
2. Check where each runs. Staging on the same managed plan shares the host's builds; staging on a developer's VPS does not.
3. Patch staging or turn it off. It is as exploitable as production and often holds a copy of its database.
4. Use staging for branch jumps, not for delay. Test an 8.1 to 8.3 move there. Do not hold a same-branch security build for a week of tests.
5. Lock it down afterwards with web server passwords, an IP allowlist or a VPN.

If you run the server yourself

On a VPS or dedicated server you manage, update packages, restart PHP-FPM and the web server, then reload Site Health to confirm. Our guide to finding and patching every PHP runtime has the full commands. If you cannot patch, the UK NCSC says to "consider taking the system offline until it can be fully mitigated." A static maintenance page served by the web server, not PHP, is the cleanest way. Our post on governments taking websites offline over PHP2Shell covers how public bodies made that call.

After the patch: checks for WordPress sites

The NCSC advises checking for signs of compromise and backdoors on systems that were not updated at once. These WP-CLI checks cover the usual hiding places.

# 1. Core files match WordPress.org checksums
wp core verify-checksums

# 2. Plugins from WordPress.org match their published checksums
wp plugin verify-checksums --all

# 3. Administrators: look for accounts you do not recognise
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 4. Must-use plugins load on every request and are a common hiding place
wp plugin list --status=must-use

# 5. Scheduled events you did not create
wp cron event list

# 6. PHP files in uploads, where they rarely belong
find wp-content/uploads -type f -name '*.php'

# 7. PHP files changed in the last three days
find . -type f -name '*.php' -mtime -3 -not -path './wp-content/cache/*'

• wp plugin verify-checksums only covers WordPress.org plugins. Compare premium plugins against a fresh vendor copy.
• In web server logs, Patchstack suggests watching for unusual multipart requests followed by memory limit errors or HTTP 500s, oversized PHPSESSID cookies, and unexplained worker restarts. These are hints, not proof.
• If anything looks wrong, treat the server as compromised: restore a pre-20 October backup onto a patched server, then rotate secrets.

# New authentication keys and salts: logs every user out
wp config shuffle-salts

Also rotate the database password in wp-config.php, API keys in plugin settings (payment, mail, CDN), SFTP and SSH credentials, and cloud keys on the box. The Hacker News reports the flaws can also leak worker memory, a reason to consider rotation for sites left unpatched for long even without signs of compromise. Then take a fresh backup and record the date and PHP build.

What would have helped

PHP gave about a day of warning. Owners who already knew their PHP version, who ran the server and how to reach their host had a calm afternoon.

Practices any site owner or agency can use

• A one-page site register. URL, host, plan type, PHP branch, who patches PHP, staging locations, support contact. Agencies need this most.
• Stay on a supported branch. 8.1 and older get no upstream fixes and 8.2 ends on 31 December 2026. Move to 8.3 or newer on a quiet week, with staging.
• Keep plugins current so branch jumps are easy. Abandoned plugins keep sites stuck on old PHP.
• Backups you have restored at least once.
• A maintenance page served without PHP, ready before you need it.
• Secrets you can rotate in an hour, because you know where each one lives.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell, and it does not patch servers or restart PHP. On shared or managed hosting, the PHP fix is your host's job and Safeguard cannot see inside their servers.

It helps teams that build and ship WordPress themselves, such as agencies running WordPress in containers or managing it with Composer:

• Finding PHP in images. safeguard scan --image your-registry/wordpress-site:prod builds an SBOM of the image, including OS packages such as PHP, and matches it against vulnerability databases. safeguard scan --dir . covers a repository and safeguard scan --sbom vendor-sbom.json a vendor's SBOM. Results land as JSON under ./output.
• "Which sites ship this version?" The platform shows which projects contain a given component and version, so "which client images still carry old PHP?" becomes a list. See SBOM incident response.
• Gates. Policies and gates evaluated in the platform can stop a build that still carries a vulnerable PHP package.
• Making the change. The Safeguard CLI's assistant can edit a Dockerfile to a patched base image tag and run your build and tests, asking before each command under its default permission mode. You can send that work from the desktop or phone app and approve each step. For application dependencies, autonomous remediation can open fix PRs; it is off by default.

Where it does not help: PHP on a host you do not control, restarting workers, blocking attacks, detecting a compromised site, or reviewing plugin code for backdoors. Reachability analysis will not lower the priority, because the bug can trigger before WordPress runs. Databases can lag a same-day advisory and backports make version matching noisy, so confirm against your vendor's changelog.

Zero-Day Discovery and Gold

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, across seven package ecosystems. PHP core is a runtime, not a package in those ecosystems, so it is out of scope.
• Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a GitHub Action for CI gates. When we wrote this it did not yet list these two CVEs; php.net is the source of truth.
• Gold Registry (registry.safeguard.sh, paid) offers hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3+, Sigstore-signed, with evidence pages. An artifact loses its badge on regression.

The habit these support is the one that mattered on 21 October: pull patched, signed components from a curated source and rebuild fast.

To try Safeguard, download it at https://safeguard.sh/download and read the CLI docs at https://docs.safeguard.sh/docs/cli .

Common mistakes and troubleshooting

• "Auto-updates are on, so we are fine." They update WordPress, not PHP.
• Checking PHP with WP-CLI only. wp cli info shows the command line PHP, not what serves visitors.
• Reading the panel dropdown as the build. "8.3" is a branch. Ask for the build.
• Panicking over a low version number. A distribution package below 8.2.35 can still carry the fix; the changelog or host will say.
• Setting workarounds in .user.ini. Under PHP-FPM, PHP's advisory says not to rely on it.
• Site Health still shows the old version after an upgrade. Workers were not restarted, or the panel pins the site to another version or handler. Restart PHP-FPM and the web server, or ask the host.
• Uploads fail after a mitigation. post_max_size was lowered or upload progress disabled. Revisit interim settings once you are on a fixed build.
• White screen after a branch jump. A plugin or theme is incompatible. Roll the branch back, then on staging run wp plugin deactivate --all and re-enable plugins one by one.
• Running exploit code to "test". Public proof of concept code is unverified and may contain malware.

FAQ

Do I need to do anything if I am on managed WordPress hosting?

Usually the host installs the fix, but confirm the exact build and deployment time, then check Site Health, including on staging.

My site shows PHP 8.3.6 or 8.2.28. Am I vulnerable?

Possibly. Those numbers are below the upstream fixes, but distributions often backport without changing the version. Ask your host whether the package includes both CVEs, or check its changelog.

Will a WordPress security plugin protect me?

A plugin runs inside WordPress, above the PHP runtime, so it cannot fix PHP2Shell. Edge firewalls can filter known attack shapes, but Cloudflare says to patch PHP even with its rules on. The fix is a patched PHP build.

Is WooCommerce more at risk than a blog?

The bug is the same, but stores hold customer data and payment gateway keys, so a compromise costs more. Patch first, then rotate gateway keys if the site was exposed for long.

I am on PHP 7.4. What now?

PHP itself has no regular release for 7.4. It published minimal source backports for 7.4, 8.0 and 8.1, which only help if your host or vendor builds from them. The real fix is upgrading to 8.2 or newer; WordPress recommends 8.3 or greater. Test on staging, then switch.

Should I take my site offline?

If your host cannot confirm a fixed build and you cannot apply interim measures, the NCSC says to consider it. A static maintenance page from the web server keeps visitors informed without running PHP.

See how Safeguard would have helped

None of these demos shows PHP2Shell. They show the real workflows you would use for it.

The first is a real CLI session that fixes a lodash CVE: the assistant reads the finding, asks before each command, edits package.json, runs install and tests, and pushes nothing. For a containerised WordPress site, you would run the same scan against your WordPress image and ask the assistant to bump the PHP base image tag and rebuild; it asks before each command.

Click through it at your own pace, or open it full screen.

The second is a real desktop app session: the CLI session shows in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit until the upgrade is done and tests pass. An agency could point it at a client site's repo and approve the Dockerfile edit and rebuild step by step.

Click through it at your own pace, or open it full screen.

The third is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. On a day like 21 October, the site owner could approve a rebuild from wherever they are.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• PHP news archive: advance notice and 21 Oct security releases (php.net)
• NCSC: Critical security issue affecting PHP
• Cloudflare: protections against the php2shell vulnerability
• CloudLinux: Imunify360 ruleset 8.83 and PHP CVE-2026-109618 and CVE-2026-109619
• SiteGround: moving early to protect customers ahead of the PHP security release
• Wordify: PHP critical security release, live updates
• GoDaddy: Important PHP security update, what website owners need to do
• Patchstack: PHP vulnerable to critical RCE
• The Hacker News: PHP2Shell, what actually protects you
• Search Engine Journal: critical PHP core flaws affect websites, including WordPress
• TechnologyHQ: critical PHP flaws put WordPress sites on alert
• WordPress.org: server requirements
• WordPress.org: Update PHP
• WordPress.org documentation: Site Health screen
• WP-CLI: wp cli info
• Docker official images docs: php image variants
• Docker official images docs: wordpress image variants

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.