PHP2Shell risk calculator
Should I take my website offline? A PHP risk calculator
If your site runs a vulnerable PHP version, can be reached from the internet and cannot be updated or mitigated soon, the NCSC's guidance is to consider taking it offline until it is fixed. Answer the questions below for a risk score out of 100 and to see which side of that line your site is on.
Last reviewed against php.net, the NCSC and CISA.
How the result is worked out
Four outcomes, from the NCSC's priority actions
The NCSC's alert sets out an order: update; if you cannot, apply the temporary mitigations; if you cannot do that either, consider taking the system offline. The calculator follows that order, adds CISA's line on PHP 8.1 and older, and moves a site to the stricter outcome when it holds personal data, takes payments, runs a customer portal or connects to other systems.
Your score out of 100
The score weighs what makes an attack more likely or more damaging against what makes it less so. Controls move it within each outcome but cannot override it: while the outcome is to restrict access or take the site offline, it stays at 60 or above, and a fixed version always scores Low.
| Category | Score |
|---|---|
| Critical | 80 to 100 |
| High | 60 to 79 |
| Medium | 30 to 59 |
| Low | 0 to 29 |
Pushes it up
- The site can be reached from the internet
- The branch gets no fixes from the PHP project
- The fix cannot be live soon
- Apache with mod_php
- Personal data, payments or a customer portal
- Connections to internal systems, revenue-critical operations or immature segmentation
Brings it down
- A fixed version going live today
- php.net's interim settings, applied
- A marketing site with nothing behind it
- Each mitigating control you have in place
Your version includes the fix
When: Your version is at or above the fixed release for its branch.
Then: Confirm the running PHP processes are the fixed build on every server, then check for signs of compromise if the site was exposed before you patched.
Patch today
When: You are affected and a fixed version can be live today, or the server is only reachable from inside your network.
Then: Update, restart PHP, confirm the live version.
Patch now, and apply the interim settings while you do
When: The update cannot land today, but you can apply php.net's interim settings and nothing you ticked about the site raises the stakes.
Then: Apply the settings now, schedule the update as an emergency change, and restrict access if it slips.
Restrict access or take the site offline until it is fixed
When: The site is public and either runs PHP 8.1 or older, or has no quick route to a fix and cannot be mitigated, or holds data, connects to other systems or matters to revenue in a way that raises the stakes.
Then: Limit who can reach it, or take it down, until a fixed and supported version is live.
Short of switching it off
What restricting access means in practice
Both flaws need an attacker to send requests to PHP without logging in. Anything that stops anonymous requests reaching PHP removes that route while you arrange the fix.
Allow only known addresses
Limit access at the firewall, load balancer or web server to the IP addresses of your own staff or office. Customers lose access, but the site keeps working for the people who maintain it.
Put the site behind a login
Basic authentication at the web server or a single sign-on gateway in front of the site stops anonymous requests from reaching PHP at all, which is the condition both flaws rely on.
Serve a static holding page
A plain HTML page served by the web server or your CDN, with PHP switched off behind it, keeps a public presence and a contact route without running vulnerable code.
Take the site offline
The cleanest option when none of the others fit. It stops new attacks, though it removes nothing an attacker may already have left on the server.
CISA also notes that a web application firewall may give some protection until the server is patched. Treat it like the interim settings: useful for days, not a reason to delay the update. If the update really is weeks away, put the full set of mitigating controls around the site.
If your host runs PHP
The questions to ask your hosting provider
On shared and managed hosting the provider patches PHP, but you usually choose which version your site uses. Ask three things:
- Which PHP version is my site running right now?
- Does it include the 21 October 2026 fixes for CVE-2026-109618 and CVE-2026-109619?
- If not, when will it, and can I switch my site to a fixed version myself today?
If you run the server
The interim settings, in short
Set session.upload_progress.enabled=0 in
php.ini or the PHP-FPM pool configuration, not with
ini_set(), and restart every PHP worker. On PHP 8.5,
also set fatal_error_backtraces=0. The PHP project
lists further partial measures on request and memory limits, and
is clear that updating is the only complete fix.
How CyPro can help
Help with whatever your result says
Patching is one job. Keeping a vulnerable system safe until it is patched, and proving it, is several more. CyPro's consultants, testers and SOC analysts can take any of them off your plate.
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
Taking a site offline: questions, answered
Should I take my website offline because of PHP2Shell?
Only if you cannot get it fixed or mitigated quickly. The NCSC's guidance is to update first; if you cannot, apply the temporary mitigations; and if you cannot do that, or it would take too long, consider taking the system offline until it can be fully mitigated. CISA goes further for unsupported versions: take systems running PHP 8.1 or earlier offline if they cannot be updated.
Is my PHP version vulnerable?
If it is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch, or on PHP 8.1 or older, yes. The exception is a distribution or vendor package, where the fix may be backported under an older-looking number; check your vendor's security tracker for CVE-2026-109618 and CVE-2026-109619.
Does this tool check my website?
No. It never contacts or probes any website, and nothing you enter leaves your browser unless you choose to send your result to us with an enquiry. Checking a site you do not own can itself cause problems, so the calculator works only from the answers you give.
If I take the site offline, am I safe?
You are safe from new attacks through that site while it is down, but taking it offline removes nothing already planted on the server. Both vulnerabilities are on CISA's Known Exploited Vulnerabilities catalogue, so check a previously exposed server for signs of compromise before you bring it back.
What does the risk score mean?
It is a guide to how urgent the problem is for this site, out of 100: Critical from 80, High from 60, Medium from 30 and Low below that. Being public, running an unsupported branch and holding valuable data push it up; a quick fix, the interim settings and mitigating controls bring it down. While the outcome is to restrict access or take the site offline, it stays at 60 or above.
Can I rely on the result?
Use it to structure the decision, not to make it for you. The outcomes follow the NCSC's and CISA's published guidance and the score weighs your answers, but neither can see your contracts, your customers or the systems around the site. The decision, and the risk, stay with whoever is responsible for the site.
Beyond the one site
The server you know about is rarely the only one
Organisations running PHP often have more of it than they realise: a staging copy, an old campaign site, a container, an appliance with PHP inside. A vulnerability scan finds them and shows which are still exposed.