Since July, the US government has added three flaws in WordPress itself to its list of flaws with reliable evidence of use in real attacks. On 21 October, PHP, the language WordPress is written in, released fixes for two critical flaws of its own. In my view, the useful question for a business owner isn't which flaw is worst. It's who is watching the parts your website is built from.
Three WordPress flaws with evidence of real attacks
The US Cybersecurity and Infrastructure Security Agency (CISA) keeps that list. Three flaws in WordPress core, the software itself rather than a plugin, have been added since July.
Two were added on 21 July. WordPress had released a fix on 17 July for what it called one critical and one high severity issue. It turned on forced updates for sites running affected versions, meaning WordPress could install the fix on its own, and still recommended updating immediately. CISA's entry says that, chained together, the pair lets someone who isn't logged in run their own code on a default WordPress install. One of the two applies when a plugin or theme passes untrusted input to WordPress.
The third was added on 25 September, three days after WordPress released a fix for a flaw it called critical. I wrote a notice on that one.
That's three entries in a little under ten weeks. Each time the fix came out first, three or four days before CISA listed the flaw. WordPress's own documentation says automatic updates are on by default on most sites, so a site can take a fix on its own. The same page says they can be switched off with a setting in the site's configuration file or by code added to the site.
What PHP fixed on 21 October
PHP is the programming language WordPress is written in. It runs on the server that hosts the site, and WordPress isn't the only thing built on it.
On 21 October the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its advisory says they fix two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619 (CVE numbers are the public ID tags flaws are filed under), that "can allow unauthenticated remote code execution". In plain terms, someone who hasn't logged in to anything could make the server run commands of their choosing. PHP rates both 9.2 out of 10 on a standard severity scale.
The advisory says the risk is highest on one way of setting up the server (it names mod_php, a way of running PHP inside the web server software), where a working attack has been demonstrated that can trigger before any of your website's own code runs. WordPress's own post, published the same day, says the flaws "are not specific to WordPress". It adds that your web host may already be updating PHP, but that you should still check with them.
What's known and what isn't
Here's where the PHP flaws stand.
- Fixed: PHP has released fixed versions for 8.2 to 8.5.
- Not on CISA's list: as of its 23 October update, neither flaw is in the catalogue.
- A working attack exists: PHP says one has been demonstrated. Rapid7, a security firm, says several public demonstration attacks exist, though each works only on a specific combination of operating system, PHP version and web server software.
- Attacks on real sites: when I read it on 25 October, Rapid7's post said it hadn't observed any, though there were multiple reports of attempts, and said it expects attacks on real sites to follow given how widely PHP is used. It doesn't describe any confirmed compromise.
- A third item: on 23 October PHP published a separate advisory, CVE-2026-115560, which it calls an unlikely route to remote code execution and says needs an unusual combination of configuration and application code. It says the full advisory will come with its next release.
What this adds up to
That's a different position from the July and September flaws, which CISA lists on evidence of active attack. I'm writing this on 25 October, and that can change. Updating stops a flaw being used from that point. It doesn't show whether anyone used it before, and that's a question for whoever hosts the site.
Who watches what your site runs on
WordPress's update screen is where WordPress and your plugins get updated. PHP isn't one of them, because it sits with whoever runs your hosting. WordPress's post says you can see your version under Tools, then Site Health, then Info, then Server.
The 21 October advisory says PHP 8.1 and older no longer get updates from the PHP project. It says some vendors that package PHP for servers or sell long-term support provide their own fixes, and otherwise to upgrade to a supported version. Separately, the announcement of PHP 8.2.35 says PHP 8.2 reaches end of life on 31 December 2026, which means no further security fixes after that date.
What to do with that answer depends on your hosting plan, what the site is built with, and whether an older site will cope with a newer PHP. That's a judgement for whoever maintains the site. The question to put to them is simple: which PHP version are we running, and has it had the 21 October fix? PHP's advisory says to check your vendor for updated packages, so ask about the fix itself, not only the version number.
Then sort yourself into one of these.
- Your host manages PHP. Ask them the question above.
- An agency or developer looks after the site. Forward them this and ask the same question.
- You manage your own server. PHP's advisory is the page to read.
- You don't know who does any of this. That's a bigger finding than these two flaws.
What a custom build changes, and what it doesn't
The Astro and Next.js sites I build (two tools for building websites) don't contain PHP, so these two flaws don't apply to them. The code has no PHP files in it.
That doesn't make a custom site immune to this kind of news. It's made from code libraries other people publish, and those get flaws too. I run an automated scan that lists known flaws in the libraries my sites depend on. It reports them; it doesn't patch anything. By a lean custom build I mean custom code where I can list every part it's made from.
I've published one comparison of a custom build against a WordPress one. It's about speed, not security, and it says what it doesn't prove.
Where to start
If nobody can tell you which PHP version your site runs on, or who updates it, that's the place to begin. Ask whoever hosts it the question above.
Pages worth acting on
Related page
CVE-2026-87902: how to check your WordPress site is patched
The September core flaw that CISA added to its list, and the question to ask whoever maintains the site.
View pageRelated page
Why I don't start with WordPress
Where it still fits, where it can cost a service business, and what I build on instead.
View pageWhat to read next
Why I don't start with WordPress (and where it's still the right call)
A first-person case for choosing the platform last, with the one comparison I've measured and five questions to ask before you agree to any platform.
Read articleCustom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleQuestions local business owners usually ask next
Moving to a lean custom build
If your site is slow, hard to look after or no longer fits the business, the Free Website Review looks at how it's built and whether it needs a fix or a rebuild. It isn't a security audit, and it doesn't replace asking your host about PHP. If it's a rebuild, I build it around what your business needs.