# Patch, Shut Down or Wait? A Decision Aid for the PHP Vulnerability

> Take your website offline because of the PHP vulnerability? A decision aid for choosing between patching, shutting down and waiting, with criteria, steps and limits.

Source: https://phpsos.de/en/blog/patchen-abschalten-abwarten/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** Whether you should take a website offline because of the PHP vulnerability comes down to one question: is PHP on this server demonstrably running on a fixed version, and have all processes been restarted? If so, no shutdown is needed. If the update is not possible immediately, the BSI recommends taking the web server off the network temporarily. Waiting is only defensible if the system does not use PHP, is not publicly reachable or the provider has confirmed the patch in writing.

## The situation in which you have to decide

PHP2Shell comprises two vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. They allow remote execution of malicious code without a login. Fixed versions have been available since 21 October 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no official updates any more for PHP 8.1 and older.

The BSI issued warning level orange and advises an immediate update or, failing that, temporary shutdown. According to media reports, the city of Mainz, bodies of the Hessian state government and other public institutions took websites offline as a precaution; the Hessian State Chancellery reported no attack. What companies can take from this is under [Authorities take websites offline](https://phpsos.de/en/blog/behoerden-webseiten-offline/).

For those responsible in companies, the question is more practical: what do we do with our shop, our portal, our company website, today?

## Taking a website offline, patching or waiting: the three options compared

The following table sets the options side by side. It does not replace the assessment of your individual case, but it makes the trade-off visible.

| Criterion | Patch immediately | Shut down temporarily | Wait |
|---|---|---|---|
| Protection against PHP2Shell | High, if patch and restart are evidenced | High for the duration of the shutdown | None, as long as unpatched |
| Business interruption | Short, for update and restart | Hours to days | None |
| Prerequisite | Supported PHP version, access, maintenance window | Management decision, static replacement page | Evidenced reason why there is no risk |
| Effort | Low to medium | Low technically, high organisationally | Low, but effort to check the evidence |
| Typical case | Server with PHP 8.2 to 8.5 | Legacy system with PHP 8.1 or older, unclear status | System without PHP or reachable internally only |
| Residual risk | Earlier break-in remains possible | Earlier break-in remains possible | Fully present |

One row deserves attention: neither patching nor shutdown clarifies whether something has already happened beforehand. According to media reports, the first observed attack attempt was on 17 October 2026, before the patch. A look for possible traces therefore belongs to every option.

## Five questions to reach a decision

Work through the questions in order. The first clear answer usually leads to the decision.

1. **Is PHP running on the system at all, and is it reachable from the internet?** If not, the system is not directly affected by PHP2Shell. Document how you established this.
2. **Is the patch level evidenced?** Evidenced means: fixed version or backport with CVE numbers in the package changelog and restart of all PHP processes. A version display in the control panel is not enough. How to check this is under [Checking the PHP version and patch level correctly](https://phpsos.de/en/php2shell/php-version-pruefen/).
3. **Can the update be installed in the next few hours?** If so: patch, restart, verify. Until then, interim measures can help.
4. **Is that not possible, for example because of PHP 8.1 or missing access?** Then, according to the BSI, temporary shutdown is the way. Interim measures from php.net reduce the risk but do not protect completely; details are under [Immediate measures if you cannot patch yet](https://phpsos.de/en/php2shell/sofortmassnahmen-ohne-patch/).
5. **Are there signs of compromise?** Then the question is no longer “patch or shut down” but “handle the incident”. Shut down, preserve evidence, do not delete prematurely.

## If you shut down: shut down properly

A shutdown is supposed to remove the attack surface, not merely hide the home page. A maintenance page that is still generated by PHP does not serve this purpose. Better is a static HTML page that the web server delivers without PHP, or a redirect to another server.

Think of everything that hangs on the same PHP: subpages, interfaces for apps or merchandise management, admin areas, payment callbacks. Talk beforehand to the payment provider and logistics if a shop is affected. And inform staff and customers in clear words: the site is offline as a precaution, contact is by phone and email. That is better than silence, which feeds speculation.

The end of the shutdown matters too. Define under which condition the site goes back online, for example “PHP on a fixed version, restart verified, first check for traces without findings”. That turns an emergency brake into an orderly process.

> **Important:**
> Shutting down is not a defeat. According to media reports, several public bodies did exactly that without any attack having occurred. A precautionary shutdown does not automatically mean that a website has been hacked.

## When you do not need a service provider

Not every decision requires outside help. If your website is with a host that confirms the patch level and restart in writing, and there are no anomalies, you are well positioned with brief documentation. The same applies if your own IT can patch a server with a supported PHP version itself and masters the verification.

Help is worthwhile if systems with an old PHP version are running, the status is unclear, several servers are affected or there are signs of a break-in.

## How does PHP SOS help?

1. In a short time, we clarify with you which systems are affected and which patch level is evidenced.
2. We provide management with a one-page basis for the decision: options, risks, recommended route.
3. We implement the chosen route, that is, patch with restart, interim measures or a clean shutdown with a static replacement page, as part of our [PHP2Shell immediate help](https://phpsos.de/en/leistungen/php2shell-soforthilfe/).
4. We check for traces since 17 October 2026 and document the result.

## Conclusion

Patching is the normal case, shutting down the right emergency brake, and waiting defensible only with evidence. Anyone who answers the five questions honestly and records the decision in writing acts in line with the BSI recommendation and can later show why.


## Frequently asked questions

**Must I take my website offline because of PHP2Shell?**  
Not if PHP is already running on a fixed version and all processes have been restarted. The BSI (German Federal Office for Information Security) recommends temporary shutdown for the case where an immediate update is not possible.

**What costs more: a shutdown in revenue or the risk?**  
That can only be answered case by case. An outage of hours is usually easier to plan for than a break-in whose consequences and duration nobody knows. Record the weighing in writing, whatever the outcome.

**May a maintenance page run on the same server?**  
Yes, if it is served as a static file without PHP. If the maintenance page is still generated by PHP, the attack surface remains.

**Is waiting ever the right choice?**  
Yes, in clearly defined cases: if no PHP runs on the system, if it is not reachable from the internet, or if the provider has confirmed patch and restart in writing. Waiting without such evidence is not an option but a risk.

**Who should make the decision?**  
The person who is responsible for the business risk, usually management or the owner. IT supplies the facts. Who decides should be set out in advance in the emergency plan.

## Sources

- [BSI: warning on PHP2Shell](https://www.bsi.bund.de/)
- [php.net: security announcements](https://www.php.net/)
- [hessenschau: authority websites in Hesse taken offline](https://www.hessenschau.de/panorama/sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-v2,sicherheitsprobleme-hacker-webseiten-100.html)
- [ZDFheute: security vulnerability in PHP](https://zdfheute.de/politik/sicherheitsluecke-php-webseiten-onlinedienste-cybersicherheit-bsi-100.html)