If the recent PHP vulnerability has achieved anything positive, it is this: it has finally got organisations talking seriously about cyber security. The issue itself matters, but the bigger story is that many businesses still lack visibility of the systems they rely on, the vulnerabilities they carry, and how quickly they could respond when something goes wrong.
For years, critical technology has quietly powered our websites, applications and digital services behind the scenes. Most of the time, nobody notices. Then an incident happens, systems become unavailable, and suddenly the real-world consequences of IT become impossible to ignore.
We saw this during high-profile infrastructure outages that affected banking services, vehicle MOT validations and other essential services. Small technical failures can have a very real impact on people’s lives. The same principle applies to cyber security vulnerabilities.
What appears to be a technical vulnerability can rapidly become a business continuity issue, affecting customers, revenue, operations and organisational reputation.
The recent PHP vulnerability is simply the latest example.
What Actually Happened?
On 21st October 2026, two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed in PHP. Both can, under certain conditions, result in unauthenticated remote code execution, potentially allowing an attacker to execute commands on an affected web server without valid credentials.
The vulnerabilities affect PHP installations serving web requests, which is why internet-facing systems were immediately prioritised for remediation.
This wasn’t simply a theoretical vulnerability. Within days of disclosure, the vulnerabilities had been added to the US Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities catalog, highlighting the urgency of identifying and remediating exposed systems.
What Is PHP and Why Does It Matter?
PHP (PHP: Hypertext Preprocessor) is an open-source programming language used to power websites and web applications. Originally developed in the 1990s, it remains one of the most widely used technologies on the internet today.
It underpins platforms such as WordPress and Drupal, supports countless e-commerce websites, and sits behind many custom business applications.
That means vulnerabilities affecting PHP have the potential to impact organisations of every size and sector.
Recent reports of the “PHP2Shell” vulnerability prompted some organisations to take websites offline as a precaution while they assessed potential exposure. The discovery also highlighted the growing role AI is playing in cyber security, helping researchers identify weaknesses that might otherwise remain hidden for years.
The National Cyber Security Centre (NCSC) has advised organisations to identify affected PHP installations, prioritise internet-facing systems, apply security updates and monitor for signs of malicious activity.
Why This Vulnerability Should Concern Every Organisation
The immediate reaction from some organisations may be: “We don’t use PHP.”
The reality is that many businesses have little visibility of all the technologies operating within their environment. Websites managed by third parties, legacy business systems, customer portals, supplier applications and cloud-hosted services frequently contain technologies that internal teams may not fully control or understand.
Even if your organisation doesn’t directly manage PHP servers, a supplier might. This is why cyber resilience starts with visibility.
You cannot protect assets you don’t know exist.
But knowing that an asset exists isn’t enough. You also need to know who owns the risk.
Take a company website, for example. The domain may belong to the business, DNS may be managed by its IT provider, hosting may sit with another company, and the website itself may be maintained by a digital agency. If a critical vulnerability appears in one part of that chain, determining who is responsible for identifying and remediating the issue can quickly become a challenge.
Key question: Which suppliers hold responsibility for the technology your business depends upon, and how quickly can they tell you whether they are affected?
For many organisations, answering that question quickly can be the difference between a controlled response and a prolonged security incident.
How Nexus Responded to the PHP Vulnerability
For Nexus, this wasn’t simply another vulnerability alert to circulate.
Following the NCSC warning, our technical team began reviewing potential exposure across our managed customer estate. That included checking internet-facing customer domains and developing an RMM detection component to identify PHP running through IIS on managed devices.
Where potential exposure was identified, customers were contacted so that the appropriate hosting provider, software vendor or responsible party could investigate and remediate it.
The exercise highlighted an important point: finding vulnerable technology isn’t always straightforward.
PHP may sit within a website managed by an external agency, an internally hosted application or a third-party product. Responsibility for patching therefore doesn’t necessarily sit with the organisation’s internal IT team or its managed service provider.
That is why maintaining an asset list is only part of the answer. Organisations also need to understand dependencies and ownership: what technology supports each critical service, who maintains it, who is responsible for security updates and who needs to act when a vulnerability is announced.
Five Cyber Security Lessons from the PHP Vulnerability
1. Know What Your Business Relies On
Many organisations discover dependencies only when something breaks.
Understanding the applications, websites, suppliers and technologies supporting your business should be a fundamental cyber security requirement.
2. Make Responsibility Clear
Who applies security patches? Your internal IT team? A web development agency? A hosting provider?
The answer should never be unclear during a security incident.
3. Verify That Updates Have Actually Happened
Automated patching is important, but it is not enough.
Updates fail. Devices go offline. Systems stop reporting. Some patches require reboots before they become effective.
Effective patch management means validating outcomes, not simply assuming success.
4. Plan for Outages
If a critical system becomes unavailable tomorrow, can customers still place orders, contact your business or access information?
Cyber resilience requires operational resilience.
5. Patching Isn’t the End of the Job
Applying a security update closes a vulnerability. It does not confirm whether an attacker has already gained access.
In some situations, organisations may need additional investigation and monitoring after patching is complete.
A robust vulnerability-management process should be able to answer four questions:
- Discovery: Where does the vulnerable technology exist?
- Prioritisation: Which instances present the greatest exposure or business risk?
- Remediation: Has the appropriate patch, upgrade or mitigation been applied?
- Verification: Can we demonstrate that the vulnerability is no longer present?
The PHP incident is a useful example because the NCSC specifically recommends prioritising internet-facing systems, monitoring third-party software that bundles PHP and assessing unpatched systems for evidence of compromise rather than considering patching alone to be the complete response.
Patching Can Expose a Bigger Problem:
Technical Debt
There is another lesson hidden in incidents like this.
Sometimes the answer isn’t simply “apply the patch”. The affected technology may already be outside its supported lifecycle.
In this case, PHP 8.1 and earlier releases are end-of-life. Organisations running them therefore face a broader problem than one vulnerability: they are relying on technology that no longer receives normal upstream security support.
Key Question: How much unsupported or ageing technology exists within our environment, and what is the plan for replacing it?
Cyber resilience is about more than fixing today’s vulnerability. Organisations need to understand and manage the wider risks within their technology environment.
We Already Have Cyber Security Controls in Place. What Should We Review After a Critical Vulnerability?
The PHP vulnerability is unlikely to expose organisations simply because they lack security tools. More often, incidents arise because of gaps in visibility, patching, monitoring or ownership.
For many organisations, the key questions are:
- Do we have visibility of all internet-facing assets and applications?
- Can we quickly identify where vulnerable software is running?
- Are security updates being applied consistently across infrastructure and applications?
- Are vulnerability scanning and penetration testing identifying genuine risks and driving remediation?
- If a vulnerability is exploited before a patch is applied, would we detect it?
This is why cyber resilience relies on multiple layers of protection. Vulnerability scanning helps identify weaknesses before attackers do. Effective patch management ensures updates are successfully applied. Regular penetration testing validates whether controls are working as intended.
Continuous monitoring also plays a critical role. As we discuss in our guide to What is a Managed SOC?, attacks do not occur solely during business hours. A Managed SOC (Security Operations Centre) provides 24/7 monitoring, threat detection and incident response, helping organisations identify suspicious behaviour and respond quickly when threats emerge.
No security solution can prevent every vulnerability. However, organisations with strong visibility, effective patching processes, regular testing and continuous monitoring are typically far better positioned to detect and contain threats before they become significant business issues.
What the PHP Vulnerability Teaches Us About Cyber Resilience
The PHP vulnerability will eventually disappear from the headlines. Another vulnerability will replace it tomorrow, and another one the day after.
Security patches are released every day for the technologies that underpin the services we all depend on.
PHP is simply the latest reminder that cyber security cannot be treated as an occasional project or a one-off investment.
The real takeaway is not that PHP needs patching. It is that thousands of other vulnerabilities also need identifying, prioritising and remediating across the systems that support our organisations, supply chains and wider economy.
Cyber resilience is not built on reacting to headlines. It is built on continuous visibility, effective vulnerability scanning, robust patch management, regular penetration testing and ongoing monitoring through services such as a Managed SOC.
Could Your Organisation Answer These Five Questions Today?
- What internet-facing systems do we operate?
- What software and third-party technologies are they dependent upon?
- Who owns patching and remediation for each one?
- Can we verify that critical patches have actually been deployed?
- Would we detect suspicious activity if exploitation occurred before remediation?
If any of those questions are difficult to answer, the issue isn’t necessarily a lack of security products. It may be a gap in cyber governance, visibility or operational ownership.
If you’re reviewing your current cyber security posture, get in touch with the Nexus team. We’ll be happy to answer your questions and aim to respond within one business day.
Related reading: 10 Ways to Strengthen Data Security This Cyber Security Month.