The PHP flaw is in the server under your website

On 21 October the PHP project released fixes for two flaws, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in first. Both are scored 9.2 out of 10. If your website runs on WordPress, Drupal, Joomla, Magento, or anything else built in PHP, the fix is not in your website. It is in the PHP installed on the server underneath it. On shared or managed hosting that makes it your host's job. If you run your own server, it is yours.

That puts most site owners in an awkward spot. You cannot reach the thing that needs fixing, so you are left asking the company you pay and hoping you can tell a real answer from a vague one. If you are one of the people who does run their own server, skip to the version table, because the job is yours and you can start now.

What the flaw is

PHP is the programming language a large share of the web runs on. It is not something you install; it is already there on the server, underneath whatever software builds your pages. These two bugs are in PHP itself. One involves how PHP behaves when it runs out of memory partway through a request, the other how it reuses leftover state between requests. In both cases a visitor who never logs in can, under the right conditions, get the server to run commands. Security researchers at Wiz demonstrated this against WordPress, Drupal and Joomla before the fixes shipped. The technical write-ups are published as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

One caveat before you act on that table. If your PHP came from a Linux distribution rather than php.net, which is usual on a managed server, your version will not look like the ones above: distributions backport security fixes into their own package revisions, so something reported as 8.3.11 can already carry the fix. Check that distribution's advisory rather than the upstream number, or ask your host to. Same for 8.1 and older, where upstream published nothing new but some vendors backport anyway. If nobody is patching your branch, plan the upgrade onto a supported one.

Updating WordPress does nothing here

The reflex when a security story breaks is to log into WordPress and update everything: core, theme, every plugin. Usually that is good advice. Here it accomplishes nothing, because the bug is not in WordPress or in any plugin. It sits one layer below, in the language they are written in. You can run a completely up-to-date WordPress on unpatched PHP and still be exposed.

WordPress will at least tell you which PHP version you are on. Go to Tools, then Site Health, then the Info tab, and open the Server section. What it will not tell you is whether that version is a patched one. On upstream numbering 8.3.36 is fixed and 8.3.11 is not, though a distribution package showing the lower number can already carry the backport. The two numbers look almost the same, so read the digits carefully against the table.

How to check whether it actually got fixed

Most advice stops at "make sure your host has updated PHP", which is incomplete. Three things to work through, in order.

1. Find your current PHP version. In WordPress it is under Tools, Site Health, Info, Server. On other platforms it is usually in your hosting control panel, or you can ask support directly. Write the full number down, all three parts of it.
2. Compare it against the table above. It has to be the same first two numbers and the same or a higher third number. 8.4.27 or above is fine. 8.4.5 is not, even though it is a higher branch than 8.3.36. If the number has a distribution suffix on it, that is the backport case above, and the upstream comparison will mislead you.
3. Ask when they last restarted PHP after the upgrade. This is the question almost nobody asks. Installing the new PHP does not retire the copy already running in memory. The old code keeps serving visitors until the processes are restarted, so a host can truthfully say they have upgraded while still running the vulnerable version.

If support comes back quickly with a real version number and a restart date, good. If they go vague on the restart specifically, push. Both advisories are explicit that restarting the workers is part of the fix.

If you run the server yourself, the work is yours rather than a support ticket: update PHP through whatever installed it, restart the processes that serve your site (php-fpm, or Apache where PHP runs inside it), then confirm what is actually being served. That last step needs more care than it looks, because the three obvious ways to check answer three different questions.

