Updating WordPress doesn't fix this PHP flaw, and the version number may not tell you if it's patched

Two critical flaws under attack are in PHP itself, the software on your web server that runs WordPress, Magento and many other sites. They aren't in WordPress or your plugins. I updated WordPress, a plugin and the themes on a test site running an unpatched PHP. PHP didn't change, and WordPress's Site Health screen passed it as "a recommended version". The number can mislead you the other way too: Ubuntu's fixed PHP still says 8.3.6, the same as before the fix. If your business runs on a PHP site, the fix belongs to your host or whoever runs your server, so your job today is getting a specific answer from them in writing.

Published November 2, 2026. Facts checked that day.

1 What happened

On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619 (a CVE number is a flaw's public ID). Both can let someone with no login run code on the server. PHP's advisory puts every PHP installation serving web requests at risk, and rates the risk highest for Apache with mod_php, one common way of connecting PHP to a web server measured (php.net). Wiz named its exploit php2shell, and hosts now use PHP2Shell for the pair.

Wiz, a security firm that published research on these flaws, says the attack doesn't depend on a flaw in the site's own code, and that it showed attacks on the latest WordPress, Drupal and Joomla container images (ready-made server packages). It also says the flaw can reveal passwords, tokens and API keys from the server's memory without running any code reported (Wiz). That's why a WordPress or plugin update can't fix it. Those updates change your site's code, and the flaw sits underneath it derived.

How hard the attack is depends on the setup. PHP's technical advisories rate attack complexity as high and say reliability varies by build. Full code execution was shown on Apache with mod_php. On PHP-FPM, another common way of connecting PHP, one attack path was shown to work and the other was judged susceptible from reading the code, with no complete exploit shown measured (PHP's advisories). Red Hat rates CVE-2026-109618 lower than PHP does, says its standard setup uses PHP-FPM, and calls code execution on that setup "difficult in practice", while saying it's possible against mod_php's default configuration reported (Red Hat). That isn't a reason to wait. PHP's advisory says "only an update is a complete solution" measured (php.net).

