In short: After the warning about PHP2Shell, websites were taken offline in Germany, including, according to the media, the web portal of the city of Mainz as well as sites of the Hessian state government and the BKA (German Federal Criminal Police Office). This was a precaution following a BSI (German Federal Office for Information Security) recommendation, not confirmed attacks. Companies can learn from this: a shutdown is a legitimate option when a patch is not immediately possible, and it works best when it has been prepared.
Websites taken offline over PHP: what happened on 21 October
On the day of the PHP security updates, numerous public websites in Germany were unreachable. According to media reports, the city of Mainz took its central web portal offline as a precaution. Offices remained reachable by telephone and email.
In Hesse, according to hessenschau, sites of the state government, the Federal Criminal Police Office and the cities of Kassel and Wiesbaden, among others, were temporarily offline. The State Chancellery spoke of technical adjustments and reported no attack. The state websites were reachable again in the evening. According to reports, other municipalities, universities and hospitals also took services offline as a precaution.
The background is the BSI's recommendation on PHP2Shell: update immediately and, if that is not possible right away, take affected web servers offline temporarily. What the BSI advises in detail is summarised on the page What the BSI recommends on PHP2Shell.
Offline does not mean hacked
In comments and on social networks, "offline" quickly turned into "hacked". Going by everything known, that is wrong. The shutdowns were a protective measure at a moment when many operators did not yet know the patch level of their servers for certain.
This distinction matters twice over for companies. First, externally: anyone who shuts down as a precaution should say so rather than stay silent. Second, internally: a shutdown does not answer the question of whether the server was attacked beforehand. It only stops further attempts. The check for traces remains necessary.
A third point is often overlooked: a shutdown must not destroy traces. Anyone who simply reinstalls the server in order to take it offline, or deletes logs to free up space, loses the ability to clarify later what happened before the shutdown. It is better to redirect the web server to an emergency page or to block access from outside and leave the server itself, with all its logs, unchanged.
Why public bodies in particular reacted this way
Authorities often run many websites side by side: main portal, specialist portals, form services, pages of individual offices and institutions. Several service providers are frequently involved. On the day of the warning, it was simply not possible for many administrations to obtain a documented patch level for every system within hours. In that situation, the precautionary shutdown was the fastest way to follow the BSI recommendation.
For companies with a grown IT landscape, the situation is often similar. The question "Is everything patched?" fails not because of the technology but because of a missing overview.
It is also remarkable how quickly the Hessian state websites came back, according to reports: the same evening. This shows that a precautionary shutdown does not have to last for days. Anyone who knows their systems and masters the update path can patch, check and go back online within a few hours. The shutdown then only bridges the time until there is clarity.
When a precautionary shutdown makes sense for companies
Authorities are in a special position: many websites, often maintained in a distributed way, and high public visibility. But the trade-off they faced is the same as in any company. The following overview helps with the decision:
| Situation | Rather shut down | Rather stay online |
|---|---|---|
| Patch level | unclear or not confirmed | fixed and documented, processes restarted |
| PHP version | 8.1 or older without a confirmed backport | supported branch at current level |
| Operating mode | Apache with mod_php | patched PHP-FPM with interim measures in place |
| Data on the server | customer data, logins, payment data | purely static content |
| Availability of the service provider | patch only possible in days | patch scheduled shortly |
The trade-off between patching, shutting down and waiting is explored further in the article Patch, shut down or wait?. What is technically possible as a stopgap when the update is still missing is covered under Immediate measures without a patch.
Temporarily taking a shop or customer portal offline costs revenue. A compromised server with customer data can cost considerably more, up to and including reporting obligations. Make the decision deliberately and record it in writing.
How to prepare for a shutdown
Mainz showed what matters: the administration remained reachable through other channels. That only works if it has been prepared. These steps are worthwhile before the next emergency arrives:
- Keep an emergency page ready: a static HTML page without PHP, with a short explanation, telephone and email contact and, if necessary, notes on current orders or appointments.
- Define the switchover route: Who can redirect the website to the emergency page, via the web server, DNS or an upstream service? How long does it take?
- Clarify decision authority: Who may order a shutdown, including outside business hours?
- Know the dependent services: Do interfaces, apps or partners depend on the website? Who needs to be informed in advance?
- Define criteria for going back online: patch documented, restart done, initial check for traces without findings.
- Pre-draft the message: two to three sentences for customers, partners and the press.
How to communicate externally in such a situation is described in the guide to crisis communication.
How does PHP SOS help?
- Basis for the decision: We determine the patch level, operating mode and data situation of your servers and give you a clear assessment of whether a shutdown is advisable.
- Orderly shutdown: We switch to a static emergency page without losing logs or traces.
- Patch and check: We update PHP, restart all processes and check for anomalies.
- Controlled return: We only put the website back online once the agreed criteria are met and documented.
The process is described on the page PHP2Shell immediate help.
Conclusion
The authorities' shutdowns were not a sign of lost control but a deliberate precaution. For companies, that is the real lesson: going offline is a legitimate decision when the patch level is unclear. Anyone who has prepared the emergency page, responsibility and return criteria makes it in minutes rather than hours.
Frequently asked questions
Why were authority websites taken offline because of PHP?
For PHP2Shell, the BSI recommends updating immediately and, if that is not possible right away, taking web servers offline temporarily. Several authorities followed this recommendation as a precaution until their systems had been checked and updated.
Does a website that was taken offline mean it was hacked?
No. A precautionary shutdown is a protective measure. The Hessian State Chancellery, for example, expressly reported no attack, according to hessenschau. Only an examination can establish whether a server was affected before the shutdown.
How long should a website stay offline?
Until PHP is at a fixed version, all PHP processes have been restarted and an initial check for traces has found nothing unusual. There is no fixed duration; according to reports, the Hessian state websites were reachable again on the evening of the same day.
What do I show visitors while the website is offline?
Ideally a plain, static emergency page without PHP, with a short explanation and the contact channels through which you remain reachable. It should be prepared before it is needed.