Critical PHP vulnerabilities: how to protect your business website

If your business website or web application uses PHP, contact the people responsible for its hosting today. Critical security updates were released on 21 October 2026, and applying them should be treated as urgent.

You do not need to understand programming to take the right action. The key is to establish whether your systems use PHP, who is responsible for updating it, and whether the fixes have actually reached the servers running your website.

What has happened?

The PHP project has released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. You may also see them discussed under the name PHP2Shell. Both are rated 9.2, Critical, under CVSS v4.0, a standard used to describe the severity of security flaws.

PHP is software used on web servers to run many websites and business applications, including WordPress-based sites and some online shops, customer portals and bespoke systems. It is separate from your website's themes and plugins.

According to the PHP project's advisory, these flaws can allow unauthenticated remote code execution. In plain English, an attacker may be able to make a vulnerable server run their instructions without first knowing a password or logging in.

The first flaw involves memory corruption when PHP handles an out-of-memory condition. The second involves internal information being used after the memory behind it has been freed. Your hosting provider or developer can use the advisory references below to assess the technical details.

These are vulnerabilities in PHP itself, not simply problems with a particular WordPress plugin. Updating your website's content management system alone does not necessarily update PHP.

What could this mean for a business?

Depending on the server's permissions and configuration, successful exploitation could allow an attacker to:

• Access information available to the website, potentially including customer data or connection credentials.
• Change pages, inject malicious content or redirect visitors elsewhere.
• Disrupt online orders, enquiries or access to a business system.
• Leave malicious files or other access behind for later use.

A vulnerable installation is not proof that a website has already been compromised. Equally, a website that looks normal is not proof that it is secure.

CERT-EU reports that technical details and initial proof-of-concept examples are circulating publicly, increasing the risk of exploitation. Businesses should not wait for a visible problem before acting.

Which systems need checking?

The PHP team says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Those names describe different ways a server runs PHP; they are useful terms to pass to your provider, not something you need to configure yourself.

The PHP team considers Apache with mod_php the highest-risk setup, with a demonstrated exploit that can run before any application code executes. This is why a login page or an application-level security plugin cannot be relied upon to stop every attack path.

Ask your provider to check more than your main website. Include online shops, customer portals, subdomains, staging sites, older websites and third-party products that include PHP. Managed hosting does not automatically mean the update has already been applied; request confirmation.

Not every website uses PHP. If yours does not, these particular flaws do not affect that site's runtime, but other systems used by your business may still need checking.

Which PHP versions contain the fixes?

The security releases issued on 21 October 2026 are:

• PHP 8.5: update to 8.5.12 or a later security release.
• PHP 8.4: update to 8.4.27 or a later security release.
• PHP 8.3: update to 8.3.36 or a later security release.
• PHP 8.2: update to 8.2.35 or a later security release.

Earlier releases within those branches need attention unless the supplier has explicitly provided a patched package covering both vulnerabilities.

Some Linux distributions and long-term-support suppliers backport security fixes: they apply the repair without changing to the upstream version number listed above. In that case, ask for the supplier's security notice and installed package revision confirming that both CVEs are fixed. A version number alone may not tell the whole story.

PHP 8.1 and older are no longer supported by the PHP project. Some suppliers provide extended support, and the PHP team has made limited source patches available for 7.4, 8.0 and 8.1 because of the severity. These do not restore general support for those versions. Your provider should arrange a verified fix now and a move to a supported branch.

PHP 8.2 also reaches the end of its PHP-project security support on 31 December 2026, so businesses using it should plan their next upgrade as well as applying today's fix.

What should you ask your website provider to do?

1. Confirm what is running and who owns the update

Ask which PHP branch and package build actually serve each website or application. Your website designer, hosting company and IT provider may have different responsibilities, so make sure someone has clear ownership of the work.

For the technical team: checking the command-line PHP version alone is not enough. The web server may use a different PHP installation or pool, and separate sites, containers or servers may run different versions. Use authenticated administrative checks rather than leaving a public diagnostic page online.

2. Apply the security update promptly

