Security Alert · October 23, 2026
The PHP Vulnerability, Explained for Rural Hospitals
Two critical flaws were just found in the software that runs most of the web that allows the attacker to quietly plant a back door, steal credentials, gain root, and move toward patient systems — often undetected for weeks. Here’s what they mean for your hospital, why updating your website probably didn’t fix them, and what to ask your IT team today.
The 60-second version
- On October 21, PHP released emergency patches for two flaws (CVE-2026-109618 and CVE-2026-109619) rated 9.2 out of 10 in severity.
- An attacker can use them to run their own code on your web server without a password and without you clicking anything.
- The problem is in PHP itself, not in WordPress, Drupal, Joomla, or your custom site. Updating your website does not fix it. The server underneath has to be updated.
- Once inside, an attacker can quietly use your website’s server as a doorway into the rest of your network.
- Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Older versions need manual patching or replacement.
- If you’d rather not own this problem at all, book a free security assessment and we’ll show you how to get off a patch-it-yourself server for good.
First, what is PHP?
Think of your hospital’s website as a house. WordPress, Drupal, Joomla, or whatever custom system your team built is the house itself — the rooms, the paint, the furniture. It’s the part everyone sees and the part your web team edits.
PHP is the foundation and the plumbing. It’s the programming language running on the server that actually builds each page when someone visits. Roughly three-quarters of all websites on the internet sit on top of it, including the vast majority of hospital and clinic sites.
Most people never think about the foundation. That’s normally fine. This week, it isn’t.
What happened this week
On October 20, details of two serious bugs in PHP leaked online a day before they were supposed to be announced. The PHP team rushed out emergency fixes on October 21. Health-ISAC (the healthcare cybersecurity information-sharing group) and the American Hospital Association both issued bulletins the same day urging hospitals to act.
Both bugs are what security people call remote code execution flaws. In plain English:
A stranger on the internet can send your web server a specially crafted request — no login, no password, no one on your side clicking a link — and your server will run whatever program they want.
What makes these two especially dangerous is that they trigger before your website’s own code even starts running. That means it doesn’t matter how well-built or well-maintained your site is. If the server is reachable from the internet and runs an unpatched PHP, it’s exposed.
Why this matters more for rural hospitals
Large health systems have dedicated security teams who were on this within hours. Most critical access hospitals and rural clinics don’t. Your website might be managed by a one-person IT shop, a marketing vendor, or a hosting company you haven’t talked to in two years.
And a hospital website is rarely just a website. It often sits on the same network, or shares the same credentials, as systems that matter a lot more:
- Patient portals and appointment scheduling
- Provider directories and intranets
- Internal forms, job applications, and bill-pay pages
- Email, file shares, and in some cases the path to the EHR
Attackers know rural hospitals are more likely to be running older software and less likely to have someone watching the logs. That makes you a target of opportunity, not a target of choice — which is actually worse, because it means automated scanners are already looking for you.
Which platforms are affected?
If your website runs on any of these, it runs on PHP, and it is affected until the server is patched:
WordPress
The most common hospital and clinic website platform. Every WordPress site runs on PHP, including hosted ones.
Drupal
Popular with larger health systems, universities, and government-affiliated facilities. PHP-based.
Joomla
Less common today but still running many older hospital, foundation, and auxiliary sites. PHP-based.
Custom PHP sites
Anything built in-house or by a vendor using PHP, Laravel, Symfony, CodeIgniter, or similar. These are often the oldest and least maintained.
Also worth checking: patient-facing forms, physician referral tools, intranet portals, donation pages, and any “little” site a department set up years ago. These are frequently forgotten and frequently PHP.
Why updating WordPress (or Drupal, or Joomla) doesn’t fix this
This is the single most important point in this post, and it’s where a lot of organizations will get a false sense of security.
When your web team clicks “Update” in WordPress, they are updating the house. The bug is in the foundation. WordPress doesn’t ship PHP; it just runs on whatever PHP your server already has. The same is true for Drupal, Joomla, and every custom PHP application.
Three things that do not fix this vulnerability
- Updating WordPress, Drupal, or Joomla core
- Updating plugins, themes, or modules
- Running a general “server update” (for example
apt upgrade) and assuming it picked up the fix — many operating systems hadn’t packaged the patched PHP yet as of this writing
The fix has to happen at the server level: someone with administrative access to the actual machine (or your hosting provider) has to install the patched PHP version and restart the PHP service so the new code is actually loaded.
What “patched” actually means
| If your server runs… | You need… |
|---|---|
| PHP 8.5 | 8.5.12 or newer |
| PHP 8.4 | 8.4.27 or newer |
| PHP 8.3 | 8.3.36 or newer |
| PHP 8.2 | 8.2.35 or newer |
| PHP 8.1, 8.0, or 7.4 | No official release. PHP published source-code backports that must be manually compiled. Plan to upgrade. |
| PHP 7.3 or older, or PHP 5 | No fix at all. These are end-of-life. The server should be taken offline or rebuilt. |
A surprising number of hospital sites still run PHP 7.x. If that’s you, there is no quick patch — this is a migration project, and it should start now.
What “remote code execution” really looks like
The phrase sounds abstract. Here’s what it means in practice, step by step. None of this requires the attacker to be skilled; most of it is automated.
- 1
They find you
Scanners sweep the entire internet looking for servers that respond like unpatched PHP. Your hospital’s website shows up in a list within hours. Nobody chose you; a script did.
- 2
They get in silently
One malformed web request, and the server runs their code. Your website keeps working normally. Nothing looks broken. No alarm goes off. Your staff and patients see exactly what they saw yesterday.
- 3
They leave a back door
The first thing they install is a “web shell” — a tiny hidden file that lets them come back any time, even after you patch PHP. This is why patching alone isn’t enough if you were already hit.
- 4
They look around
From the web server they read configuration files, which often contain database passwords, email credentials, API keys, and sometimes VPN or Active Directory details that were pasted in years ago and forgotten.
- 5
They climb
The web server usually runs as a limited user. The attacker’s next job is to become “root” — the all-powerful administrator account — using other unpatched software on the same machine. Once they’re root, that server is fully theirs.
- 6
They move deeper
With root on one machine and a pocket full of stolen passwords, they move laterally: to file servers, to email, to the domain controller, and toward the systems that hold patient data. This phase can take weeks and is designed to be quiet.
- 7
Then you find out
Usually the first visible sign is ransomware: screens lock, the EHR goes down, and you’re diverting ambulances. By then the attacker has been inside for a month, and the website that let them in was never the real goal.
The point isn’t that your website will be defaced. The point is that your website’s server is a computer on your network, and this bug hands a stranger the keys to it.
What to do this week
You don’t need to understand the technical details. You need to ask the right people the right questions and get written answers. Here’s the list.
1. Make a list of every PHP site you own
Main website, patient portal front end, foundation site, intranet, job board, old microsites. Ask each department. Ask marketing. Ask the person who’s been there 20 years.
2. Ask your IT team or host one question, in writing
“What exact PHP version is running on each of these servers, and has it been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619?” If the answer is a version number below the ones in the table above, you are not done.
3. Confirm the service was restarted
Installing the new version isn’t enough; PHP-FPM or the web server has to be restarted so the old, vulnerable code stops running. Ask for the output of php -v after the restart.
4. Check the logs from October 20 onward
Details leaked on the 20th. Ask IT to review web server logs for unusual requests, new or modified files in the web directory, and unexpected processes started by the web server user. If anything looks off, treat it as an incident and get help.
5. If you can’t patch, take it offline
A hospital website being down for a few days is an inconvenience. A ransomware event is a patient-safety crisis. If a server is running PHP 7 or older and can’t be updated quickly, pulling it off the public internet is a reasonable call.
6. Start the conversation about getting off the old stack
This won’t be the last PHP vulnerability. If your website is on an end-of-life version, or if nobody is clearly responsible for keeping the server patched, that’s the real risk — and it’s a fixable one. The section below covers what that looks like.
The permanent fix: stop running a server you have to patch
Patching PHP this week closes this hole. It doesn’t change the underlying situation: your hospital is operating a public-facing server, and someone on your team — or a vendor you hope is paying attention — has to keep it patched forever. For most rural hospitals, that’s not a job anyone was hired to do.
There’s a different model. Content.One runs your website as a managed platform: there is no PHP, no server your IT team owns, and no runtime for an attacker to exploit. Your pages are published to a global CDN, and the platform itself deflects more than 10,000 attacks a day behind actively managed firewalls and rulesets. When the next vulnerability hits — and it will — it’s our problem, not your night shift’s.
Safe now
We can stand up a first draft of your site on Content.One within days, so a vulnerable server can come offline fast instead of waiting on a migration plan.
Safe in the future
No server means no patch cycle. Security, uptime, and infrastructure are handled by the platform, so your IT team can focus on clinical systems.
Nothing lost
Your content, forms, directories, and integrations come with you. Content.One adapts to how your organization already works rather than the other way around.
How a move works
- Discovery — we learn how your site is used and extract your existing content and data.
- Planning — sitemap, content model, and migration plan, tailored to your departments and workflows.
- Build — your new site is built and tested on the platform. You see a working version early, not at the end.
- Launch — DNS cutover, final review, and integrations. The old PHP server gets retired.
For a typical hospital or clinic site, this is weeks, not quarters — and the first working draft arrives within days of the discovery call.
Find out where you stand — today
If your website or digital infrastructure relies on PHP, our team will review your current exposure, explain your risk without the technical jargon, and give you a practical path forward — whether that’s patching what you have or moving to a platform that never needs it.
Book a free security assessment