PHP2Shell vulnerability: is your practice website at risk?

Over the last two days, two practices have asked me almost word for word: “Is PHP still safe? Do we need to worry about our website?” The trigger was headlines about a PHP vulnerability said to threaten “half the internet”, and public authorities taking their websites offline. This question deserves a calm, honest answer. Here it is.

The key points in 30 seconds:

• On 21 October 2026, the PHP project closed two serious security vulnerabilities. PHP is the technology that WordPress, for example, runs on.
• The vulnerability is serious, but the update is available. By the morning of 22 October, no successful break-in had been publicly confirmed, although there had been a very large number of automated attack attempts.
• Whether your website is protected depends on the PHP version on your hosting provider’s server, not on a WordPress update.
• Websites most at risk are those running PHP 8.1 or older and websites that nobody looks after.
• Your current provider cannot help you? Read the Emergency section further down, or contact us directly.

What happened? The short version without the jargon

PHP is a programming language that a large share of the world’s websites run on. Many practice websites use it too, usually through WordPress. You can think of PHP as the engine that assembles each page in the background as soon as a patient opens it.

Two flaws were found in this engine which, under certain conditions, allow outside code to be run on the server. Specialists call this remote code execution. Put simply: in the worst case, an attacker could take control of the website without knowing a password.

Vulnerabilities like this are normally fixed quietly. The people who discover them report them, the developers build a fix, and the public is only informed once the update is ready. This time, exactly that process went wrong:

• On 20 October, the identification numbers of the vulnerabilities leaked early via an anonymous internet forum, together with exaggerated claims.
• That same evening, one of the security firms that had found the vulnerability accidentally published a video demonstrating the attack. It was deleted, but copies continued to circulate.
• On 21 October at 16:00 German time, the official update was released, one day earlier than planned (PHP Foundation), (php.net).

Important for putting this in context: PHP itself was not hacked, and no data was leaked. What leaked was the information that the vulnerability exists.

Why the headlines were louder than the actual situation

If you have read the news over the last few days, you were probably worried. That is understandable, because many reports contradicted each other or exaggerated. Three examples:

1. The severity was overstated. The leaked post gave the highest possible severity rating, 10 out of 10. Many media outlets repeated this. The official rating is 9.2. That is still critical, but the developers explicitly called the 10 wrong, because an attack depends on certain preconditions.

2. The affected versions were named incorrectly. Some reports spoke of “PHP 5, 6, 7 and 8”. A PHP 6 version has never been released. A member of the PHP security team has since publicly corrected the worst errors (Alexandre Daubois).

3. Shutdowns were mistaken for attacks. In the Netherlands, Finland, France and also in Germany, authorities took individual websites offline as a precaution, and in the Netherlands, citizen portals were temporarily offline too. That read like a large-scale attack. In fact it was caution: according to consistent reports, the shutdowns were not caused by break-ins but by the decision not to take any risks until the update was available.

The BSI (Germany’s Federal Office for Information Security) has issued a warning and advises you to update without delay (BSI). That is the factual core message behind all the headlines.

Is your practice website affected?

This is where it gets specific, and where the good news lies. The vulnerability is in the PHP engine itself, not in WordPress, not in your theme and not in your plugins. That means:

• A WordPress update does not close this vulnerability. What matters is which PHP version your hosting provider uses on the server, for example IONOS, Strato or your IT service provider.
• Versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or higher are protected. These versions contain the fix.
• PHP 8.1 and older is affected, and there is no official update for it. These versions are no longer maintained by the PHP project. Fixes do exist in the source code, but you will need to ask your hosting provider whether they apply them.

One detail, so that you do not worry unnecessarily: some hosting providers and server operating systems build security fixes into older versions without the version number changing. An “old” number therefore does not automatically mean that your server is unprotected. It does mean, however, that you should ask.

Not affected are websites whose server does not run PHP at all. These include, for example, static websites, which we have also been using for our own website since this autumn. More on this further down.

