Updated October 28, 2026: CISA now lists both flaws as exploited in the wild. The October 23 updates added when attacks started, a fixed start date for the file check, and a third PHP flaw that needs a setting change.
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.
Update, October 23: Amazon says its honeypots caught an exploit attempt on October 17, four days before the fixes shipped. It says it’s still unclear whether those early attempts would have worked on real systems. Its advice is to investigate from October 17, not from the announcement, so I changed the file check below to match. Amazon’s post lists IP addresses to search your web server logs for. They belong to shared anonymizing services, so look into any hits rather than blocking them. Separately, VulnCheck says it built an exploit that works on x86-64 servers with ASLR turned on, the memory protection it says had kept most public exploits from working on real servers. It’s sharing the exploit only with paying customers, but it shows that barrier can be overcome. If you haven’t patched, do it today.
Update, October 23, afternoon: PHP disclosed a third flaw, CVE-2026-115560, and this week’s updates don’t fix it. It only affects an unusual setup: PHP is configured with session.serialize_handler set to php_binary or php_serialize, and the application switches it to php with ini_set() before starting a session. PHP considers that unlikely in practice, so the fix will come with the next regular release instead of an emergency one. Until then, PHP’s advisory suggests setting session.upload_progress.enabled = 0, the same setting it listed on October 21. If you already set it, leave it in place. The PHP Foundation told The Register it has no evidence of exploitation on patched versions. Mandiant’s CTO wrote on LinkedIn, also according to The Register, that many public exploits don’t work, but Mandiant confirmed some that run code on default Apache mod_php setups, though not on PHP-FPM.
Update, October 28: CISA, the US government’s cybersecurity agency, added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on October 26. That catalog lists flaws that have been exploited in the wild, so this is no longer only attempts. Federal agencies have until October 29 to patch; the deadline doesn’t apply to anyone else. The Register also reports that a researcher’s three honeypots running PHP under Apache mod_php recorded 35 successful attacks on October 24. The researcher cautions that the honeypots ran a single PHP worker, a setup that favors the attacker, so the results may not reflect real servers. If you still haven’t patched, don’t wait for more proof.
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.” Keep session.upload_progress.enabled = 0 even after you update, until PHP’s next regular release; see the afternoon update above. 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 since October 17. 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 since October 17, the first known attack attempt
# (-newermt needs GNU find, standard on Ubuntu and Debian)
find . -name '*.php' -newermt 2026-10-17If 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.
