PHP security update: what it means for your website and what to do next

Website security rarely gives you much notice. Yesterday’s PHP2Shell disclosure was a reminder of how quickly a problem behind the scenes can become a priority for businesses.

On 21 October 2026, PHP released emergency security updates for two critical vulnerabilities. These flaws can allow someone to run malicious code on an affected server without logging in. Fixes are available, so the priority now is to establish whether your website is affected and confirm that the update has been applied. PHP security advisory

You don’t need to become a server administrator overnight. You do need a clear answer from whoever looks after your hosting.

What happened yesterday?

PHP2Shell is the name given to two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619.

A coordinated disclosure had originally been planned for 22 October. After information leaked publicly, that timetable moved forward to 21 October, bringing the security response forward too. Both vulnerabilities have been rated critical, with severity scores of 9.2 out of 10. Ubuntu’s disclosure update

Cloudflare has since confirmed that it observed attack traffic targeting its customers. There is a practical reason to act promptly: attempts to exploit the flaws are already happening. Cloudflare’s response

That doesn’t mean every affected website has been hacked. It means leaving an unpatched installation online carries a risk that needs addressing.

Why does this reach beyond one website platform?

PHP is software running on your server. It powers platforms including WordPress, Drupal and Joomla, alongside bespoke websites and applications.

The vulnerabilities sit within PHP’s handling of memory and failed requests. Researchers demonstrated attacks against several popular platforms, but those were examples of the wider problem. A website can be exposed even when its own application code is secure. Wiz’s research

This distinction matters when deciding what to update.

Keeping your CMS, themes and plugins current remains good maintenance. However, those updates don’t replace the PHP security fix. The underlying server software needs attention from your hosting provider, developer or infrastructure team.

What could happen if it’s left unresolved?

Successful exploitation can allow an attacker to execute code with the permissions of the PHP process. That can give them access to files and services available to that process; it does not automatically mean unrestricted administrator access to the entire server. PHP’s technical advisory

Researchers have also demonstrated access to sensitive information in memory, including passwords, tokens and API keys. Wiz’s findings

For a business, the possible consequences include:

• Disruption: an unavailable website, failed enquiries or interrupted orders.
• Exposed information: customer data or credentials accessible to the compromised application.
• Altered content: malicious changes, misleading pages or redirects.
• Recovery work: investigation, rebuilding affected systems and replacing exposed credentials.

Those are possible outcomes, rather than evidence that they have happened to your site. The aim is to close the vulnerability and check whether anything needs investigating.

What’s being done about it?

PHP has released fixes, and software distributors are providing updated packages. Some vendors apply the security changes to an older package without changing it to the latest upstream PHP version. This is known as a backported fix. PHP’s update guidance

Protection is also being added around affected systems. Cloudflare, for example, has deployed web application firewall protections and continues to adjust them as attack techniques change. It still advises customers to patch PHP. Cloudflare’s protection update

For website owners, the job is to make sure those fixes have reached the systems their business actually uses.

Eight checks to work through with your hosting team

1. Find every relevant website and application

Start with your main website, then check subdomains, staging sites, old installations and other PHP applications.

A forgotten development site still needs attention if it is publicly accessible. Products that bundle their own PHP installation may need a separate vendor update, too. NCSC-NL’s recommended actions

Make a short list so each system has an owner and a confirmed status.

2. Get a specific answer from your hosting provider

Ask whoever manages the server to confirm:

• Whether your installation was affected by either vulnerability.
• Which fixed release or vendor security package has been installed.
• When it was applied.
• Whether the running services have been restarted and checked.
• Whether every relevant site and server is covered.

“Security updates are automatic” is useful background. You still need confirmation that these particular fixes are active.

3. Confirm the correct security update is installed

The fixed upstream releases are:

PHP branch	Release containing the fixes
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Use these releases or a later release in the relevant supported branch. NHS England’s remediation guidance

If your host uses backported fixes, ask for the package version and vendor advisory confirming coverage of both CVEs. A familiar-looking version number alone cannot settle that question. Ubuntu’s patched package list

For PHP 8.1 and older, establish whether your vendor supplies a maintained fix and agree a route to a supported PHP branch. The PHP project no longer provides normal support for those older branches. PHP’s guidance for older installations

4. Check your backup and recovery arrangements

Before making changes, confirm that you have usable backups of the website files and database, and that someone knows how to restore them.

For a busy shop or booking system, consider how recent orders and submissions would be preserved during recovery.

A backup helps you recover. It doesn’t fix vulnerable server software, and a recent backup should not automatically be assumed free of compromise.

5. Verify the website is using the patched software

Installing a package is only part of the work. The services using PHP need to load the updated components.

Ask your administrator to restart the relevant PHP workers or web server services, then check the version or patched build actually serving website requests. Ubuntu explicitly notes that applications may still require restarting after automatic updates. Ubuntu’s restart guidance

Where multiple servers, PHP versions or containers are involved, verify each one.

6. Reduce exposure if patching cannot happen immediately

Have your administrator review the official temporary mitigations and your firewall provider’s current advice.

These measures can reduce exposure, but they do not fully fix the vulnerabilities. CERT-EU recommends considering isolation of affected internet-facing applications until a fix can be applied and verified. CERT-EU’s recommendations

A maintenance page served through the same vulnerable PHP installation should not be treated as isolation.

7. Look for signs that need investigation

Ask your technical team to review server and application logs alongside changes to files, user accounts and scheduled tasks.

Unexpected redirects, unfamiliar administrator accounts, repeated server errors or unexplained PHP crashes deserve attention. An absence of obvious errors does not prove that exploitation has not occurred. PHP’s logging guidance

If compromise is suspected, preserve the available evidence and involve someone experienced in incident response. Patching closes the vulnerability; it does not remove access an attacker has already established. Recovery may require a clean rebuild and replacement of exposed credentials.

8. Test the site and record what was completed

Once the update is active, test the journeys your business depends on: forms, logins, checkout, uploads, payments and integrations.

Record which systems were checked, what was installed, who verified it and any outstanding work. Keep monitoring afterwards and give remaining tasks a named owner.

That gives you a useful answer when someone asks whether it’s sorted.

What we’ve done for Bronco customers

We’ve updated all of Bronco’s servers with the PHP2Shell security patches and made sure the WordPress installations we manage are up to date.

For customers whose websites we host and maintain, this work has already been completed. The patches are in place, so you don’t need to apply these updates yourself. If you have any questions about your website, our team is here to help.

Need a hand getting it checked?

If you’re unsure what your website runs on, or your hosting provider’s reply leaves you with more questions, talk to the Bronco team.

We can help you understand your setup, work through the checks and identify what needs doing next. Clear advice, practical help and a plan to get things sorted.