On October 26, CISA, the US government's cyber defense agency, added both flaws to its list of flaws with evidence of real attacks measured. On October 28 it added a Linux flaw that it says can be chained with these two to plant web shells (hidden back doors) and run commands as root, the server's all-powerful account reported (CISA's catalog). Amazon says its decoy servers saw an attempt dated October 17, four days before the fixes, and that it's unclear whether any attempt it saw would have worked on real systems reported (Amazon). I didn't find a confirmed public count of hacked WordPress or Magento sites. That doesn't show there are few.

2 What I tested, and what happened

On November 2, 2026, I ran these on my own computer, in throwaway containers (small disposable servers) nobody else could reach. I checked what each check reports. I didn't attempt the attack on anything.

The "What happened" column is measured. I didn't test a real host's servers, other ways of connecting PHP to a web server (PHP-FPM, LiteSpeed), or Magento.

3 How to see your PHP version

Use one of these. Each shows what your site is running, which is step one, and not yet an answer.

1. WordPress: go to Tools, then Site Health, then the Info tab, then Server, and read "PHP version" measured, tested on 7.1.4. Don't use the pass mark on the Status tab as your answer.
2. cPanel, a common hosting control panel: MultiPHP Manager lists the PHP version for each domain, though your host can hide it reported (cPanel's documentation). I didn't test this one.
3. Any PHP site: make a plain text file called v.php containing only <?php echo PHP_VERSION;, put it in your site's main folder, open it in a browser, note the number, then delete the file and check it's gone, because it shows your version to anyone who finds it. I tested this on plain PHP and WordPress, and it reported the web PHP correctly each time measured. Magento's sample server setup blocks PHP files it doesn't recognize measured (Magento), and some hosts don't allow uploads. If you get an error, or you've never uploaded a file to your server, ask your developer or host to do this.

4 What the number can and can't tell you

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 or higher on the same branch: by PHP's own numbering, the two fixes are in measured (php.net). A branch is the first two numbers, such as 8.3.
• The same branch but a lower number: it could be unfixed, or it could carry the fix under the old number. Ubuntu's does, and several hosts say theirs did too: InMotion, GoDaddy and WordPress.com each say a patched site can show the older number reported (their pages are linked in section 6). Only whoever built your PHP can tell you which it is.
• 8.1 or older: PHP has no release for you. Your host or server vendor may have added the fix themselves, or nobody has. Ask, and read section 7.

5 The email to send your host

Send it to your host, or to the person who runs your server if that's your developer. Copy it, fill in the brackets, and cut any question that doesn't apply.

Subject: PHP security fixes on my site (CVE-2026-109618, CVE-2026-109619)

Hi,

My site is [address], on [account or plan name]. Please answer for the PHP that actually serves my site, not the command-line version.

1. Does it include the fixes for CVE-2026-109618 and CVE-2026-109619? What's the exact PHP version and package or build, and what date did the fix go in?
2. Was PHP fully restarted after that, so the running site uses it?
3. If my PHP is 8.1 or older, or 8.2, who supplies its security fixes, and until what date?
4. Is the server's Linux kernel patched for CVE-2026-46300, which CISA says can be chained with these two?
5. Is session.upload_progress turned off? php.net suggests that until its next release, because of CVE-2026-115560.
6. Do you have the server's logs from October 17, 2026 onward? Did you see anything suspicious on my site or server, and how long will those logs be kept?

Thanks,
[your name]

A good answer names a version or package and a date. "We take security seriously" or "your site is protected" alone doesn't answer question 1, so ask once more for the version and date, and keep the reply. Questions 1 and 2 matter most, and a shared host declining 4 or 6 isn't a red flag by itself. Include any staging or old sites on the same account, because they run PHP too. If you get no specific answer in two days (my judgment, not a rule), ask for a supervisor, and read CISA's offline advice in section 7. On a server you or your developer manage, such as a VPS (a rented server of your own), the answer may be that this is your job. Hostinger, GoDaddy, IONOS and Namecheap all say so for those plans reported (section 6). There, the fix is your vendor's updated package followed by a full stop and start of whatever runs PHP (Apache with mod_php, otherwise PHP-FPM or LiteSpeed), then check the version from the website again. On a vendor's build the number may not change, so check the package version too. The kernel flaw in question 4 is a separate update, and it usually needs a reboot, so plan a quiet time and take a backup first derived.

Question 5 is the smallest of these. PHP says that third flaw needs an unusual setup, and that a full advisory comes with its next release measured (php.net). As of November 2, php.net listed no newer release than the ones above measured.

6 What hosts say on their own sites

My AI tools read each company's own page on November 2, 2026. This is what they say, not something I tested, and it changes, so follow the link. A host-wide statement also isn't proof about your account, especially on a plan where you run the server yourself. "Older branches" means PHP 8.1 and below. Some of these brands share an owner: WP Engine runs Flywheel's patching, for one.

If your server runs a control panel or an operating system's own PHP, the fixed packages exist from cPanel, CloudLinux, Ubuntu and Debian reported. Red Hat's bulletin said some updates were available and more were in progress, as of its Oct 23 update reported. A package existing doesn't mean someone has installed it on your server.

7 What an unsupported version means

PHP now supports each branch for four years, then stops measured (php.net). After that date the PHP project publishes no new releases for it, so a flaw found later stays in that branch unless someone else fixes it.

This one was serious enough that PHP's security team published source-code fixes for 7.4, 8.0 and 8.1. These aren't releases: they're for people who build PHP themselves or can't get it from a vendor. Otherwise PHP tells you to ask your vendor or upgrade measured (php.net). Many hosts stepped in, as section 6 shows. So an old branch isn't automatically unfixed today, but your safety now rests on that one vendor continuing to do this for each new flaw. AlmaLinux, for one, says future fixes for its retired versions aren't guaranteed reported (AlmaLinux).

You may be in a lot of company. Modat, a firm that scans the internet, counted 4.38 million PHP services the day before the fix, and 79% of those showing a version were on a branch PHP no longer supports reported (Modat). As my Ubuntu test shows, a number alone can't say how many of those were unfixed derived.

CISA says organizations that can't patch right away, or that run 8.1 or an older unsupported version, "should take PHP-based systems offline until they can be patched or updated" measured (CISA's alert). If your vendor has confirmed a fix for your old branch in writing, I read that as patched for this flaw. That's my reading, not CISA's.

Moving to a newer branch is the lasting fix, and it can break old plugins, themes or custom code, so try it on a copy of the site first derived. WordPress recommends PHP 8.3 or greater measured (WordPress).

8 If you run Magento or Adobe Commerce

You have two separate jobs. The PHP fix above is one. The other is a flaw in Magento itself, a file upload problem (CVE-2026-48356) that CISA added to its list of exploited flaws on October 27 measured (CISA's catalog). CISA's entry points to Adobe's July bulletin, which lists fixed versions ending 2026-jul measured (Adobe). A Magento update fixes that one, and it doesn't touch PHP. Your store's version also limits your PHP choices: Adobe lists only PHP 8.1 for 2.4.4 and 2.4.5, and 8.2 or 8.1 for 2.4.6 measured (Adobe's requirements). So an older store may need its fix from a vendor, or a Magento upgrade first derived. Adobe's list for Magento Open Source stops at 2.4.6, so an older Open Source store has no listed fix measured. I didn't test Magento myself.

9 If your site may already have been exposed

Amazon advises starting any investigation from October 17, not from the date of the fix measured (Amazon). So if your PHP ran unfixed on any day from then until it was patched, treat it as possibly exposed. That doesn't mean you were hacked. PHP's technical advisory for CVE-2026-109619 says "absence of an error in logs is not proof of safety" measured (PHP on GitHub), and the memory leak Wiz describes wouldn't need to leave a changed file behind derived. This is the order I'd follow:

1. Get the fix in first, or have your host take the site offline until it's in. A WordPress maintenance-mode plugin doesn't count: PHP still answers every request, and PHP's advisory describes an attack that fires "before any application code runs" measured. Ask your host to block the site at the server, or to show a plain page that doesn't use PHP derived. Anything you change before the fix could be read again. CISA says a web application firewall (a filter in front of your site) "may provide some protection" until then measured (CISA's alert).
2. Take a copy before you clean anything, even if it may be infected. WordPress's guide says the same measured (WordPress). Keep it off the server and never restore from it, because it holds your secrets and maybe the infection derived.
3. Ask your host to check. CISA suggests looking for PHP processes launching shells or downloading tools measured (CISA's alert). Wiz adds unusual multipart requests (the kind used for file uploads) followed by memory errors or repeated 500 errors (the server's generic failure page), and oddly large or malformed PHPSESSID cookies reported (Wiz). These logs are usually out of your reach, which is why question 6 is in the email.
4. Look at what you can see yourself: admin users you don't recognize, your host disabling the site, or search and antivirus warnings about it. WordPress's guide also singles out .htaccess as often changed, and says to watch index.php, header.php, footer.php and functions.php (it spells that one function.php) measured (WordPress).
5. Replace the secrets PHP could see, once the fix is in, without waiting for your host's answer to step 3. If steps 3 or 4 already found real signs, read step 6 first. If a leak of one would be expensive, I'd replace it even if your logs look clean derived. The list: the database password, WordPress's secret keys, admin passwords, and any API or payment keys in your site's settings, because of the memory leak Wiz describes. WordPress's guide adds hosting and FTP (file upload) passwords measured (WordPress). Wiz says that memory can also hold certificates and data from other visitors' requests reported, so ask your developer whether a store should reset customer passwords and whether your host should reissue your certificate (what gives your site its HTTPS padlock) derived. If steps 3 or 4 turned up real signs, change everything again after the cleanup, because a back door can read new passwords too. WordPress's guide says to change them after the site is clean measured. These changes can break a live site. A new database password has to go into the site's settings file (wp-config.php, or env.php on Magento) at the same moment or the site goes down, new WordPress secret keys log everyone out, and a payment key changed in one place and not the other can stop checkout. Do them one at a time, at a quiet hour, with your developer or host if you're not sure.
6. If you find real signs, stop treating it as a checklist. On a server you run yourself, I'd build a new server rather than clean the old one, because CISA says these flaws can be chained with a Linux flaw to reach root derived. If customer or card data may have been reached, talk to your payment provider and a lawyer about what you owe people.

Skip any "fix" plugin or pasted code. A plugin runs on top of PHP, and Patchstack, a WordPress security firm, warns against unverified ones too reported (Patchstack).

How I got this

I ran the tests on November 2, 2026, on my own computer, working with Claude Code, an AI coding tool. They used the official PHP container images (php:8.3.35-apache, 8.3.36-apache, 8.1-apache, 7.4-apache), Ubuntu 22.04 and 24.04, Debian 12 and WordPress 6.8 and 7.1.4. Nothing was reachable from outside my computer, and I sent no attack traffic to anything. So this shows what the checks report. It doesn't show whether any server can be attacked. One WordPress update crashed on its first try and worked on the second, and I didn't look into why. Site Health flagged other things about my bare test server, none of them about the PHP version. The two setups marked "on purpose" in section 2 are ones I built to test a check, so they show what can happen, not how often it does.

My AI tools read the advisories, CISA's entries and each host's page on November 2, 2026. One AI agent gathered the host pages first, and fresh AI reviewers checked the wording against them. Two pages refused my tools (Plesk's support article and InMotion's news article), so I've left them out. You should also know that I sell security reviews, so I have an interest in you taking this seriously. The labels say how far each claim goes:

Measured

I counted it myself, or read it on the source that owns the fact (PHP's own advisory, say).

Reported

A named source, a host's own page included, says it, and I can't check it myself.

Derived

My own reasoning from the two above.

Sources

Host pages are linked in the table in section 6.

1. PHP project, "Security advisory: Critical remote code execution vulnerabilities, update now", October 21, 2026. php.net. Technical advisories: CVE-2026-109618, CVE-2026-109619.
2. PHP project, "Informational advisory: Session upload progress", October 23, 2026. php.net
3. PHP project, "Supported Versions" and "Unsupported Branches" (read November 2, 2026). Supported, unsupported.
4. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching", October 21, 2026, last revised October 26. cisa.gov
5. CISA, Known Exploited Vulnerabilities catalog, version 2026.10.30: entries for CVE-2026-109618, CVE-2026-109619, CVE-2026-46300 and CVE-2026-48356. cisa.gov
6. Wiz, write-up of the PHP2Shell flaws (read November 2, 2026). wiz.io
7. Amazon Web Services security blog, on an exploit attempt before public disclosure, October 21, 2026. aws.amazon.com
8. Modat, PHP exposure before the October 21 release (data from October 20, 2026). modat.io
9. Patchstack, PHP vulnerability alert, October 2026. patchstack.com
10. WordPress documentation, "FAQ My site was hacked" (last updated July 26, 2026). wordpress.org
11. WordPress, "Requirements" (read November 2, 2026). wordpress.org
12. cPanel documentation, "MultiPHP Manager for cPanel" (read November 2, 2026). docs.cpanel.net
13. Adobe, security bulletin APSB26-73, July 14, 2026, last updated August 11. adobe.com
14. Adobe, Commerce system requirements (read November 2, 2026). experienceleague.adobe.com

Want help with this?

If you're not sure what your host's answer means, or what to replace and in what order, tell me what your site does and what your host said, and I'll say whether I can help. I reply within 2 business days, so if you think your site is under attack now, start with your host. I don't touch your live site, real records or keys without your written OK.