On October 21, the PHP project shipped emergency updates for two critical flaws that researchers are calling PHP2Shell. An attacker who exploits them can run code on your web server without logging in. According to W3Techs, PHP runs 69.3% of the websites whose server-side language it can identify, including every WordPress-based site.
My own site was exposed. It runs WordPress in a Docker container. WordPress had kept itself current the whole time, but PHP was still 8.3.31 from an image I had pulled in June, running under mod_php, the setup the advisory rates highest risk. I found no sign of an attack in my logs. I applied the temporary settings and moved to the patched image within minutes of it appearing on Docker Hub.
If your business website runs WordPress, you may assume it keeps itself up to date. WordPress does update itself, and plugins and themes can too. PHP is the layer underneath them, and none of those updates touch it. Somebody has to update PHP on purpose.
What happened
- The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws are CVE-2026-109618 and CVE-2026-109619. The PHP project’s advisory says every PHP installation that serves web requests is potentially at risk.
- The risk is highest for Apache with mod_php, the setup the official WordPress Docker image uses. The advisory says a single request from someone who isn’t logged in can trigger the attack there before any of your site’s code runs.
- PHP-FPM isn’t off the hook. The PHP Foundation says code execution was also confirmed on PHP-FPM through application code.
- Wiz, one of the research teams credited with the find, says every PHP version from the last decade is affected, back to 5.4. It says the flaws can also expose server memory that may hold passwords, tokens and API keys.
- Attacks have started. Cloudflare says it saw attack traffic aimed at its customers before the fixes were public. watchTowr told The Register it is seeing exploit attempts, none successful at the time it spoke.
Who updates your PHP?
It depends on where your site lives.
- Managed WordPress or shared hosting: your host. You may be able to pick a PHP version in a control panel, but the host installs the updates.
- An agency or developer runs it for you: them, or the company they host it with.
- Your own server or cloud VM: you or your IT staff.
- A Docker container: PHP is baked into the image. It changes only when someone pulls a new image and recreates the container.
If you don’t know which one applies to you, that’s the first thing to find out.
Check your version
In WordPress, go to Tools > Site Health > Info and open the Server section. It lists the PHP version. The WordPress documentation covers the rest of that screen.
- 8.2, 8.3, 8.4 or 8.5: you need at least the fixed release for your branch, listed above.
- 8.1 or older: the PHP project no longer ships updates for these. It published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux vendors backport fixes. Otherwise the fix is a PHP upgrade, which can break old themes and plugins. W3Techs says 27% of sites that use PHP are on version 7 and 7.7% are on version 5. If that’s you, start the upgrade this week.
One trap. Linux distributions often patch PHP without changing the main version number. On Ubuntu 24.04, the fixed package is 8.3.6-0ubuntu0.24.04.13, and it still calls itself PHP 8.3.6. On a distribution build, check the vendor’s security notice, not the number alone.
Ask your host
If someone else runs your server, send them something like this today:
Our website, [your domain], is hosted with you. Have you applied the October 21 PHP security releases for CVE-2026-109618 and CVE-2026-109619 to the server it runs on? Which PHP version and build is it running now? If it’s on PHP 8.1 or older, what is the plan to upgrade it?
Get the answer in writing. “We’re on it” isn’t an answer. A version number is.
If you run the server yourself
Install your distribution’s PHP updates, then restart PHP-FPM or Apache so every PHP worker loads the fix. On Ubuntu, for example:
# Install the patched packages
sudo apt update
sudo apt upgrade
# Show the installed PHP package versions and compare them to the security notice
dpkg -l 'php*' | grep '^ii'
# Restart whichever one serves your site
sudo systemctl restart php8.3-fpm # PHP-FPM
sudo systemctl restart apache2 # Apache with mod_phpIf your site runs on the official WordPress Docker image, pull the new image and recreate the container. The image was rebuilt with PHP 8.3.36 on October 21.
# Run these in the folder that holds your docker-compose.yaml
docker compose pull wordpress
docker compose up -d wordpress
# Confirm the new version: 8.3.36 or later for the current image
docker compose exec wordpress php -vAnything you installed inside the container by hand, such as WP-CLI, goes away with the old container. Mount it from the host instead so it survives the next update.
If you can’t update today, the advisory lists temporary settings that block the confirmed attack paths, such as session.upload_progress.enabled = 0 in php.ini. It also says plainly that they “do not make an installation safe.” CERT-EU went further, according to The Register, and told organizations that can’t patch to consider taking internet-facing applications offline.
If your site sits behind Cloudflare, its PHP2Shell rules are on by default on every plan with the WAF, including Free. Cloudflare still says to patch.
Look for signs of trouble
Wiz researchers told Krebs on Security they expect attackers to use these flaws to plant web shells, files that give an attacker a control panel on your server. After you patch, take ten minutes:
- Look for PHP files in
wp-content/uploads. That folder holds your images and documents, so a .php file there needs an explanation. - Look for PHP files that changed in the last week. Updates you installed will show up too. You’re looking for the ones you can’t explain.
- Open Users in WordPress and look for administrators you don’t recognize.
# Run from your WordPress folder (the one with wp-config.php)
# PHP files in uploads deserve a look
find wp-content/uploads -name '*.php'
# PHP files changed in the last 7 days
find . -name '*.php' -mtime -7If you find something, treat it as a breach, not a cleanup. Get help, and change the passwords and keys your site uses, because these flaws can expose memory.
Know who owns each layer
The fix this week is an update. The lesson is ownership. A website has layers: WordPress and its plugins, the PHP under them, and the server under that. Write down who updates each one. If the answer for any layer is “nobody” or “I assumed the host did,” that’s the one to fix first.
