If your website or business software uses PHP, there’s a good chance you’ve seen the recent security headlines and wondered what they mean for you. WordPress is one familiar example, but the issue reaches much further.
The immediate answer is straightforward: ask whoever manages your hosting to confirm that the PHP running your website has received the security fixes for these vulnerabilities. Do that today.
At BPS Designs, we had already started moving our WordPress websites to static sites built with Eleventy. These vulnerabilities have given us another reason to move that work along faster.
But first, let’s explain what has happened and why patching needs to come before any longer-term plans.
What has happened?
On 21 October 2026, the PHP project released fixes for two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they can allow an attacker to run code on a vulnerable server without logging in. The releases containing these fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Update to the appropriate fixed release or a later supported security release. See the official PHP security advisory.
“Run code on your server” might sound a little abstract. In practice, it can give someone the ability to interfere with your website and potentially the information it handles.
The exact impact depends on the installation and its permissions, but the possible consequences are serious: stolen information, altered pages, disruption and a difficult recovery.
The PHP Foundation’s explanation confirms that remote code execution has been demonstrated, including on Apache with mod_php and through application code paths on PHP-FPM. Using a different hosting setup is no reason to assume you’re safe.
That makes this an urgent maintenance job.
Updating WordPress alone won’t fix this
PHP is the software underneath WordPress that helps it generate pages and handle requests. Updating WordPress, its plugins and its themes is still important, but those updates do not, by themselves, patch the PHP installation on your hosting.
That distinction is easy to miss. You can open your WordPress dashboard, see that everything is up to date, and reasonably assume the job is done.
For this issue, you need confirmation from your hosting provider or server administrator.
A useful message to send is:
Please confirm that the PHP installation serving our website has the fixes for CVE-2026-109618 and CVE-2026-109619, and that the patched version is running.
Some hosting providers use vendor packages with security fixes applied to older version numbers. The PHP advisory explains this approach. Ask for confirmation that both fixes are included, rather than relying on a version number alone.
And look beyond your main website. Old sites, staging environments, forgotten subdomains and other services may also use PHP.
What should website owners do now?
The UK’s National Cyber Security Centre recommends immediate action, with priority given to systems exposed to the internet.
For a business owner, the practical steps are:
- Find out where you use PHP. Ask your hosting provider or technical team to check websites and other software that may include it.
- Get the security updates applied promptly. If you use an unsupported PHP version, arrange a supported upgrade or confirm that your vendor supplies the necessary fixes, as the PHP advisory recommends.
- Agree a plan if patching is delayed. Have your technical team follow the official temporary mitigation guidance while arranging the update. These measures only reduce exposure; updating is the complete fix. The NCSC advises considering taking affected systems offline if temporary mitigations cannot be applied, or would take too long.
- Check for signs of compromise. Installing a patch closes the vulnerability; it does not remove anything an attacker may already have left behind.
You don’t need to understand every technical detail yourself. You do need someone responsible for checking it and confirming the work.
Why we’re accelerating our move to Eleventy
For our websites, we’re also looking at how much software needs to be running just to show someone a page. Where a static site meets our needs, we can simplify things.
With WordPress, PHP typically builds the page when a visitor requests it. With Eleventy, we can build those pages ahead of time and publish the finished files.
For the sites we migrate fully, that means visitors can read our pages without a live WordPress installation or PHP generating them.
For a website whose main job is to share information and articles, that’s an appealing approach. Those pages can be ready to read without a database working behind every visit.
There is still maintenance to do. Hosting accounts, build tools, forms and any connected services all need care. The old WordPress installation also needs to be properly retired; leaving it accessible would leave its risks in place.
Removing software we no longer need gives us fewer things to maintain and fewer routes for an attacker to try.
WordPress remains useful, and plenty of applications need PHP. Moving to a static website won’t suit every business or every feature.
For us, the migration was already under way. This incident has increased its priority.
For anyone still running PHP, though, the immediate task is the same: confirm that the security fixes are applied. A migration planned for next month won’t protect a vulnerable website today.