• php -v reports whichever command-line binary comes first on your PATH. On a machine with more than one PHP installed that can be a different build from the one serving your site.
• php-fpm8.3 -v tells you which build is installed on disk. Use the binary for your own branch, so php-fpm8.5 if you are on 8.5, and the full path /usr/sbin/php-fpm8.5 if you are not root, because that directory is not on a normal user's PATH. It says nothing about the workers currently running, so if the restart quietly failed it will report the patched number while your visitors are still served the old code.
• A one-line page that prints PHP_VERSION, fetched over HTTP is the one that answers the question, because the number comes back from the process actually handling requests. Use a file containing only an echo of PHP_VERSION rather than phpinfo(), which would publish your environment variables, absolute paths and loaded configuration on a page nobody has to log in to see, and those variables routinely hold database and mail credentials. Restrict it to your own IP address if you can reach the server config, or failing that give it a name nobody would guess, delete it when you are done, and clear any cache or CDN sitting in front of it, since the response can outlive the file.

One catch even with that check: a single request only proves which worker answered it. A reload does not necessarily replace the processes that answer requests, so depending on the server the patched file can sit on disk while the old build keeps serving visitors. Do a full restart rather than a reload, then confirm none of the original processes are still alive before calling it done.

Does this mean your site was hacked?

Probably not, and it is worth separating what is established from what is being implied. Working exploit code for the first flaw is public, and security vendors including Recorded Future and SOCRadar report attempts against real servers. As of 23 October, in-the-wild exploitation was still being described as reported and under investigation rather than confirmed, and the flaws were not listed in the US government's Known Exploited Vulnerabilities catalogue. So: actively probed, not yet a documented mass compromise.

What actually raises your own risk is narrower than the headlines suggest.

• Whether anything reaches PHP at all. Both flaws need a request to get as far as the PHP runtime. A site serving plain HTML files has no route to the bug, even sitting on an unpatched server.
• How your host runs PHP. The older arrangement, where PHP runs inside the web server process, is the configuration researchers confirmed a full compromise against. The more modern setup, where PHP runs as a separate pool of processes, is harder to exploit but not safe.
• Shared hosting. Your neighbours are on the same machine, so someone else's unpatched site can be the way in, and you are relying on your host having patched the whole box rather than just your bit of it.

None of that changes what you should do about it. It just means being a few days behind is not the same thing as having been breached.

If you want more than reassurance, ask two further things alongside the version number: whether they saw exploitation attempts against their platform, and whether someone will check your account's access logs for unexpected POST requests around the disclosure date. Plenty of hosts keep those logs and will go through them if asked.

What Simplepages customers had to do

Nothing. The servers that serve your pages were on the patched PHP releases within two days of the fixes being published, and nobody had to log in, update anything, or get in touch.

It works that way because of how the pages are built. Your Simplepages page is static HTML, so there is no database sitting behind it and no plugin directory that needs keeping up to date. Our editor will not produce PHP either: it writes HTML and CSS, the checks that run over generated pages reject a file containing PHP, and the files you can upload to a site are limited to HTML, text, XML and JSON. When something in the runtime underneath does need patching, that is one change on our side instead of thousands of separate updates for site owners to chase.

That static output is also why we let you download your page as plain HTML and host it anywhere. A folder of HTML files has no version number to track, which is a reasonable thing to want from a brochure site or a set of service pages that grew into a full website. If you are weighing up what to move to, our AI website builder produces that kind of site from a description of your business, though the general point stands whichever static host you pick.

What a static page does not protect you from

Static hosting removes some categories of attack, not all of them. The routes below stay open no matter how your site is built, and across a year they probably deserve more of your attention than this month's PHP story does.

• Your own account. If someone gets your email password or reuses a leaked password of yours, they can edit the site. Turn on two-factor authentication wherever it is offered.
• Your domain name. Whoever controls your domain registrar controls where your visitors land, regardless of what is hosted. Lock the domain and secure that login properly.
• Third-party scripts. Every tracking pixel, chat widget and booking embed you add runs code from somebody else's server on your page. Each one is a trust decision.

What to do this week

If your site runs on PHP and somebody else hosts it, send them one message this week asking for two things: which PHP version you are on now, and when they restarted it after upgrading. Push for the actual numbers. If the server is yours instead, do the upgrade and the restart, then check that the version your server reports has actually moved. Exploit code for these flaws is already public and vendors are reporting attempts, so there is less room than usual to be a few weeks behind.