When you cannot update today: a 48-hour mitigation plan

An old application, a late vendor, a device with PHP inside: the decisions to take in the first 48 hours after a critical vulnerability, using PHP2Shell as the example.

Sometimes news of a serious vulnerability arrives at a moment when updating simply cannot happen straight away. The application is old and does not support the new version. The vendor of a device promises a fix "soon". The agency that built the website no longer answers the phone. That was the situation in October 2026 with the PHP2Shell vulnerabilities: the PHP team published fixes on 21 October, but many companies could not apply them that same day.

This article is for the owner or manager in that position. It does not explain how to configure a server. It sets out which decisions to take, in what order, and what to ask your team or supplier for in the first 48 hours. The example is PHP2Shell, but the steps apply to any critical vulnerability.

One thing needs saying up front: a mitigation plan buys time, it does not solve the problem. The PHP team states explicitly that there is no complete mitigation for PHP2Shell and that only updating is safe. Everything below is a bridge to an update or a migration, not an alternative to one.

The first question is not "how do we defend ourselves" but "where does the vulnerable software run". The NCSC, the UK's national cyber security agency, puts the inventory first. DNSC, Romania's national cyber security directorate, asks for the same and points to the places people forget: test servers, old applications that are rarely used, and solutions supplied by vendors.

For PHP2Shell, the list typically includes:

• the company website and the online shop;
• internal applications (customer portal, intranet, forms);
• test or development copies left on a server;
• devices with a PHP-based web interface: some NAS units, routers or building management systems. The Dutch NCSC-NL keeps a public list of affected products.

For every system on the list, write down one name: the person who can make a change to it today. It may be a colleague in IT, the hosting provider, the agency that built the site or the device vendor. DNSC recommends naming an owner for each installation. If a system has nobody, you have already found your biggest problem.

On shared or managed hosting, PHP is updated by the host, not by you. Write to them directly and ask three things: whether they have applied the 21 October fixes, when they will if not, and what temporary measures they have in place until then. Ask for the answer in writing. For device vendors, ask when the update will be available and what they recommend in the meantime.

The FBI and the NCSC say the same thing: if an immediate update is not possible and the temporary measures cannot be applied either, the system should be taken offline until it is fixed. For a manager, the decision comes down to two questions: what a day without the system costs, and what is lost if the system is compromised. A brochure website can be replaced with a static page for a few days. An online shop or a customer portal needs more careful thought, but the risk of a hijacked server includes your customers' data.

For PHP2Shell, the PHP team published a few measures that reduce the risk. Whoever manages the server applies them; you only need to know what to ask for:

• turning off a PHP feature called "session upload progress", then restarting every PHP process;
• lower limits on the size of incoming requests and on the number of fields they contain;
• blocking file uploads wherever the site does not need them;
• memory settings enforced by the administrator, which the application can no longer change.

Ask for confirmation that the measures were applied in the server configuration, not just inside the application, and that the PHP processes were restarted. DNSC points out that without a restart the server may keep running with the old settings.

A web application firewall (WAF) filters requests before they reach the server. Cloudflare published rules for PHP2Shell, including on its free plan. DNSC sets a clear condition, though: a WAF only helps if the server cannot be reached directly, bypassing the filter. Ask your team to confirm that the server only accepts traffic through the WAF. Otherwise the protection is only apparent.

Anything not needed today is extra risk: test copies, old applications nobody uses any more, file upload forms nobody checks. Switching them off temporarily is the cheapest measure in the whole plan.

If the company website has to go offline, a simple static page with your contact details and a short message keeps the business visible. It does not run PHP, so it is not exposed to the same vulnerability.

Attacks can start before the patch. With PHP2Shell, the first reported attempt came on 17 October, four days before the announcement. The FBI recommends watching for PHP processes that launch command shells or download files. DNSC adds the signs to look for from 20 October 2026, 15:00 UTC:

• new or modified files in the website's directories;
• changes to PHP configuration files inside the website's directories;
• new scheduled tasks or SSH access keys;
• new administrator accounts in the application.

If anything turns up, the system is isolated, the logs are kept, and the question is no longer "when do we update" but "how do we clean up".

Before any update or migration, you need a backup you know can be restored. "We have a backup" is not the same as "we restored yesterday's backup to a copy and it worked". Ask for the second, and keep the backup separate from the affected server.

The mitigation plan ends with a date. If the application runs on a supported PHP version, that is the date of the update. If it runs on PHP 8.1 or older, for which the PHP project no longer publishes releases, it is the date of the migration, and the temporary measures stay in place until then. A plan without a date tends to become the system's permanent state.

DNSC warns about several measures that feel reassuring but do not protect against PHP2Shell:

• security plugins in WordPress or other applications;
• the website's maintenance mode;
• disabling file uploads in the application settings;
• the application's own login checks.

The reason is the same for all of them: they act after PHP has already processed the request. The vulnerability sits before them.

1. Hours 0–4: the inventory, an owner for each system, written questions to your host, and the online or offline decision.
2. Hours 4–24: the official temporary measures, a WAF only with direct access to the server closed, switching off anything not needed, and a static page if required.
3. Hours 24–48: watching for signs of compromise, a backup restored as a test, and a fixed date for the update or migration.

At ME Digital we help companies that cannot update immediately: we take the inventory, apply the temporary measures, check for signs of compromise and prepare the update or migration, as part of our security and updates services. If you have a system in this position, get in touch.

• PHP, security announcement of 21 October 2026, including the temporary measures
• DNSC, Alert: critical vulnerabilities in PHP (updated 22 October 2026, in Romanian)
• NCSC (UK), Critical security issue affecting PHP
• FBI Cyber Division, guidance on the PHP vulnerabilities (21 October 2026)
• CERT-EU, Security Advisory 2026-018
• Cloudflare, WAF protection for the PHP vulnerabilities
• NCSC-NL, list of products that include PHP
• The Hacker News, the 17 October exploitation attempt reported by Amazon