PHP2Shell and Healthcare Sites: What US Billing Companies Should Do

For the overwhelming majority of websites, the PHP2Shell vulnerabilities were a non-event: the host patched within a day, nobody had to do anything, and that is the end of it.

If your server handles protected health information, it is not the end of it. An unauthenticated remote code execution flaw on a system that touches PHI is a different category of problem from a website outage, and the questions it raises are not ones your developer can answer alone.

We build for US medical billing and RCM companies — four of them are live case studies on this site — so this is the version of the article for that sector.

Correct as of 25 October 2026. This is a fast-moving situation and some of the detail below will have changed. Where it matters, we have said what is confirmed and what is not.

The short version

Patch or confirm your host patched, first. Then establish whether your server was reachable and unpatched during the exposure window, and whether anything in your logs suggests it was touched. An unauthenticated RCE affecting a system with PHI is a risk analysis question under the Security Rule, and potentially a breach assessment question — which is a conversation for your privacy officer and your counsel, not a decision to make from a blog post.

Why this one is different for you

Most website vulnerabilities require something: a login, a specific plugin, a user to click something. These do not. The relevant properties are:

• Unauthenticated. No account needed.
• Remote code execution. The ceiling is not "they defaced a page"; it is "they ran their code on the server".
• Rated 9.2 of 10, and affecting PHP from 5.4 through 8.5.
• Attempts observed before disclosure. Amazon logged an attempt against its honeypots on 17 October, four days before the fix was public.

Palo Alto's Unit 42 documented an incident against a European government entity in which the attacker reached password hashes and multi-factor authentication secrets within roughly two hours of initial access. That is the shape of the risk: not website defacement, but credential access and lateral movement.

If your web server shares an environment with, or holds credentials for, anything that stores patient data, the question "could someone have run code there" matters in a way it does not for a restaurant's brochure site.

What to actually do, in order

1. Establish your patch status and the window

Find out what PHP version your site runs — which, as we explain in checking whether your PHP is really patched, is usually not what php -v tells you — and when your host applied the fix. Most published a timestamp. You want two dates: when the patch landed on your server, and how long before that your server was reachable from the internet running a vulnerable build.

If you are on managed hosting the window is probably hours. If you run your own VPS and nobody has touched it this week, the window is still open right now and that is the emergency.

2. Preserve and review the logs before they rotate

This is the time-sensitive step and it is the one people skip. Access logs on shared hosting commonly rotate within days to weeks. If you may later need to demonstrate that nothing happened, you need the logs from before and during the window, and you need them copied somewhere safe now, not when someone asks in January.

Ask your host for the raw access and error logs covering roughly 15 to 24 October and keep a copy. If you have a WAF or CDN in front of the site, export its logs for the same period.

3. Get a qualified pair of eyes on those logs

We are a web development company, not a digital forensics firm, and we will say plainly that reviewing logs for evidence of exploitation of a specific CVE is forensics work. If your exposure window was meaningful and you hold PHI, that review should be done by someone who does this professionally. Your cyber insurance policy may already include incident response — a lot of practices have that cover and have never looked at it.

4. Rotate what the server knew

If the server was exposed and unpatched for a meaningful period, treat the credentials it held as potentially known: database passwords, SMTP credentials, API keys for clearing houses or practice management systems, and any tokens in configuration files. Rotating these is cheap and reversible. Deciding not to, and being wrong, is neither.

5. Make the breach assessment a documented decision

Under the HIPAA Breach Notification Rule, an impermissible acquisition or disclosure of PHI is presumed to be a breach unless you can demonstrate a low probability that PHI was compromised, through a risk assessment. Whether this situation requires one depends on facts we cannot see: what the server held, whether it was exposed, and what the logs show.

What we can say is that this is a determination for your privacy officer and your counsel to make and document, not something to resolve informally. The documentation matters as much as the conclusion. We are not lawyers and nothing here is legal advice.

What not to do

• Do not announce a breach you have not established. Attempts observed against honeypots on the internet are not evidence that your server was compromised. Panic notifications do real damage to a billing company's client relationships.
• Do not assume you are fine because the site looks normal. The documented incidents involved credential theft, not visible changes.
• Do not let the logs rotate while you decide. Preserving them costs nothing and keeps your options open.
• Do not rely on a vendor's verbal assurance. Get the patch date in writing. You may need it later.

The structural question

The reason this is stressful for a lot of billing companies is not the CVE. It is that the answer to "who patches our web server, and how fast" turns out to be unclear — and that same unclarity is a finding waiting to happen in your next security risk analysis.

If your website and your PHI systems live in the same place, they probably should not. If your site collects anything through a form that could carry patient information, that form should be treated accordingly: encrypted in transit, never relayed in plain text to a personal inbox, with a retention policy behind it. We have written about what an RCM website needs to get right, and the compliance-adjacent parts of it are the parts agencies most often skip.

And to be straightforward about our own limits: we build and maintain these sites, we take the handling of PHI seriously in how we build them, and we will not tell you we are a HIPAA compliance consultancy, because we are not and there is no such thing as a HIPAA certification for a web agency to hold. For the website and hosting side of this — which is the work we do for US clients — tell us what you are running and we will give you a straight assessment.