You check your website before a client meeting.
The homepage opens. The portfolio loads. You submit a test enquiry and receive the email.
Everything works.
Later, your hosting provider tells you an urgent security update is needed.
Your first reaction might be: “But I checked it this morning.”
You did. You checked what a visitor could see.
The recent PHP security emergency concerned something underneath it.
On 21 October 2026, PHP released updates addressing two critical vulnerabilities.
The PHP Foundation warned that, under certain conditions, attackers could execute code on affected servers without signing in.
PHP supports functions behind many websites and business applications. A weakness at that level may not change the appearance of a single page.
That is what makes the incident relevant to business owners: a working website is not proof of a maintained server.
What was updated?
Your content? The application? Its packages? The PHP installation on the server?
Each answer refers to a completely different layer.
A useful confirmation from your technical team should identify the affected software, the relevant fix, and whether it has been applied successfully.
You do not need to become a server administrator. You need an answer that goes beyond “all done.”
Here is a practical starting script you can copy and send today:
“Please confirm whether our website uses a PHP installation affected by the recent security advisory. If it does, confirm that the relevant patch has been applied, that important website functions have been checked afterwards, and who is responsible for future security updates.”
For a business-critical application, your technical team may need to provide more detail about its environment and remediation.
A small website can hold information that matters.
An enquiry form may collect names and phone numbers. A quotation portal may receive architectural drawings. A customer account may contain documents or billing transaction details.
Make a short inventory with your team:
| Audit Question | Why It Matters |
|---|---|
| What information do we collect? | Determines regulatory risk and client privacy obligations. |
| Where is it stored or sent? | Identifies database endpoints, third-party mailers, and webhooks. |
| Who has access? | Reveals dormant admin accounts and loose credential permissions. |
| Who maintains the application and hosting? | Clarifies whether the developer, host, or internal team owns patches. |
| Who checks that backups can be restored? | Backups that have never been tested offer zero disaster recovery guarantee. |
If nobody can answer, the problem is ownership as much as technology.
Custom development can give you full control over features, design, and workflows. The resulting system still depends on software that needs maintenance.
Laravel depends on PHP. Other application stacks have their own runtimes, packages, and infrastructure.
Every choice needs someone responsible for its upkeep.
Take these four straightforward actions:
- Get patch confirmation: Verify that the recent PHP update or vendor package is applied.
- Identify the maintenance owner: Clarify exactly who receives security bulletins and deploys fixes.
- Review handled data: Know what customer information travels through your forms and portals.
- Confirm update and recovery procedures: Verify that off-site backups run on schedule and can be cleanly restored.
These steps will not promise perfect security. They will give you a clearer picture of your website’s condition and responsibilities.
