What has happened?
The PHP security team released emergency updates on 21 October 2026 for two critical vulnerabilities. They are tracked as CVE-2026-109618 and CVE-2026-109619 and both received a severity score of 9.2 out of 10.
The flaws can allow remote code execution without authentication. In plain English, an attacker may be able to make a vulnerable server run their instructions without first needing a valid username or password. That can put website content, customer information, credentials and other systems connected to the server at risk.
The PHP team says all installations serving web requests should be treated as at risk. This includes common arrangements such as PHP FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team considers the demonstrated risk highest for mod_php because an attack can be triggered before the website application itself begins running.
Has this really affected 77 per cent of websites?
No evidence shows that 77 per cent of websites have been attacked or compromised. The figure refers to estimates of how widely PHP is used, not the number of sites known to be vulnerable or breached.
W3Techs currently reports that PHP is used by 69.3 per cent of websites where it can identify the server side programming language. Older reports often quoted a figure near 77 per cent. The current percentage is still enormous, which explains the urgency, but it must not be confused with confirmed impact.
A site that uses PHP may already be protected if its host has installed a fixed release or a verified vendor backport. A website that does not use PHP is not affected by these two PHP flaws. The first task is therefore to establish what the site actually runs and who is responsible for updating it.
Which PHP versions contain the fix?
The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anyone managing PHP directly should move to the appropriate fixed release without delay and test the website after the update.
PHP 8.1 and older no longer receive normal security releases from the PHP project. Some Linux distributions and long term support vendors may provide their own backported fixes. In that situation, check the vendor advisory and package status rather than relying only on the version number shown by the server.
PHP 8.2 reaches the end of its supported life on 31 December 2026. Updating an 8.2 system to 8.2.35 addresses these immediate flaws, but an upgrade plan to a supported branch is still required.
- PHP 8.5 users should update to 8.5.12 or later.
- PHP 8.4 users should update to 8.4.27 or later.
- PHP 8.3 users should update to 8.3.36 or later.
- PHP 8.2 users should update to 8.2.35 or later and plan their next upgrade.
- Users of older releases should obtain a confirmed vendor fix or move to a supported version.
WordPress updates are not the same as PHP updates
WordPress, Drupal, Joomla, Magento and many other content management systems commonly run on PHP. Updating the website application, theme and plugins remains important, but it does not necessarily update the PHP software installed on the hosting server.
On managed hosting, the hosting company may apply the PHP fix for you. On a virtual private server, dedicated server or internally managed web server, responsibility may sit with your organisation, developer or IT provider. Ask for written confirmation of the active PHP version or the relevant vendor backport and when it was installed.
Do not change a live website to a new major PHP branch without checking compatibility. Take a verified backup, confirm that it can be restored, update the staging or test environment first where possible, then check forms, payments, logins, scheduled tasks and integrations after the production update.
What website owners should do today
The National Cyber Security Centre advises organisations to identify every system running PHP, prioritise internet facing systems, monitor them for malicious activity, follow official guidance and install updates as soon as they are available. It also warns that appliances and services can contain bundled copies of PHP that are easy to overlook.
Use the checklist below even if another company manages the website. A clear written answer is better than assuming that an automatic update has happened.
- Contact the website host or developer and ask whether the service uses PHP.
- If it does, request the active PHP version and confirmation that the October 2026 fixes have been applied.
- Identify other internet facing systems that may bundle PHP, including portals, appliances and management tools.
- Create and verify a current backup before making changes, while keeping a clean earlier backup available.
- Review web server, security and account logs for unexpected activity, new administrator accounts or changed files.
- Check that the website, forms, payments, integrations and scheduled tasks still work after patching.
- Reset exposed credentials and begin incident response if there are signs that the server was compromised.
- Record who confirmed the update, when it was applied and which systems were checked.
Can a firewall or temporary setting remove the risk?
The PHP security team has published measures that may reduce exposure to particular attack paths, but it states clearly that there are no complete mitigations. Updating is the only safe choice.
A web application firewall can provide a useful extra layer and may block known attack patterns, but it should not be treated as a replacement for the PHP update. Attack methods can change, and some vulnerable processing happens before the website application begins running.
If a critical system cannot be updated promptly, the responsible technical team should assess whether access can be restricted or the service should be temporarily taken offline. That decision should be based on business impact, exposure, evidence of malicious activity and current vendor advice.
What if you use Wix, Shopify or another managed platform?
With a fully managed website platform, the provider normally controls the underlying server software and security updates. That does not automatically mean every service is affected or safe. Check the provider's official status or security notice and ask support if you need confirmation.
If your organisation only edits pages through a hosted website builder and has no access to PHP settings, do not install unofficial tools or make speculative changes. Confirm the position with the platform. Continue to protect administrator accounts with strong unique passwords and multifactor authentication because those controls remain important regardless of the PHP issue.
How Bury I.T. Support can help
Bury I.T. Support can help businesses and schools identify public systems, confirm who manages them and coordinate urgent checks with website developers and hosting providers. We can also review backups, administrator access, monitoring and the wider effect on connected systems.
A website fix should not stop at seeing a newer version number. If there is any sign of compromise, the priority is to preserve evidence, contain the affected service, protect credentials and establish whether customer, staff or pupil information may have been accessed.
If you are unsure whether a website, portal or server uses PHP, contact us with the website address and the details of your host or developer. We will help you establish what needs checking and who needs to take action.
Official sources and further reading
These primary sources were checked when this article was last reviewed.