If this week's PHP security headlines have left you wondering whether your website is safe, you're probably ready for a clear answer. You might have received an update from your hosting provider, or you might still be waiting for someone to explain what happens next.
I think the most useful next step is to ask specific questions. You shouldn't need to understand server configuration to find out whether the people maintaining your website have addressed a critical security issue.
These are the five questions I'd start with, along with what I'd want each answer to tell me.
Security information checked October 23, 2026.
- Have you applied the PHP security fixes to the server running my website?
Start with the work that needs to be confirmed.
The PHP team released updates on October 21 addressing CVE-2026-109618 and CVE-2026-109619, the two critical vulnerabilities commonly called PHP2Shell. They can potentially allow attackers to run code without logging in. [1]
Ask your provider:
Can you confirm that the PHP installation serving my website has received the fixes for both vulnerabilities, and when they were applied?
A useful answer should identify your website's environment, confirm its patch status and give you a completion date.
The announced fixed releases were PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some vendors provide backported fixes, so ask for confirmation of the actual security update rather than judging by the version number alone. [1]
I'd follow up on an answer like “your account is protected” or “all WordPress plugins are updated.” Neither tells you whether the relevant PHP fixes have been installed.
If patching is still pending, ask what exposure remains, what interim measures are in place and who is responsible for completing the update. PHP warns that temporary mitigations don't make an unpatched installation safe. [1]
- Have you checked the latest follow-up guidance?
An update confirmation is useful. Knowing that someone is still watching the issue is useful too.
On October 23, PHP published follow-up guidance about session upload progress and an unusual configuration-dependent attack path. [1] That's a practical example of why the first announcement shouldn't be the last thing your technical provider reads.
Ask:
Have you reviewed the latest PHP advisories, and does our website need any additional configuration changes or updates?
A useful answer should tell you which guidance was reviewed, whether it applies and what action was taken.
I wouldn't expect a business owner to change server settings based on a paragraph in a blog. The person managing the environment should assess the recommendation and explain the result.
If no additional action is needed, that's a reasonable answer when it comes with a clear explanation. What I'd want to avoid is everyone assuming that someone else is checking.
Keep the response with the date. That gives you a reference if further guidance appears.
- Have you checked whether my website shows signs of compromise?
Patching and investigating answer different questions.
The first asks whether a weakness has been addressed. The second asks whether anything suspicious happened while the website was exposed.
Ask:
Have you reviewed our environment for signs of compromise, what did that review cover, and is any further investigation needed?
A useful answer should explain the scope of the checks, their findings and their limitations.
The National Cyber Security Centre recommends assessing for evidence of compromise and attacker backdoors where systems couldn't be updated or disabled promptly. It also recommends specialist assistance when an organisation can't confidently perform that assessment itself. [2]
I'd want to understand whether the provider reviewed the hosting environment, the website application or both. If application-level investigation falls outside your hosting plan, ask who can take that part on.
Be careful with an absolute reassurance based on a limited check. “We found no suspicious activity in the logs we reviewed” tells you something specific. “There is no possibility of a breach” needs much stronger evidence.
If suspicious activity is found, have the technical team explain the investigation and recovery steps. Avoid making uncoordinated changes that could complicate their work.
- What backups could we restore if something went wrong?
“We take backups” is a starting point. I'd want to know what recovery would actually involve.
Ask:
What website backups are available, what do they contain, and when was the restore process last tested?
A useful answer should cover backup frequency, retention, storage protection and the practical restoration process.
The NCSC advises checking that backups contain the important data you need and knowing how to restore them. [3]
For a business website, I'd ask whether the backup includes both the website files and its database. I'd also ask who can access or delete the backups, and whether a server compromise could affect those copies.
Then think about the business consequences. If you restored yesterday's copy, what would happen to today's orders, bookings or enquiries? Which records also exist in your CRM, inbox or another system?
If a compromise is suspected, ask how the team would choose a suitable recovery point and address the weakness before bringing the restored site back into use.
You want an answer that helps you plan for recovery, including any likely gaps or extra costs.
- Who handles future security alerts, and how will you notify me?
This is the question I'd use to turn an urgent conversation into a better maintenance arrangement.
Ask:
Who monitors security alerts, who applies server and website updates, and how will you contact us when action or downtime is required?
A useful answer should assign responsibilities and explain the escalation process.
Your hosting provider, developer and marketing team may each have a role. Ask them to confirm the boundaries in writing, especially if your hosting plan covers server maintenance but your developer manages WordPress, plugins and custom code.
I'd also agree on who tests the website after technical work. From a marketing perspective, that means checking the actions customers need to complete:
- Can visitors open the main landing pages?
- Do enquiries reach the right inbox or CRM?
- Do bookings or checkout work where relevant?
- Does conversion tracking record the intended actions?
Imagine your ads are still sending visitors to a booking page while a technical change has broken the booking form. The campaign report might show clicks, but the business has lost the opportunity to receive those enquiries.
Someone needs to own that final check.
Get answers you can act on
You don't need to become a PHP expert to ask for clear confirmation. Start with the patch status, then work through follow-up guidance, investigation, recovery and ongoing responsibility. If an answer is vague, ask what has been checked and what still needs doing.
If you'd like help reviewing your website after the technical work, book a consultation with me. We can check your landing pages, enquiry forms and conversion tracking, and coordinate with your hosting provider or developer on the fixes your customer journey needs.
Sources