Critical PHP Vulnerabilities: Patching Is Urgent, But Do You Know Everywhere You’re Affected?
Friday 23rd October 2026
A critical vulnerability is disclosed. A patch becomes available. The obvious next step is to deploy it.
But what happens when you are not completely certain where the affected technology is running?
The National Cyber Security Centre (NCSC) is urging UK organisations to take immediate action following the disclosure of two critical vulnerabilities affecting PHP: CVE-2026-109618 and CVE-2026-109619.
Under certain conditions, the vulnerabilities could result in unauthenticated remote code execution, potentially allowing an attacker to execute commands on an affected server.
A security update is available, but patching is only part of the challenge.
The bigger question is:
Can you confidently identify everywhere PHP is running and verify that the necessary action has been taken?
Why This Matters
PHP is not limited to traditional websites. It can also be incorporated into third-party applications, appliances and services, making affected systems harder to identify.
Organisations therefore need to look beyond the obvious web servers and consider PHP across their wider technology estate, prioritising internet-facing systems.
Security and IT teams should be able to answer three questions:
- Do we know where PHP is running?
- Have affected systems been patched or appropriately mitigated?
- Can we demonstrate that systems have not been missed or compromised?
This is not simply a patching issue. It tests the effectiveness of asset visibility, vulnerability management, remediation and security assurance.
What Should Organisations Do Now?
Organisations should:
- Identify systems running PHP, prioritising internet-facing infrastructure.
- Update affected systems to a fixed and supported PHP version.
- Check third-party products and services that may incorporate PHP and monitor vendors for updates.
- Apply recommended hardening or temporary mitigations where immediate patching is not possible.
- Consider taking systems offline where the risk cannot be adequately mitigated.
- Assess exposed systems for signs of compromise where appropriate.
The aim should not simply be to close a vulnerability ticket. It should be to establish confidence that affected systems have been identified, remediated and verified.
From Patching to Proof
Critical vulnerabilities create urgency, but remediation needs certainty as well as speed.
Knowing a patch exists is one thing. Being able to demonstrate that you have identified affected technology, completed remediation and checked for signs of compromise is another.
Strong vulnerability management, testing, assurance and detection capabilities help answer the more important question:
Are we confident the risk has actually been addressed?
How Bytes Can Help
When critical vulnerabilities emerge, organisations need clarity around four things:
What is affected?
What needs immediate attention?
What has been remediated?
Where is further investigation needed?
Bytes can support organisations with:
- Vulnerability management to identify affected assets and prioritise remediation.
- Testing and assurance to verify remediation has been effective.
- Detection and response where compromise or suspicious activity is suspected.
- Cloud security where PHP-based applications form part of wider cloud environments.
The starting point should be understanding your environment, your exposure and the evidence needed to demonstrate that the risk has been addressed.
A Patch Is Available. Make Sure the Risk Is Addressed.
For organisations using PHP, the priority is clear: understand where PHP exists, follow the latest NCSC and PHP guidance, apply the appropriate updates and verify your remediation.
Concerned about what these vulnerabilities could mean for your environment?
Read the full NCSC security advisory.
Want to keep informed? Sign up to our Newsletter