The PHP Warning Is a Vendor Problem: Where Is Your Data?

Your patients' records are sitting on servers you have never seen. Some of those servers belong to vendors you stopped paying years ago. This week, federal agencies told everyone running PHP, the software behind roughly 7 in 10 websites, to patch immediately or pull the plug.

Do you know which of your vendors got that message?

What did the government actually say?

On October 21, 2026, the team behind PHP released fixes for two critical security flaws. PHP is the software behind roughly 7 in 10 websites. (Source: W3Techs, 69.3 percent of sites with a known server-side language, October 21, 2026.) It runs WordPress and many patient forms. (Source: php.net.)

CISA told organizations to patch immediately. Organizations that cannot "should take PHP-based systems offline until they can be patched or updated." (Source: CISA.) NSA said the same, and warned these flaws "often provide a direct path to the server's file system or database." (Source: NSA.)

That is all the technology you need. The rest of this is about you.

Does this affect you if you do not run any servers?

Yes. I hear "we do not run PHP, our vendors handle IT" every week. I get it. You are running a practice, and IT is not your job.

But "do we run PHP?" is the wrong question. The right question is "where is our patient data, and who has it?"

For most practices, the answer is a long list. The EHR. The billing company. The patient forms tool. The website host. The marketing agency. The transcription service. The IT company. The consultant from three years ago. The scheduling app a staff member signed up for with a work email.

Any one of them could be running PHP on the server that holds your patients' records. You cannot answer "are we affected?" until you know who they are.

That list has a name in HIPAA. It is your risk analysis, and it is Required: "an accurate and thorough assessment of the potential risks and vulnerabilities" to the electronic protected health information you hold. (Source: 45 CFR 164.308(a)(1)(ii)(A).) HHS says it covers all of your ePHI "regardless of the particular electronic medium" or "the source or location." (Source: HHS, Guidance on Risk Analysis.) Location includes your vendors.

Is a BAA in place with every vendor that holds your data?

Every vendor, consultant, and third-party app that creates, receives, maintains, or transmits your patients' information needs a business associate agreement first. The written contract is Required, not addressable. (Source: 45 CFR 164.308(b); 45 CFR 164.502(e); 45 CFR 164.504(e).)

The middle of a vendor breach is not the time to go looking for it.

The BAA decides what happens next. HHS allows a vendor up to 60 days after discovering a breach to tell you. (Source: 45 CFR 164.410.) The BAA you sign sets the actual window, and each one can differ. HHS confirms a BAA may require faster reporting. (Source: HHS, Guidance on HIPAA & Cloud Computing, question 6.) No BAA, no agreed window. What a good one contains is in Business Associate Agreements, Explained.

Your vendor's vendors count too. If your forms company stores data with a hosting company, your forms company must have its own agreement with that host. (Source: 45 CFR 164.502(e)(1)(ii).)

OCR has enforced this against small practices. The Center for Children's Digestive Health paid $31,000 after neither it nor its records-storage vendor could produce a signed BAA for years of shared records. (Source: HHS, April 20, 2017.)

What about the vendor you stopped using in 2019?

This is the part almost nobody checks.

You switched forms companies. You let the old IT contract lapse. You stopped paying the marketing agency that built the old site. Ending the service did not end the data. If that company still holds your patients' records, it may still be running them on a server nobody has patched in years.

HHS is direct about this. A vendor that maintains your ePHI is a business associate, and it stops being one only once it securely returns or destroys that data. (Source: HHS, Guidance on HIPAA & Cloud Computing, question 5.)

Your BAA must require exactly that. At termination, the vendor must return or destroy all PHI "if feasible." If that is not feasible, the agreement's protections must extend to the data, and further uses must be limited. (Source: 45 CFR 164.504(e)(2)(ii)(J).)

So ask yourself one question. Did you get it in writing that the data was returned or destroyed?

If not, that data is still yours to answer for. Three reasons, stated carefully:

• Your patients, your letter. If a former vendor has a breach of your patients' unsecured information, the duty to notify those patients is the covered entity's. (Source: 45 CFR 164.404(a).) Patients see your name on the letter, not the vendor's.
• What you knew matters. If you knew of a pattern of activity by a business associate that materially breached its agreement, you must take reasonable steps to cure it, and end the arrangement if that fails and termination is feasible. (Source: 45 CFR 164.504(e)(1)(ii).)
• Agents. When a business associate acts as your agent, you can be liable for civil money penalties based on its acts or omissions within the scope of that agency. (Source: 45 CFR 160.402(c).)

None of that is a reason to panic. It is a reason to close the loop.

What did you stop using yourself?

Vendors are half of it. The other half is the stuff you retired but never deleted. The old intake site. The portal you replaced. The old EHR server in the closet, kept just in case. Backups of all of them.

Decommissioned is not deleted. Disposal of ePHI and the media it sits on is Required. (Source: 45 CFR 164.310(d)(2)(i).)

Vision Upright MRI, a single-location imaging practice in California, is the lesson here. An unsecured server exposed the medical images of 21,778 people, and OCR found the practice had never conducted a risk analysis. Its corrective action plan requires "a complete inventory of all electronic equipment, data systems, off-site data storage facilities, and applications that contain or store ePHI." (Source: HHS resolution agreement.)

What does your paperwork say you have?

One more place this shows up: your cyber insurance application.

I have watched a multi-state home health organization lose most of a cyber insurance claim after a ransomware attack, because its application described controls it did not actually have. The gap between what your paperwork says and what is true stays invisible until the day it is exposed. If your application says you manage your vendors, this week is a good time to make that true.

Five calls to make this week

You do not need to understand PHP to do any of these.

1. Call or email every current vendor that touches patient data. Ask in writing: do you run PHP on any system that holds our data, and is it patched or offline?
2. Pull every BAA. Match each one to a vendor on your list. Any vendor without one is your first fix.
3. List your former vendors. For each, request written certification that your data was returned or destroyed.
4. Find what you forgot. Old websites, old portals, old servers. Your billing records will show domains and hosting you are still paying for.
5. Update your risk analysis with everything you learned. That document is your proof.

So, are you confident you know where your patients' data is today?

Most owners I talk to are not. That is not a failing. Nobody hands you this list when you open a practice.

The PHP warning will fade from the news. The list is what protects you the next time, and there will be a next time.

That is what our risk analysis work is for: every system and vendor that touches your patients' data, every BAA, and every former vendor closed out in writing. We have done this since 2010 for 500+ healthcare organizations under 1,000 employees, with a 100 percent audit success rate. Audit-ready in 60 days, or we keep working at no additional cost until you are.

Get My Audit-Readiness Score and see where your vendor gaps are.