PHP2Shell for Healthcare Practices: Patient Forms, HIPAA and Your Website

As of 23 October 2026, PHP2Shell is fixed, exploitation attempts against websites are widely reported, and no public source has documented a confirmed successful compromise. The flaws are not on CISA's Known Exploited Vulnerabilities list as of that date; our PHP2Shell exploitation status tracker follows any change. PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. PHP runs on the server behind most WordPress sites, which is what many medical, dental, therapy and chiropractic practices use for their public website.

The direct answer for a practice: find every web form, portal and tool that collects patient information and runs on PHP, get written confirmation from whoever runs each server that it is on a fixed build and was restarted, and record what you did. The HIPAA Security Rule in force today requires a risk analysis and risk management. A documented PHP2Shell response belongs in that record.

This page is general information, not legal advice. For decisions about your obligations, talk to your compliance officer or healthcare attorney.

How a Practice Website Usually Handles Patient Information

Most practices have a mix of pieces, and only some of them run on a server you or your web company control:

The second row is the one practices most often overlook. A form plugin on a WordPress site is part of that site's PHP application. Whatever a patient types into it passes through the same PHP process that PHP2Shell affects, and stored entries sit on the same server.

Why PHP2Shell Matters for Patient Data

PHP's advisory says both flaws "can allow unauthenticated remote code execution." On an unpatched server, an outsider who never logs in may be able to run commands with the permissions of the web server account. That account can usually read the site's database and uploaded files, including stored form entries.

PHP2Shell also has a memory disclosure side. Wiz, one of the research teams, describes it and says leaked memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself." Beazley Security advises investigators to "treat secrets held by an affected PHP process as potentially exposed." For a practice, those secrets can include the keys your forms use to send email or connect to other systems.

Healthcare is a target in general. Verizon's 2026 Data Breach Investigations Report, covering October 2024 to November 2025, lists 1,492 healthcare incidents, 1,438 with confirmed data disclosure, and "Exploitation of vulnerabilities (20%)" as the top initial access vector for healthcare breaches. That data predates PHP2Shell, so it says nothing about PHP2Shell itself.

What to Do This Week

1. List every system that collects patient information online. Include each form, the portal, any embedded third-party form and any old or secondary site.
2. Ask each host or vendor in writing. Name both CVE numbers. Ask which PHP build serves the system, whether it includes the fix, whether PHP was restarted and on what date. Keep the replies.
3. Check the replies are specific. A patched build can keep an older-looking version number, so look for a build date, package version or changelog entry. Our PHP2Shell fixed versions table lists the upstream and vendor fixes.
4. Retire PHP 8.1 or older. CISA says systems that can't be updated, or that run PHP 8.1 or earlier, should go offline "until they can be patched or updated." If an intake form lives on such a server, move patients to another channel until it is fixed.
5. Review how form entries are handled. Find out whether entries are stored on the web server, emailed in plain text or forwarded to another system, and how long they are kept.
6. Look for signs of trouble from 17 October 2026. That is the date of the earliest reported exploitation attempt. Was my site hacked through PHP2Shell? lists what to check.
7. Write it down. Date, systems checked, vendor answers, fixes applied and anything found. That record is what the next sections are about.

The HIPAA Security Rule in Force Today

The Security Rule at 45 CFR Part 164, Subpart C applies now. Under 45 CFR 164.308, two administrative safeguards are marked Required:

• "(A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information".
• "(B) Risk management (Required)."

A critical, publicly known flaw in the software under your patient forms is a vulnerability your risk analysis should account for. Patching it, confirming the patch and recording both is the kind of risk management step the rule describes. How it fits your own documentation is a question for your compliance officer.

The technical safeguards in 164.312 also apply where a website handles ePHI. They include audit controls that "record and examine activity" and transmission security for data "being transmitted over an electronic communications network." Our guide to website security for service businesses maps each of those to a website.

One common point of confusion: HHS proposed an update to the Security Rule on 6 January 2025. As of October 2026 it is not final. The latest Unified Agenda moves it to "Long-Term Actions" with a final action date of "07/00/2027," and that date has slipped once already. Plan around the rule in force, not the proposal.

Business Associates: Your Host, Form Vendor and Web Company

HIPAA's definition of a business associate in 45 CFR 160.103 includes a person who, on behalf of a covered entity, "creates, receives, maintains, or transmits protected health information." It also covers subcontractors that do the same for a business associate.

So whether your web host, form vendor or web company is a business associate depends on whether it handles PHI for you. A form vendor that stores intake answers may be one. A web company with access to stored form entries may be one. Whether a business associate agreement is needed, and what it should say, is for your compliance advisor. For PHP2Shell, the practical step is the same either way: ask each vendor that touches patient data what it did, in writing. Our shared responsibility model guide explains who usually secures which layer.

Platform choice matters too. Webflow, for example, says it "is not HIPAA compliant by default and is not designed to store or process protected health information." Read your own platform's terms before collecting patient information through it.

If Patient Information May Have Been Exposed

HIPAA's breach rules are in 45 CFR Part 164, Subpart D. In summary, and as general information only:

The four factors include "Whether the protected health information was actually acquired or viewed." That is why evidence matters. Before anyone restores or rebuilds a suspect server, preserve the web, PHP and server logs, as Beazley advises. Our website incident response plan covers the first hour. Breach reports go to HHS through the OCR breach portal. The portal itself notes it "will be offline for maintenance from Fri Oct 23 10:00 PM EDT to Sat Oct 24 12:00 PM EDT."

State breach laws can also apply alongside HIPAA. Ask your attorney which ones reach you.

Practice Checklist

Conclusion

For a healthcare practice, PHP2Shell is a server fix with a paperwork trail. Find every form and tool that touches patient information, get written confirmation of fixed PHP and a restart for each one, check for signs of trouble from 17 October and record it all as part of your risk management. If a form runs on a server nobody can vouch for, our emergency PHP patching service can confirm the fix and preserve evidence before anything is rebuilt. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions