Can't patch?
Can't patch PHP yet? Do not leave it exposed
Sometimes a vulnerable system cannot be updated quickly. When that happens, it should not stay reachable from the internet without the mitigating controls below in place. If the business then decides to carry the risk, accept it properly.
Last reviewed against the NCSC's and CISA's PHP alerts and php.net's advisory.
Mitigating controls
Six controls before a vulnerable system stays online
Do not keep a portal or system externally exposed on a vulnerable PHP build without these. None of them fixes PHP2Shell. Together, they make an attack harder to land, faster to spot and less damaging if it succeeds.
Already have some of them? The risk calculator scores your site with the controls you have, and shows which are missing.
-
Control 1
Quantify the effort and investment
A decision not to patch is often made on a feeling that it is too hard. Put figures on it: engineering and testing time, any code or platform changes the update forces, hosting or licence costs, and the downtime the change needs.
Set those figures against what a breach of the same system would cost. Without them, the board cannot judge whether patching really is too expensive or too slow, and an unquantified "too hard" has a way of becoming permanent.
A fractional CISO can build the case with you -
Control 2
Network segregation, isolation and a WAF
Isolate the infrastructure from the wider network and from other internal systems, so a compromised web server cannot be used as a stepping stone. Limit inbound and outbound connections to the ones the application needs. A web server rarely needs to open connections to the internet, and blocking them makes it much harder to download attack tools or send data out.
Depending on how the application is built and hosted, put a web application firewall (WAF) in front of it, such as Cloudflare's or the one your hosting provider offers. CISA notes that a WAF may give some protection until the server is patched. Run it in blocking mode, confirm with the provider that its rules cover CVE-2026-109618 and CVE-2026-109619, and treat it as one layer, not the fix.
Our consultants can put the WAF and segmentation in place -
Control 3
Review admin access to the back end
Review the administrative and service accounts on the server, the application and the databases behind it. Remove accounts nobody uses, cut every permission back to what the role needs, and make sure no shared or default credentials remain.
Least privilege limits how far an attacker can move if they get a foothold on the back end. Include the account PHP itself runs as: it should not be able to change its own code or reach systems it has no reason to touch.
We can run the access review -
Control 4
Enhanced security monitoring
Check what your SIEM can actually see of this system: which log sources reach it and which live detection rules apply. Make sure server activity, authentication attempts, unusual processes and new network connections are all covered.
CISA's alert points to PHP worker processes starting shells or downloading tools as a sign of exploitation. An alert like that needs someone to act on it at any hour, because attacks do not keep office hours.
Our SOC can monitor the server around the clock -
Control 5
Protect customer data
Heavily restrict data export from the databases connected to the system, so that if someone gains unauthorised access, the data cannot be taken out in bulk.
Give the application a database account that can only do what the site needs, switch off bulk export features, filter outbound traffic from the database hosts, and alert on unusually large queries or transfers. Encrypting the most sensitive fields means a copied table is of little use.
We can design the data controls with you -
Control 6
Application penetration testing
Once controls 2 to 5 are in place, commission a focused application penetration test to check they work: that the WAF blocks what it should, that segmentation holds, that monitoring raises the alerts you expect and that data cannot be pulled out.
A control nobody has tested is an assumption. The test turns it into evidence the board can rely on.
Book an application penetration test
Alongside the controls
Three quick steps that still apply
Apply the interim settings
php.net lists configuration changes that reduce the risk until you update. They are partial, and the PHP project says so, but they cost little.
The interim settingsRestrict who can reach it
An IP allowlist or a login in front of the site stops anonymous requests reaching PHP, which both flaws rely on.
Restricting access in practiceCheck it has not already been hit
Both flaws are being exploited. A system that has been exposed on a vulnerable build should be checked before you build controls around it.
Signs of compromiseRisk accept?
Accepting the risk, properly
If patching the system is prohibitively expensive or slow, you may be encouraged internally to accept the risk instead. That can be a legitimate decision, but only if it is made properly. Our advice is that a valid risk acceptance has three elements.
1
An executive owner
Someone who sits on the board, or a company director, who takes on the risk personally. Not the IT manager and not a committee. The owner should understand what the system holds, what the vulnerability allows and what the controls do, and sign the acceptance in their own name.
2
A time limit
Every acceptance needs an expiry date; it cannot be indefinite. Set it to match the plan for removing the risk, such as the date a replacement goes live. When it expires the risk goes back to the owner for a fresh decision, not an automatic renewal.
3
Recorded conditions
Write down the conditions the acceptance rests on, for example "we are decommissioning this system in three months anyway" or "the WAF and monitoring stay in place". If any condition changes, that triggers a review of the acceptance.
What to write down
- The system, what it does and what data it holds.
- The vulnerabilities (CVE-2026-109618 and CVE-2026-109619), and that CISA lists both as exploited.
- Why patching is not possible yet, with the effort and cost figures behind that.
- The mitigating controls in place, and who keeps each one running.
- The risk that remains with those controls in place.
- The executive owner, the expiry date and the conditions.
Review it early if
- A new advisory or exploit for these flaws, or for PHP on the same branch.
- A change to the system, the data it holds or who can reach it.
- A mitigating control failing, being switched off or not being renewed.
- Any sign the system has been probed or compromised.
Accepting a risk does not stop an attack. The mitigating controls still need to be in place, and the system still needs checking for signs of compromise.
A fractional CISO can advise the board on the decisionHow CyPro can help
We can put these controls in place with you
From the WAF and segmentation to round-the-clock monitoring, the penetration test that proves it all works and the board conversation about accepting what is left, CyPro can do the work or guide your team through it.
WAF and network hardening
Our consultants put a web application firewall in front of the site, isolate the server from the rest of your network and lock down admin access and data export.
More on cypro.co.uk
24/7 security monitoring
Our SOC analysts watch your servers day and night for the signs of exploitation: PHP workers starting shells, new outbound connections, logins that do not fit.
More on cypro.co.uk
Application penetration testing
A focused test of the site and the controls around it, so you know the firewall, segmentation and monitoring hold before an attacker finds out for you.
More on cypro.co.uk
Fractional CISO for the board
A senior security lead who advises the board on whether to patch, mitigate or accept the risk, puts numbers on each option and owns the decision record.
More on cypro.co.uk
Incident response
If a site may already be compromised, our responders contain it, preserve the evidence, find out what was touched and get you back online safely.
More on cypro.co.uk
Vulnerability scanning
Find every internet-facing PHP server you run, including the forgotten ones, and see which are still on a vulnerable build.
See the PHP exposure scanQuick answers
When you cannot patch: questions, answered
Can I protect a PHP site without updating it?
Partly, and only for a while. php.net says there are no complete mitigations. Its interim settings, a WAF and restricted access all reduce the chance of a successful attack, and the controls on this page limit the damage if one gets through. The lasting fix is a supported PHP version with the fix in it.
Is a web application firewall enough on its own?
No. A WAF blocks the request patterns its rules recognise, and attackers adapt their requests to get past them. Use it as one layer alongside segmentation, monitoring and data controls, and confirm its rules cover these two CVEs.
Who should sign a risk acceptance?
A board member or company director who takes on the risk personally. Someone more junior can prepare it, but the person accepting the risk needs the authority to decide the business can carry it.
How long should a risk acceptance last?
Only as long as the plan to remove the risk needs, and never open-ended. Give it a fixed expiry date, and review it straight away if any of the conditions it rests on change.
Can't patch?
Get the controls in place before someone finds the gap
Tell us about the system you cannot update yet. We will tell you which controls matter most for it, and can put them in place with you.