The PHP Security Alert: What Website Owners Need to Check Now
Published
This week’s PHP security warnings have understandably raised concerns among business owners. When headlines describe serious vulnerabilities in software used by websites around the world, it is difficult to know what that means for your own.
Security fixes were released on 21 October 2026. These updates, often called patches, fix weaknesses in the software. The immediate priority is to confirm that the PHP software running your website has received the relevant update. The next question is what checks have been undertaken to establish whether someone used those weaknesses before the fix was applied.
You do not need to become a server engineer to ask these questions. You do need clear answers from the people responsible for your website and hosting.
In our recent articles, The Website Ownership Gap: Responsibility Without Understanding and Website Maintenance Is More Than WordPress Updates, we explored the responsibilities that can fall between website owners and their providers.
This week has brought those discussions into sharp focus.
The patch is not enough
Being told that your website is running a patched PHP version is useful and important.
Being told that this alone means “no further action is required” is shortsighted.
The patch fixes the vulnerability. It does not remove malicious code, unauthorised accounts or other access an attacker may already have established. It also does not tell you whether information was accessed before the update.
Think of repairing a faulty lock. You have addressed the weakness in the lock, but that repair cannot tell you whether somebody entered beforehand or what they did while inside.
There are two separate questions to answer:
- Has the vulnerability been fixed?
- What has been done to check whether someone used it to gain unauthorised access?
Asking the second question does not mean your website has been hacked. It means you are establishing its position rather than assuming that applying an update answers everything.
What has happened, in plain English?
PHP is software that runs behind the scenes on a web server, the computer that hosts your website. Websites built with WordPress, along with many other systems, use it to process requests and generate the pages people see.
Two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, could allow an attacker to run unauthorised code without logging in. PHP released fixes on 21 October in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Details are available in the official PHP security advisory.
Your host may use an update supplied by its hosting software provider that includes the same security fixes. Confirmation should therefore address these vulnerabilities specifically, rather than rely entirely on the version number displayed in a dashboard.
This is not simply a warning about neglected websites. A website that was running current software before this release still needs the new security fix.
Updating WordPress, themes and plugins does not apply the underlying PHP server update. That work needs to be handled by whoever manages the relevant hosting software.
Does this mean my website has been hacked?
Not necessarily. A vulnerability is a weakness that could be used by an attacker. Its presence does not establish that anyone successfully used it against your website.
Equally, a website looking normal cannot establish that nothing happened.
Pages may load, orders may arrive and the WordPress dashboard may appear unchanged while unauthorised activity remains hidden. Relevant technical checks are needed to assess what has happened.
If you already have warning signs, such as an unexplained administrator account, visitors being sent to unexpected websites or suspicious changes, contact your hosting provider and website manager urgently. The section below on suspected compromise explains the priorities.
Confirm that your website has received the fix
Contact your hosting provider or server manager for confirmation that both vulnerabilities have been addressed.
“We are aware of the issue” does not confirm that the work is complete. Neither does “our servers update automatically”.
The confirmation needs to relate to the PHP software actually running your website. Include other websites, separate test copies and subdomains, such as shop.example.co.uk, which may use different software or settings from your main site.
If you have previously been advised that your PHP version is outdated, raise that now. Some providers supply security fixes for older versions, but you need specific confirmation that these vulnerabilities are covered and a plan for ongoing support.
If the update remains outstanding, ask what immediate protective measures are in place and when the full fix will be applied. PHP warns that temporary measures do not provide a complete solution.
Who can check whether a compromise occurred?
A compromise means that someone has gained unauthorised access or made unauthorised changes. Checking for it requires someone with appropriate technical expertise and access to the relevant website and server.
They should assess whether your website was exposed to the vulnerabilities and determine what checks are appropriate. Not every website requires a full forensic investigation. The extent of the work should reflect the hosting arrangement, the period of exposure, the available evidence and any warning signs.
Checks may include examining records of activity, unexpected file changes, accounts, access routes and the website’s database, where content and other information are stored.
A person with WordPress access alone cannot assess the complete server environment. A check of the website’s public pages cannot do that either.
The findings should explain what was examined, what was found, which period the available records cover and anything that could not be checked.
Those limitations matter. Finding no evidence of compromise is useful, but it may not prove that nothing happened, particularly if older activity records are unavailable. Your provider should explain what its findings allow it to conclude and whether further work is needed.
The National Cyber Security Centre’s guidance on these PHP vulnerabilities includes checking potentially affected systems for evidence of compromise and hidden ways for attackers to regain access where immediate updating or disabling was not possible.
What if your website uses shared hosting?
On shared hosting, several customers use the same underlying server. Customers will usually have access to their own account, with limited visibility of the wider system.
That gives your hosting provider an essential role. You cannot independently inspect parts of a server that you have no permission to access.
Establish what the host has investigated, how customer accounts are separated and what remains for your website manager to check within your own website.
Sharing a server does not itself mean that another customer’s compromise has affected you. The provider needs to assess the actual arrangement and evidence.
With inexpensive hosting, incident investigation or recovery support may be limited or separately chargeable. Find out what your package includes and who can undertake work beyond it. Price alone does not establish whether hosting is secure, but the support available during an incident matters.
What if the answer only confirms the PHP version?
If the reply addresses the update but leaves the investigation unanswered, follow up:
“Thank you for confirming the update. Please could you also confirm what checks have been undertaken to establish whether either vulnerability was used to gain unauthorised access, what those checks covered and whether anything remains outstanding?”
The provider may have completed checks but omitted the details. Give them the opportunity to explain.
If they cannot answer, request escalation to their technical or security team. Where adequate investigation is unavailable, independent specialist advice may be needed.
Moving to another hosting company is not, by itself, a remedy. Copying a compromised website can transfer malicious files or hidden access into the new system.
Questions to send your hosting provider
You can use this checklist to establish where you stand:
- Have both CVE-2026-109618 and CVE-2026-109619 been addressed in the PHP software running our website?
- When did the fix become active?
- Does that confirmation cover our other websites, subdomains and separate test copies?
- What checks have been undertaken for evidence of unauthorised access or changes, and what were the findings?
- Did those checks cover the underlying server, our website files and database, or only some of those areas?
- Which period do the available activity records cover, and are there gaps that limit the findings?
- On shared hosting, have possible effects between customer accounts been assessed?
- What remains unchecked or unresolved, who will address it and when?
What should you do if compromise is suspected?
Contact your hosting provider or server manager and your website manager urgently. Make clear that you are reporting a suspected security incident.
The technical team should assess whether the affected website or services need isolating or restricting to protect visitors, information and connected systems. The NCSC advises considering taking systems offline where updates or temporary protective measures cannot be applied promptly.
Avoid trying to clean things up yourself. Deleting a suspicious file, restoring yesterday’s backup or removing an unfamiliar account may alter evidence without resolving the underlying problem.
Ask the team to preserve relevant activity records, files and database evidence while taking urgent steps to prevent further harm. Existing backups also need protecting so that potentially useful recovery copies are not lost or overwritten.
The investigation should establish how access was obtained, what was affected and whether other unauthorised access remains. Securing accounts and changing credentials should form part of a coordinated response. Changing a WordPress password alone does not address every possible route into the system.
Keep a simple timeline of discoveries, provider responses, findings and actions. This helps everyone work from the same information.
Recovery and reporting
Recovery needs a source that can be trusted. A recent backup may already contain the compromise, particularly if it remained undetected for some time.
The people handling recovery should assess the available backups, close the route the attacker used to get in, remove remaining unauthorised access and check the system before normal service resumes.
Reporting obligations need assessing alongside the technical response. They should not wait until recovery is complete.
Establish whether personal information or payment systems may have been affected. Involve the relevant payment provider promptly where appropriate.
Not every website security incident requires notification to the Information Commissioner’s Office (ICO), the UK’s data protection regulator. Assess the circumstances using its guidance and breach-reporting self-assessment.
Where notification is required, it must be made without undue delay and, where feasible, within 72 hours of becoming aware of the personal data breach. Information can be supplied in stages; a complete investigation does not need to precede an initial report. Where a breach is likely to create a high risk to people’s rights and freedoms, those affected must also be informed without undue delay.
Record the assessment and reasoning, including where a decision is made not to report.
Check that the website still does its job
After the update, or following safe recovery where an incident occurred, confirm that the functions your business and customers depend on still work.
Submit an enquiry and check that it reaches the correct inbox. Test bookings, account access and purchases where relevant, coordinating those checks with the people managing the technical work.
A website being available is only part of the picture. It also needs to deliver the outcomes it exists to provide.
The Last Word
Website owners should not need to inspect server records or recognise malicious code themselves. They do need to know who is responsible for the work, understand the findings and ensure that outstanding actions have an owner.
Your providers have responsibilities within their work too. Where several companies are involved, establish where each role begins and ends so that important checks do not fall between them.
Keep their confirmations and findings together, ask for explanations you understand and follow through on anything unresolved. That gives you a documented basis for decisions about the website your business relies on.
Part of the Marketing Clarity Series
This article builds on the Marketing Clarity series from The Last Hurdle, exploring the thinking behind clearer, more effective marketing.
A website’s contribution to your business depends on more than its appearance or visibility. Clear technical responsibility, reliable customer journeys and informed decisions about its upkeep all help protect the work your marketing is doing.
