Critical PHP Security Update: What Website Owners Need to Do Now
Critical PHP Security Update: What Website Owners Need to Do Now
Two critical PHP vulnerabilities can allow unauthenticated remote code execution. Here is what UK businesses should check, patch and verify now, without turning the issue into unnecessary panic.
On the 21st of October 2026, the PHP project released an urgent PHP security update for two critical vulnerabilities rated 9.2 out of 10. They can allow an attacker to run code remotely without signing in. If your website or web application uses PHP, ask the person responsible for its server to confirm that it’s running PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a vendor package with the equivalent fixes. Don’t rely on a general assurance that “updates are automatic”. Ask what was patched, when, and how the live version was verified.
A website is a bit like a car, in more ways than you may initially think. It can look perfectly healthy, sleek and shiny, but if you pop the bonnet, everything underneath may be overdue for attention. Does it drive and get you from A to B? Sure. Most of the time.. and that’s fine, right? Is it something you’re proud of, as the dashboard looks like a Christmas scene, with an array of lights flashing up? Ehhh… Not really.
And that’s pretty similar to a lot of sites. The pages load, just about. The contact form works, and someone changed the homepage banner last month. And that’s all you need, right? …Right?
The reality is that it tells you very little about the software running on the server, and this week’s PHP security news is a sharp reminder of the difference.
PHP, if you’re unfamiliar, sits behind a large number of business websites and web applications, including sites built with WordPress, Drupal, Laravel and many bespoke platforms. On the 21st of October, the PHP project published fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution. In plain English, a successful attacker may be able to make the web server run code without first needing a valid account.
The risk is already moving beyond a theoretical vulnerability. Cloudflare says it has observed attack traffic, while security firm Patchstack reports active exploitation flagged by hosting partners, while entities such as NHS England assess further exploitation as highly likely.
What’s happened with PHP?
The PHP project released emergency patches on the 21st of October for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities rated 9.2 under CVSS v4.0. Both involve memory handling or internal state during web requests. Successful exploitation can allow an attacker to execute code without logging in.
The PHP team says all PHP installations that serve web requests are in scope, including common setups such as PHP FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers the demonstrated risk highest for mod_php. The project also states that there is no complete workaround; updating is the safest option.
Exploit reliability depends on the server build, its configuration, and how requests are handled, so compromise isn’t inevitable. Even so, “we have a firewall” or “the site is fully managed by an agency” simply isn’t enough evidence that the issue has been addressed. You need to make sure.
Which PHP versions contain the fix
The PHP security update is included in these versions:
| PHP branch | Patched version | What to do |
|---|---|---|
| 8.2 | 8.2.35 | Patch now and plan a move to a supported branch before the 31st of December 2026. |
| 8.3 | 8.3.36 | Patch now. This branch receives critical security fixes until the 31st of December 2027. |
| 8.4 | 8.4.27 | Patch now. This branch receives active support until the 31st of December 2026. |
| 8.5 | 8.5.12 | Patch now. This branch receives active support until the 31st of December 2027. |
If your provider uses an operating system or long-term support package that backports security fixes, its version number may not match the figures above exactly, but it can still be legitimate. Ask the provider to name the package and confirm that fixes for both CVEs have been applied.
Could AI make the PHP vulnerabilities more dangerous?
AI has already played a role in finding these flaws. OpenAI says AI-assisted security research identified one of the vulnerabilities, while cloud security researchers at Wiz have also highlighted concerns about the vulnerabilities and their potential impact on businesses running affected websites.
There’s no doubt that AI can help defenders find serious weaknesses sooner, but on the flip side, similar capabilities may also make it easier for attackers to investigate and adapt exploits.
Cloudflare says attackers have been changing malicious request payloads in attempts to bypass its protections, which is evidence of evolving attack techniques, but perhaps stops short of being proof that AI has successfully bypassed the firewall. The concern for businesses is speed: publicly disclosed vulnerabilities can attract repeated, automated probing before every website owner has patched.
For UK businesses, the immediate response stays practical. Confirm the live PHP version, apply the emergency fixes, check for suspicious activity and make sure the people responsible for your website, hosting and security are working from the same information.
What should website owners do now?
Most businesses need a short, controlled response. It should be urgent, while still protecting availability and leaving an audit trail.
Find the owner: Identify who controls the PHP runtime in production, which may be your managed hosting provider, web developer, cloud team or internal IT function. If responsibility is unclear, resolve that first rather than forwarding the advisory around a long email chain.
Confirm the scope: List the public websites and web applications that use PHP, including customer portals, campaign sites, older microsites, staging systems and forgotten subdomains. Remember, an asset that has slipped out of normal ownership is still reachable from the internet.
Apply the PHP security update: Move each supported branch to at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Where a vendor backport is used, obtain confirmation that both CVE-2026-109618 and CVE-2026-109619 are covered.
Test and verify: Use a staging environment where practical, take a recoverable backup, agree on a rollback route and test the functions that matter to the business: logins, forms, payments, uploads, integrations and scheduled jobs. Restart the relevant PHP workers if required, then check the version exposed by the live runtime rather than only the package list.
Review for signs of trouble: Patching prevents future use of the flaws; it doesn’t tell you what happened beforehand. Review relevant web, application and security logs, unexpected file changes, new accounts, scheduled tasks and unusual outbound connections. As always, escalate anything suspicious through your incident response process.
Record the evidence: Keep the affected systems, completion time, tested services, patch source and named owner together - this makes the response easier to explain to leadership, customers, auditors and insurers if the question arises later.
Does this affect WordPress websites?
Potentially, yes. WordPress is written in PHP, so the PHP runtime underneath the site matters. The same applies to WooCommerce, Drupal, and Laravel applications, as well as many custom portals. Updating WordPress core, a theme or a plugin doesn’t update the server’s PHP runtime, as they’re different layers, often managed by different suppliers.
The difficult part of issues such as this is often accountability. A web agency may maintain the site, a hosting company may maintain the server, and an internal IT team may own the wider risk. Each can reasonably assume somebody else has handled the PHP security update. Assumptions are efficient right up until they aren’t.
What if the website can’t be updated immediately?
PHP says there are no complete mitigations other than updating. A web application firewall can provide an additional layer, but it isn’t a replacement for patching. The UK NCSC advises organisations to consider taking systems offline where immediate remediation isn’t feasible.
If a critical site can’t be patched promptly, make the exception visible. Record why the update is blocked, who owns the decision, which compensating controls are in place and when the issue will be revisited. Depending on the service, it may also be sensible to restrict exposure, place it behind additional access controls or temporarily disable non-essential functions. Those choices need technical review because a hurried configuration change can create a different outage.
Older PHP versions need a separate decision
PHP 8.1 and older no longer receive normal updates from the PHP project. Some operating system and commercial long-term support vendors may provide backported fixes, but that needs to be confirmed rather than assumed. The PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1 because of the severity of these flaws, but those exceptional patches don’t turn an unsupported platform into a healthy long-term position.
PHP 8.2 also reaches end of life on the 31st of December 2026. A business running 8.2, therefore, has two jobs: apply 8.2.35 now, then complete a planned upgrade to a supported branch before the end of the year. Emergency patching and lifecycle planning are related, but they aren’t the same task.
Remember, a website is an operational service
Websites are often treated as finished marketing assets, but they’re much more than just a shop window - they’re live technology services with an operating system, runtime, frameworks, extensions, integrations, credentials, logs and backups. And it can be the most polished homepage in the world, but that doesn’t make those layers self-maintaining.
What we tend to see is a gap between suppliers. The developer looks after the application, the host looks after the platform, IT looks after the company systems, and marketing owns the content. When responsibility for patching and verification sits between those roles, a critical PHP vulnerability becomes a useful test of the operating model.
Once the immediate PHP security update is complete, ask four simple questions:
- Do we have a complete list of public websites and web applications?
- Is there a named owner for every technical layer?
- How quickly must critical updates be assessed and applied?
- What evidence shows that patching, testing and monitoring actually happened?
None of those questions seems to be especially glamorous, but they also shouldn’t be too difficult to answer, and they’re far more useful to know now, rather than being discovered during an incident that “managed” meant something different to each supplier.
How Fifosys can help
If you’re unsure which of your websites use PHP, who owns the server layer or whether the latest fixes have reached production, Fifosys can help you bring the right technical parties together and turn the advisory into a clear action plan. First, verify the patch. Then make website ownership, monitoring and lifecycle management less ambiguous before the next urgent update arrives.
Speak to the Fifosys team if you need help understanding your exposure, coordinating with suppliers or strengthening the way internet-facing systems are managed.
Frequently asked questions
What are the critical PHP vulnerabilities reported in October 2026?
CVE-2026-109618 and CVE-2026-109619 are two critical PHP vulnerabilities rated 9.2 under CVSS v4.0. Successful exploitation may allow unauthenticated remote code execution on affected PHP web servers.
Which PHP versions fix the vulnerabilities?
The PHP project released fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some operating system and long-term support vendors may also supply equivalent backported fixes.
Does this affect WordPress websites?
Potentially, yes. WordPress is written in PHP, so the PHP runtime underneath the site matters. The same applies to WooCommerce, Drupal, Laravel applications and many custom portals. Updating WordPress core, a theme or a plugin does not update the server’s PHP runtime. They are different layers, often managed by different suppliers.
Does a web application firewall protect against these vulnerabilities?
A web application firewall can provide an additional layer of protection, but the PHP project says there is no complete workaround other than applying the security update. Firewall rules should not be treated as proof that a vulnerable PHP runtime is safe.
Who is responsible for updating PHP on a business website?
Responsibility depends on the hosting and support arrangement. It may sit with a managed hosting provider, website developer, cloud team or internal IT department. Businesses should confirm who owns the production PHP runtime and obtain evidence that the live environment has been patched.
Does this PHP vulnerability affect Squarespace websites?
Squarespace is a managed website platform, so customers do not normally administer the underlying PHP runtime. The main consideration is whether the business also operates separate PHP-based websites, custom applications, portals or integrations hosted elsewhere.
Website security shouldn't depend on assumptions
From vulnerability management and technical ownership to incident response and ongoing risk reviews, Fifosys helps businesses keep their internet-facing services secure, supported and accountable.
Talk to our team
Get practical guidance on understanding your exposure, coordinating suppliers and strengthening security.
Explore our Security Framework
Discover the controls and protections that help businesses reduce risk across their IT environments.