Vulnerability management
“Which known weaknesses can we identify?”
Frequent, repeatable and broad coverage. It is well suited to known vulnerabilities, unsupported software and remediation tracking.
Critical vulnerability management
PHP2Shell: Is the vulnerability hiding somewhere you cannot see?
A critical software vulnerability may be easy to patch when you know exactly where it exists. The bigger risk is the website, application, appliance or SaaS platform nobody realised depended on it.
The latest PHP security alert is a timely reminder that digital assets need active patching, independent verification and a tested route to recovery throughout their lifecycle.
Business service
Website · Customer portal · SaaS platform
What the business sees
CMSLayer 1
ApplicationLayer 2
FrameworkLayer 3
PHP runtime Vulnerability marker
Web serverLayer 5
Operating systemLayer 6
Hosting / cloudLayer 7
Third-party servicesLayer 8
The business sees the service. The attacker looks for the vulnerable layer underneath.
A critical reminder, not a one-day story
Most organisations know whether their website is working. Far fewer know exactly what technologies are running underneath it.
PHP2Shell is the label now used for two critical PHP security vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The UK National Cyber Security Centre, or NCSC, says the issue could allow an attacker to execute commands on a web server running PHP in affected circumstances. PHP is a widely used server-side runtime for websites and applications, and is also present in other products.
At the time of writing, PHP has released fixes in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The NCSC is urging UK organisations to identify PHP across their infrastructure, with particular attention to internet-facing systems, and to keep watching third-party vendor updates for appliances and services that may bundle PHP.
The most useful lesson is broader than one named flaw. Knowing your website is patched is not the same as knowing the technology stack underneath it is patched. A CMS update does not necessarily update the PHP runtime, web server, operating system or hosted dependencies that sit beneath it.
“If you’re not sure whether it is happening, it probably isn’t.”
Immediate action
Start by finding out whether you are exposed.
Contact the web developer, hosting provider, MSP and any application supplier responsible for systems that matter to the organisation. The aim is not to guess who owns the work. It is to establish the version, the responsible party, the expected completion time and the evidence that supports the answer.
Responsibility for PHP often sits with the hosting provider rather than the web developer. On managed hosting, the organisation that can update the runtime may not be the organisation that changes website content. That boundary needs to be explicit before a critical vulnerability appears.
Updating WordPress does not necessarily update PHP.
Eight immediate questions
- 1Does this system use PHP?
- 2Which version is running?
- 3Has it been updated to a fixed version?
- 4Who owns PHP patching?
- 5Are unsupported PHP versions present?
- 6Have logs been reviewed for suspicious activity?
- 7Are any third-party applications or appliances dependent on PHP?
- 8If patching is not complete, when will it be?
The hidden supply chain
What if the vulnerable technology is inside a service you do not control?
PHP may appear in hosted applications, customer portals, appliances, industry-specific software and third-party platforms. That does not mean every SaaS provider uses PHP. It means the customer may not know which technologies a supplier uses behind a service that supports an important process.
“The less technology you manage directly, the more important supplier assurance becomes.” A SaaS supplier should be able to identify affected components, patch them, investigate attempted exploitation, monitor for compromise and communicate with customers where appropriate. If a critical vulnerability appeared tomorrow inside one of your most important suppliers, how would you know whether the organisation was exposed?
Who actually owns the risk?
Outsourcing the technology does not outsource accountability.
A website can involve internal IT, marketing, a web developer, a hosting provider, a cloud provider, plugin developers and an MSP. Each may have a valid role. The risk appears when ownership is assumed rather than recorded. If every supplier assumes somebody else is patching it, nobody may actually be accountable.
Technology layer
Responsible supplier
Internal owner
Verification
CMS and plugins
Web developer
Marketing or digital owner
Vulnerability report and update confirmation
PHP and web server
Hosting provider or infrastructure team
IT service owner
Version, package and restart evidence
Operating system and database
Hosting provider, cloud team or MSP
IT service owner
Patch and scan results
Backups and monitoring
MSP, hosting provider or security partner
Risk or technology owner
Recovery and alerting test evidence
Patching is a process
A critical vulnerability should trigger an established response, not a discussion about who owns the server.
Regular patching should cover operating systems, CMS platforms, web servers, plugins, libraries, frameworks, network appliances, firewalls and business applications. Critical changes may also need testing, change control, a maintenance window, a backup, a rollback plan and service validation.
Speed and control are not opposites. A high-risk internet-facing service can demand an urgent change, while a sound process still establishes what will be changed, how it will be validated and who will own the customer impact. Patching is not complete until the organisation has confirmed the weakness has been removed and the service still operates normally.
The critical-change loop
Patch
Apply a confirmed fix or a documented risk reduction.
Validate
Confirm the relevant package, service and business function.
Monitor
Watch for unusual activity and the next security update.
Independent assurance
Do not rely entirely on the supplier responsible for maintaining the system.
Vulnerability management provides an independent view of known vulnerabilities, unsupported software, outdated services, exposed ports, weak encryption, misconfiguration and unexpected services. It helps turn an asset list into owned remediation work.
“The purpose of vulnerability management is not to replace the web developer. It is to independently verify that important weaknesses are not being missed.” The core cycle is Discover → Scan → Prioritise → Remediate → Verify. It is an operating discipline, not an annual report.
Discover
Scan
Prioritise
Remediate
Verify
Not every CVE is equal
Vulnerability severity is only part of the decision.
A critical vulnerability on an internet-facing customer portal is normally more urgent than the same theoretical vulnerability on an isolated test system. Active exploitation, available mitigation, data sensitivity, privilege level, external exposure and business dependency all affect the response.
The objective is not simply to patch the highest number first. It is to reduce the greatest real-world risk first.
A useful priority formula
Severity × Exploitability × Exposure × Asset criticality × Business impact
Use the formula to guide a clear, documented decision. It does not remove the need for experienced judgement and an accountable owner.
Scan and challenge
Vulnerability scanning and penetration testing answer different questions.
Penetration testing
“Can these weaknesses or relationships be used to achieve something they should not?”
Human-led analysis can challenge chained vulnerabilities, business-logic weaknesses, access-control failures and complex attack paths.
“The strongest approach is continuous vulnerability management plus periodic independent testing.”
When prevention fails
A secure system should also be recoverable.
No organisation can guarantee prevention. For critical assets, ask whether there is a current backup, tested restoration, failover option, protected configuration, isolation plan, rebuild path, DNS contingency and an alternative way to communicate. The same question applies when a critical SaaS supplier becomes unavailable.
“The question is not only whether we can prevent an incident. It is whether the organisation can continue operating and recover if prevention fails.”
Prevent
Reduce opportunities before the incident.
Detect
Recognise suspicious activity quickly.
Contain
Limit impact while facts are established.
Recover
Restore service through tested options.
Focus where failure hurts most
Not every technology asset deserves the same level of scrutiny.
Public websites, customer portals, CRM, finance systems, identity, email, firewalls, VPNs, APIs, cloud platforms and critical SaaS should be classified by revenue impact, customer impact, operational dependency, data sensitivity, regulatory exposure and recovery difficulty. The resulting criticality should determine the strength of monitoring, patch oversight, scanning, penetration testing, supplier assurance and resilience planning.
Senior leadership does not need to know every PHP version. It should be able to ask: “Are our critical digital assets actively managed for vulnerabilities, and can you show me the evidence?” Assurance should come from asset inventories, patch status, open risks, owners, remediation tracking, test findings, recovery tests and supplier assurance, not confidence alone.
The Proactive Digital Asset Security Lifecycle
Manage critical digital assets through their full lifecycle.
1
Discover
Know which systems, applications and suppliers exist.
2
Classify
Understand criticality, exposure and ownership.
3
Patch
Keep software current and within support.
4
Scan
Identify known weaknesses and unexpected services.
5
Test
Challenge important controls independently.
6
Prioritise
Focus action on real-world business risk.
7
Remediate
Patch, mitigate, replace or restrict.
8
Verify
Confirm that the weakness has been removed.
9
Monitor
Watch for suspicious activity and new disclosures.
10
Recover
Maintain tested recovery and continuity options.
Proactive: Discover → Classify → Patch → Scan → Test → Verify → Monitor → Recover
Reactive: Deploy → Assume → Wait → Respond
The Wavex approach
From reactive patching to continuous vulnerability management.
Wavex helps organisations discover internet-facing assets, continuously assess vulnerabilities, prioritise remediation, coordinate responsible suppliers, track action, test important controls and build resilience. That can include patch governance, penetration testing, security monitoring, incident management, recovery planning and executive reporting.
Wavex may identify a vulnerability even when another supplier owns the service. It can help establish the risk, contact the responsible party, track remediation, verify the result and escalate unresolved critical issues. It cannot directly patch a third-party SaaS provider’s infrastructure. “You should not have to rely on the supplier responsible for a system being the only organisation checking whether that system is secure.”
Related Wavex content
Build a more proactive security operating model.
Risk-led cybersecurity
Move beyond security product lists to a model that understands and owns real business risk.
Read the cybersecurity guideResilience beyond backup
Build business continuity through prevention, detection, response, recovery and improvement.
Read the resilience guideWebsite due diligence
Understand the technical and supplier questions that matter before investing in a website change.
Read the website checklistQuestions for your next review
Ten Questions to Ask About Your Critical Digital Assets
A useful conversation should lead to named owners, clear actions and evidence you can revisit, not only an assurance that somebody is looking after it.
- 1Do we have an inventory of all internet-facing systems?
- 2Who is responsible for patching each one?
- 3How quickly are critical vulnerabilities addressed?
- 4Which critical vulnerabilities are currently open?
- 5Are externally exposed systems vulnerability-scanned regularly?
- 6How is remediation independently verified?
- 7When was our last penetration test?
- 8Which SaaS suppliers support our most critical processes?
- 9Have recovery and restoration been tested?
- 10Can you show me the evidence that all of this is happening?
Frequently asked questions
PHP2Shell and vulnerability management questions.
Vulnerability management
Do you know which of your critical systems are vulnerable today?
Wavex helps organisations identify internet-facing assets, continuously assess vulnerabilities, prioritise remediation and build the resilience needed when prevention is not enough.
Discuss vulnerability management
Tell us which critical assets, suppliers or security concerns you would like to review. a sector specialist will be in touch. We aim to reply within 1 hour.