Ask the responsible provider to install a fixed release or a vendor-confirmed patched package. Prioritise internet-facing systems and do not leave this until the next routine maintenance cycle.

Take or verify a recoverable backup and perform focused compatibility checks, but do not allow a lengthy testing process to leave an exposed system publicly accessible without a protection plan. If a fix cannot be applied promptly, discuss restricting or temporarily removing public access.

3. Make sure the running services use the fix

Installing a package is not the same as confirming every live process is patched. Ask your provider to restart or replace the relevant PHP workers and services as required by the supplier, and to update and redeploy affected containers or server images.

Request confirmation that every instance serving traffic now uses a fixed build, not just that an update command completed successfully.

4. Check that the business-critical parts still work

After the update, check the functions your customers and staff depend on: enquiries, sign-in, checkout, bookings, uploads and integrations, where applicable. Ask the provider to review errors and monitor the site after the change.

5. Review for signs of compromise

Ask your provider to review available web, application and security logs, unexpected file changes, unfamiliar administrator accounts and unusual activity. No single check can prove a server was never compromised, especially where logging is limited.

Patching closes the vulnerability; it does not remove an attacker who has already gained access. If anything suspicious is found, involve your IT or incident-response provider, preserve relevant evidence and follow a containment and recovery plan. Credentials or secrets accessible to the affected system may need to be replaced from a trusted environment. Consider data-protection reporting obligations with appropriate professional advice if personal data may have been exposed.

What if an update is not available immediately?

The PHP project is clear: there is no complete configuration workaround. Updating is the only complete fix. CERT-EU recommends considering isolation of internet-facing applications until the fix has been applied and verified.

Your hosting or security provider may use temporary access restrictions, targeted web application firewall rules and the specific configuration measures in PHP's advisory to reduce exposure. These are interim measures, not evidence that the server is safe.

For technical teams, the official guidance includes disabling session upload progress before request parsing and restarting all workers, plus disabling fatal-error backtraces on PHP 8.5. These block particular confirmed paths only, not every variant. Application-level changes made after request parsing are not an equivalent protection.

The advisory also describes carefully controlled changes to PHP memory and request limits. Do not copy memory-setting advice into a live server without specialist review. Removing PHP's memory limit can introduce availability risks, and the advisory requires separate resource boundaries and other precautions. Read the full, current guidance rather than applying isolated settings from social media.

A firewall, HTTPS padlock, strong password or multi-factor authentication remains useful, but none replaces this PHP update.

A message you can send to your hosting provider

Please confirm whether any of our websites, staging sites or business applications use PHP and are affected by CVE-2026-109618 or CVE-2026-109619. If so, please apply the relevant security update urgently, restart or replace affected workers as required, and confirm the fixed version or vendor-patched package running on every instance. Please also confirm that key website functions have been checked and that available logs have been reviewed for suspicious activity. If a fix cannot be applied immediately, please explain how public exposure will be restricted and when the update will be completed.

Keep their response with your maintenance records. It gives you something more useful than a general assurance that the website is “up to date”.

How to reduce the risk next time

• Keep an inventory. Know which websites and applications you operate, who hosts them and who maintains them.
• Use supported software. Plan upgrades before support ends, including PHP and the applications that rely on it.
• Agree an urgent patching process. Critical security fixes should not have to wait for a monthly maintenance window.
• Maintain tested, protected backups. A backup should be recoverable and protected from changes by a compromised web server.
• Limit access and permissions. Give each application only the access it needs and separate unrelated sites where practical.
• Keep useful monitoring and logs. They help detect suspicious activity and investigate what happened.

The immediate priority is simple: identify PHP systems, get the fixes applied, and obtain confirmation that the live services are protected.

Contact ITfinity if you need help understanding your exposure or coordinating the next steps with your website and hosting providers.

Sources and further reading

Guidance checked on 21 October 2026. This is a developing security issue; providers should check the current advisories before making changes.

• PHP's official security advisory and release announcements
• CERT-EU: Critical Vulnerabilities in PHP, advisory 2026-018
• PHP technical advisory for CVE-2026-109618
• PHP technical advisory for CVE-2026-109619