How to check your PHP version in two minutes

If your website runs on WordPress and you have access to the admin area:

If it shows 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a higher number in the same branch, this vulnerability is closed. If it shows 8.1 or older, or a lower number, speak to your hosting provider or the person who looks after your website today.

You have no access or do not know who looks after your website? Then that is the first finding, and not a rare one. Send us your web address and we will help you assess the situation.

How to tell whether your website has already been compromised

Compromised means: an outsider has gained access and changed something. For this vulnerability, that has not yet been publicly confirmed. However, because there have been documented first attack attempts since 17 October (AWS Security Blog), a careful check is worthwhile. Especially if your website still runs on an old version.

What you can check yourself, in about 10 minutes

• User list in WordPress: Under Users, filter by the Administrator role. Are there names you do not recognise?
• Look at your website from the outside: On a computer and on your phone, once directly and once via Google search. Are you redirected to other websites? Do you see adverts, foreign languages or content that is not yours?
• Ask Google: Enter site:your-practice.de in Google, using your own address. Do pages appear that you never created, for example with adverts for medicines or gambling?
• Google Search Console: If it is set up, look at the security issues under Security and Manual Actions.
• Messages from your hosting provider: Has your hosting provider sent warnings, or has the website been noticeably slow or occasionally unavailable over the last few days?
• Forms and emails: Are unusual enquiries coming in, or are people you know reporting spam that appears to come from your address?

If none of this stands out, that is a good sign. It is not a guarantee, because skilled attackers hide themselves.

What your service provider should check

These points require technical access to the server. You can pass the list on to the person who looks after your website as it is:

• Changed and new files since 17 October, especially PHP files in the upload folder (wp-content/uploads). Only images and documents belong there.
• Comparison of the WordPress core files and plugins with the originals using checksums.
• Server logs from 17 October: unusually large uploads and frequent memory errors. Both can point to attack attempts, but are not yet proof of a break-in.
• Scheduled tasks (cron jobs), the .htaccess file and new entries in the database.
• A scan with a reputable security scanner.

If a suspicion is confirmed

Please do not delete everything in a hurry. It is better to follow this order:

1. Preserve the current state: a copy of files and logs, so that it can be established later what happened.
2. Take the website offline temporarily or switch on a maintenance page.
3. Change all passwords: WordPress, hosting, database, FTP and email.
4. Restore from a clean backup and move straight to a current PHP version while doing so.
5. Check data protection: if your website has forms that handle patient data, involve your data protection officer.

Emergency: your provider cannot help you? We can help.

Over the last few days we have often heard: “I asked my web designer but got no answer.” Or: “The agency that built our website no longer exists.” Or: “My service provider says they are dealing with it, but I don’t know if that is enough.”

This is not a criticism of anyone. Many practice websites were built years ago, and the support gradually lapsed at some point. A report like this suddenly brings that to light.

If any of these statements applies to you, get in touch with us:

• Your current provider cannot be reached or cannot answer the question about the PHP version.
• You do not know who looks after your website or where the access details are.
• Your website runs on PHP 8.1 or older, and nobody is updating it.
• You have noticed one of the warning signs above and do not want to wait.

What we then do:

What we need from you: your web address and, if known, the name of your hosting provider. Access details are helpful but not essential. If they are missing, we will show you how to get them back via your hosting provider. The website belongs to you, not to your former service provider.

Are you moving to a new server soon anyway?

This question came up in one of the two conversations: is maintenance on the old server still worthwhile if the move is happening next week anyway?

My honest answer: A large maintenance package for the old server is not worthwhile. A small stopgap is. Most automated attacks come in the first few days after a vulnerability becomes known. In this situation, a week is a long time. Sensible steps are:

