The recent PHP security headlines have understandably raised questions for businesses. If your website or business platform uses PHP, the important thing is to establish whether the fix has been applied to the system actually serving your application.
What has happened?
On 21 October 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. These can allow an attacker to execute code remotely without logging in. The issues concern PHP’s handling of memory and request state; they are not simply defects in a particular website plugin.
The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP advisory covers installations serving web requests, including PHP-FPM, Apache, CGI, FrankenPHP and LiteSpeed. This is therefore something to check with your hosting provider or development team, even if your website appears to be working normally.
1. Confirm which systems use PHP
Start with your public websites, but do not stop there. Customer portals, internal tools and third-party products may also include PHP. The UK’s National Cyber Security Centre recommends identifying PHP across your infrastructure and prioritising exposed systems for updates.
Give someone responsibility for maintaining that inventory. Knowing who hosts each system and who can update it saves valuable time when an urgent advisory appears.
2. Check the running version, not just the installed version
A server can have several PHP versions installed. Ask your provider to confirm that each affected site is using a patched runtime, and that the relevant services have been restarted or reloaded as required.
Linux vendors sometimes backport security fixes without changing the headline version to match an upstream release. In that situation, ask for confirmation of the vendor package and security advisory. A version number on its own may not tell the whole story.
Applications running in containers need attention too. Updating PHP on the host does not automatically update a container image: your team should rebuild and redeploy against a patched base image, then verify the running application.
3. Treat patching as the priority
The PHP project states that updating is the only complete solution. Temporary measures reduce particular exposure paths; they do not make an unpatched installation safe. If an immediate update is not possible, involve your technical provider in assessing the risk and the appropriate next steps.
The NCSC advises considering taking a system offline where updates or suitable temporary measures cannot be applied promptly. If compromise is suspected, seek incident-response assistance: installing a patch alone will not remove an attacker’s existing access.
4. Keep the rest of the system maintained
Use this as a prompt to review your wider maintenance routine. Keep WordPress, plugins, themes and application dependencies supported and updated. Remove components you no longer use. Test important journeys after changes, including logins, enquiries, payments and integrations.
Backups should be separate from the live system, and restoration should be tested. A backup is far more useful when you know who can restore it and how long recovery is likely to take.
5. Make security an ongoing responsibility
Restrict administrative access, use strong unique passwords and enable multi-factor authentication where available. Agree who monitors security notices, applies updates and investigates unusual behaviour. Maintenance should have an owner and a budget, rather than waiting until something breaks.
At SoftwareBox, we believe ongoing care belongs in the conversation about any business system. If you need to discuss an existing platform or a future software project, get in touch.
Information checked on 23 October 2026. Security advice and fixed releases may change; consult the current official guidance.