PHP2Shell: Why EDIS had to carry out an emergency shutdown

The vulnerabilities known as “PHP2Shell” may be the most serious security threat we have faced in our almost 30-year company history. They forced us to take a measure that had never previously been necessary at EDIS: temporarily shutting down our webhosting services, including the websites hosted on them, as a precaution.

This decision followed intensive technical assessments and calls arranged at short notice with other hosting providers. We wanted to understand how our peers assessed the situation and whether they were also considering an emergency shutdown. Those conversations made it clear that other companies were seriously considering this exceptional protective measure too.

At the same time, media coverage increased sharply within just a few hours. Our customers’ concern was clearly evident: a small number even deleted their domains’ DNS records themselves in an attempt to protect their websites from possible attacks. We understand that concern. However, deleting DNS records is no substitute for a security update or for effectively isolating a vulnerable server.

Our decision was driven by the technical risk assessment: a successful attack could have had severe consequences, while immediately deployable security updates were not yet available for all affected systems. We therefore prioritised the security of the systems and data entrusted to us and followed the recommendations of CERT-EU and other national cybersecurity centres to isolate vulnerable services from the public internet until they could be secured.

We know what an interruption like this means. Websites become unavailable, online shops cannot accept orders, and businesses lose an important point of contact with their customers. The decision on 21 October 2026 was therefore one of the most difficult we have made in recent years. Based on our assessment at the time, however, there was no responsible alternative to an immediate precautionary shutdown.

What PHP2Shell means

PHP2Shell refers to two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. They affect PHP itself, the underlying technology used by many websites, online shops and content management systems. Under certain conditions, attackers can execute their own code on an affected server without first authenticating. Researchers also demonstrated the ability to read sensitive information from memory. Even an up-to-date website can be affected if its underlying PHP binaries are vulnerable. Updating WordPress, Joomla or individual extensions alone therefore does not fix these vulnerabilities.

Security updates: Why older PHP versions required so much work

Security updates had been announced for 21 October at 16:00 Austrian time. When we made our decision, however, we could not rely on immediately usable and tested updates becoming available at that time for every PHP version in use across our systems. An announced release does not mean that all affected systems have already been secured.

Once the fixes were released, we could begin updating our systems. New security releases were available for the supported PHP branches 8.2, 8.3, 8.4 and 8.5. The situation was considerably more difficult for older PHP versions. Source-code fixes were also provided for PHP 7.4, 8.0 and 8.1, but these did not automatically translate into installable packages for every existing server environment.

For PHP 7 and the much older PHP 5 environments in particular, security fixes had to be backported to older source-code versions, adapted, compiled by our team and then tested. We encountered enormous technical difficulties when assessing and securing systems running PHP 5.3, 5.4, 5.5 and 5.6. These involved different software versions and dependencies, some of which had been out of regular support for many years.

We therefore worked to clear priorities: first, we updated our current Hosting NG platform with its Coffee hosting plans. We then updated the LTS hosting plans sold up to June 2019. These older platforms host projects running PHP versions up to and including 7.3.

Timeline of the shutdown and restoration

All times below are Austrian summer time (CEST).

• 21 October, 14:44: Precautionary shutdown of the Webhosting Control Panel and Webmail.
• 21 October, 15:04: The protective measure was extended to all hosted websites.
• 21 October, from 16:00: Review of available security updates and preparation for installation.
• 21 October, 21:40: Websites running PHP 8.2 to 8.5 were reachable again.
• Overnight into 22 October: Work continued on PHP 8.0, 8.1 and the older PHP 7 versions.
• 22 October, from 08:00: Gradual activation of the updated PHP versions 7.4, 8.0 and 8.1.
• 22 October, 13:30: Rollout began for PHP 7.3, the last outstanding version branch on Hosting NG, while work on LTS plans continued in parallel.
• 23 October, 08:00: All LTS webhosting plans had been patched and reactivated. All websites on our webhosting platforms were therefore active again.
• 23 October, 08:25: The Hosting Control Panel at manage.edis.at was also fully accessible again.

You can find the full chronology of our actions in the incident notice on our status page.

Keeping customers informed during the interruption

While our technical team worked on the security updates, our phone lines were extremely busy. We also received a large number of messages via WhatsApp, Messenger, email, SMS and other channels. Even with this exceptional volume of enquiries, we wanted to respond to our customers’ questions and concerns as quickly as possible.

Our status page therefore became the central source of information. We continuously documented what had happened, which work had been completed and what the next steps would be. In parallel, we updated automatic replies to incoming enquiries. Our aim was to provide customers with a clear explanation and the latest chronological overview as promptly as possible, regardless of how they contacted us.

We could not give a firm answer to every question immediately. In particular, it was initially impossible to reliably estimate the work required to produce a functioning security fix for the oldest PHP versions. We communicated that uncertainty openly and updated our information as further progress was confirmed.

Older PHP versions: Patches are only a temporary solution

The security fixes provided for PHP 5 and PHP 7 are explicitly a temporary solution. They address specific vulnerabilities, but they do not replace a regularly supported PHP version or the ongoing maintenance of your website. An outdated shop system, an unmaintained CMS or an insecure extension does not automatically become secure when the PHP binaries are patched.

PHP2Shell also illustrates how the threat landscape is changing. According to the security researchers involved, artificial intelligence helped uncover longstanding vulnerabilities and make them practically exploitable. We must expect AI to accelerate both the discovery of further vulnerabilities and the development of attacks. The fact that old software has run without apparent problems for years is no longer a security argument we can rely on.

We therefore urgently ask all customers with outdated websites, online shops and projects to start preparing their migration to current software. This includes up-to-date applications, maintained extensions, an officially supported PHP version and, for older hosting products, a move to a current hosting plan. Please involve your web agency or developers early. Simply switching the PHP version in the control panel is often not enough: the application must be compatible and tested.

Over the coming weeks, we will contact customers whose projects still require PHP 5 or PHP 7. We will provide a binding timetable specifying when the affected websites, shops and applications must be migrated to a supported technical platform.

We have kept older platforms running for a long time to provide continuity for existing projects. However, the effort and risk involved in keeping software that is sometimes around 15 years old running indefinitely through individual security fixes are no longer justifiable. As a hosting provider, we must draw a line when reliable operation and maintainable security can no longer be assured. In our view, accepting known security risks indefinitely would be grossly negligent.

We sincerely apologise for the interruptions and the difficulties they caused. Our team worked under considerable time pressure to secure systems and restore services step by step. Thank you for your patience and trust. We ask you to work with us on the modernisation that is now necessary.

Further information

For broader context on the security situation, see the reports from ORF (German) and Reuters, as well as the Wikipedia article on PHP2Shell (German).

Technical details and recommendations are available in the CERT-EU security advisory, the PHP project’s announcements and the Wiz Research analysis.