1. Ask your hosting provider whether the PHP version on the server already contains the fix.
2. If possible, switch to PHP 8.2 or newer straight away. With many hosting providers, this is a setting in the customer area and takes a few minutes. Afterwards, briefly check that the website still works normally.
3. If that is not possible, put a protective layer in front of it. Services such as Cloudflare introduced emergency rules against this vulnerability on 21 October, including for the free plan (The Hacker News). This is a temporary solution, but reasonable for a week.
4. Make a backup now, while nothing looks suspicious.

And for the move itself, two points that are often overlooked:

• The new server needs a current, patched PHP version. Otherwise the problem simply moves with you.
• Move only the content, not all files blindly. If the old website has in fact been compromised in the meantime, you would otherwise take a hidden back door with you. The clean approach: install WordPress and plugins fresh on the new server and only transfer content, images and the database after they have been checked.

Looking ahead: what this vulnerability tells us about the coming years

If the situation is calmer now, why not simply tick it off? Because the case shows something that will remain.

Artificial intelligence now finds security vulnerabilities faster than ever before. The flaws in PHP were discovered in August 2026 with the help of AI models, by several teams independently of each other. One company says it found the vulnerability in a single evening with its own AI tools, based on nothing more than a hint (Techzine). Since July, the PHP project has published 15 security vulnerabilities and handled more than 100 invalid or duplicate reports (PHP Foundation).

For you as a practice owner, this means three things:

• Reports like this will become more frequent. Not because software is getting worse, but because it is being examined more thoroughly. By attackers too.
• The time between update and attack is shrinking. Amazon observes that AI-supported analysis allows more actors to act within hours (The Hacker News). Anyone who only updates after two weeks will be late in future.
• The decisive question is not “which technology” but “who looks after it”. A well-maintained WordPress website was protected within hours on 21 October. A website that nobody feels responsible for may still not be protected today.

And the article Digital patient management describes why trust online carries so much weight, especially for health topics.

Three ways to keep your website secure

Perhaps the topic of your website has felt like hard work for a while. Nothing has been done for years, nobody knows exactly who has the access details, and every change takes weeks. In that case, this report is no reason to panic, but a good opportunity to put things in order. This can be done in manageable steps, and you do not need to become a technical expert to do it.

There are three sensible ways. None of them is right for every practice.

Option 1: Keep WordPress and have it looked after reliably

WordPress is secure when it is looked after properly. That includes a current PHP version, regular updates of WordPress and plugins, daily backups and someone who acts on the same day when a report like this comes out. This is the obvious option if your website looks good, brings in patients and you are happy with it.

Option 2: Switch to a lean website without PHP

Static websites deliver ready-made pages instead of assembling them anew each time they are opened. No PHP runs on the server, no database can be reached from outside, and there is considerably less that can be attacked or needs updating. This vulnerability does not affect such websites. We switched our own website to this approach in autumn 2026 and also use it for practices.

The honest catch: switching is a relaunch, not a push of a button. It is mainly worthwhile if your website is getting on in years anyway. We show openly what a practice website with hosting, security and maintenance costs on our Website and web design page. The guide What does practice marketing cost? gives an overview of budgets, and you can read what generally matters for a good practice website under Websites for doctors.

Option 3: First find out where you stand

You do not have to decide anything today except one thing: to find out what state your website is in. That is what our free security check is for.

Your next step with MedDirection

For anyone who is unsure, wants clarity quickly or suspects that their website is affected: you give us your web address and, if known, your hosting provider. We check what can be checked and send you a short, clear assessment: Is your website affected by this vulnerability? What is urgent now, and what can wait? Which questions should you ask your hosting provider or service provider? This is usually done within 1-3 hours. Due to the current high demand, we can offer you a solution within 72 hours.

For anyone who would like to talk about options straight away: in the initial consultation, we look at your website together and discuss which of the three options suits your practice. Without jargon and without sales pressure.

There will always be security vulnerabilities. What you can control is whether someone responds on the same day next time. We are happy to take care of that, from Berlin and Dresden, for practices across the DACH region.