In short: A medical practice website is about the security of health data, not just a business card on the web. Check which forms store data or send it by email, have the server's PHP patch level confirmed in writing, and preserve the logs immediately if you suspect a problem.
Which PHP systems run in practices and MVZ
Most practice websites are based on a PHP CMS, often WordPress, less often TYPO3 or Joomla. It gets interesting with the additional functions: forms for prescription and referral requests, patient history questionnaires to download or upload, recall registrations, job ads with application uploads and online appointment booking.
Appointment booking is often an external service that is merely embedded. In that case the appointment data sits with the provider. Some practices, however, use booking plugins that store appointments together with the reason for the visit in the website's own database. You should know exactly this difference before you assess the risk.
Health data: why the website is more sensitive than it looks
A sentence like “I need my blood pressure medication again” in the contact form is health data. Such details belong to the special categories of personal data under Art. 9 GDPR. For doctors, the duty of confidentiality also applies, and breaching it can be a criminal offence under Section 203 of the German Criminal Code (StGB).
For the website this means: form entries that remain in the database, copies in form plugins, mail logs on the server and uploaded documents are all within reach in an attack. Anyone who executes code on the server will usually be able to read them too.
Have it checked whether your form plugin also stores entries in the database. Many do so by default. Data that is not stored cannot leak.
What an outage or data leak means for the practice
If the website goes down, patients call, and the practice phone is already busy as it is. That is annoying but manageable. An unnoticed attack weighs more heavily: redirects to fraudulent sites under the practice's name, forged forms or intercepted requests that refer to illnesses.
Such an incident can trigger reporting duties towards the data protection authority and, depending on the risk, a notification of the people affected. The 72-hour deadline under the GDPR starts as soon as you become aware of the breach. Clarify the assessment with your data protection officer.
Medical practice website and security: the typical responsibility gap
In practices there are usually three parties, each feeling responsible for one part:
| Party | Usually takes care of | Often not on their radar |
|---|---|---|
| Practice IT service provider | Practice management system, network, connector, workstations | Website server at the host |
| Web agency | Design, content, plugins | PHP version and restart of the server |
| Host | Server operation | The practice's form data and plugins |
With PHP2Shell the gap lies exactly between these roles: in PHP on the web server. With shared hosting the host is usually responsible, but you have to request the confirmation of the package version yourself. In MVZ with several locations, the operator often comes into play as well and sets its own requirements.
Is there a bridge between the website and the practice network?
The practice website usually runs at the host and has no direct connection to the practice management system. There are exceptions you should know about, though: forms that transfer data automatically into the practice management system, a website server in the MVZ's own data centre, or credentials used at the same time for the website, mail accounts and remote maintenance.
In such cases a compromised web server is not just a website problem. Have your practice IT service provider and the person maintaining the website jointly check which connections exist and which passwords are used more than once. In addition, the requirements of the German National Association of Statutory Health Insurance Physicians (KBV) on IT security apply to the practice IT. How far they affect the website is something to clarify with your data protection officer.
The first hours after a warning
- Ask the host whether PHP is at 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a backport has been applied, and whether all PHP processes have been restarted.
- If that is not confirmed: take the website offline temporarily or replace it with a static notice page showing phone hours, as the BSI (German Federal Office for Information Security) recommends for servers that cannot be patched.
- Preserve server and access logs from 20 October 2026 onward.
- Watch for signs of a compromise: unknown files, new admin accounts, changed redirects.
- Involve the data protection officer early, not only after the cleanup.
How does PHP SOS help?
- We clarify with the host and the agency who patches and restarts PHP, and obtain the confirmation with the package version.
- We check where form data, uploads and mail copies are stored on the web server, and whether connections to the practice network exist.
- If you suspect a problem, we preserve evidence, search for webshells and clean up the server as part of our emergency help for hacked websites.
- We document the incident so that your data protection officer can assess the reporting duty.
- Afterwards we reduce the stored data and harden the server, so that less is at stake next time.
Frequently asked questions
Is my practice software affected by PHP2Shell?
The practice management system and the connection to the telematics infrastructure usually run separately from the website. What is affected are PHP web servers, that is, usually the practice website and any forms or portals connected to it. Whether there are links between the website and the practice network should be checked by your IT service provider.
Is data from the contact form health data?
Often yes. Even a request for a repeat prescription, or an appointment request because of particular symptoms, allows conclusions about health. Such data belongs to the special categories under Art. 9 GDPR. You clarify the exact classification with your data protection officer.
Do I have to inform patients if the website was hacked?
That depends on whether personal data is affected and how high the risk is for the patients. With health data the risk is often high. You make the decision with your data protection officer and, if needed, with legal advice.
Who is responsible for PHP updates on the practice website?
That is set out in the hosting or maintenance contract. With shared hosting and managed hosting the host usually patches; with your own server, the service provider you have commissioned does. If there is no clear arrangement, you should put one in writing now.