Table of Contents
How PHP2Shell Puts the Path from Your Website to Your EHR in the Spotlight
On October 21, 2026, Calif.io, Wiz, OpenAI, and Quarkslab disclosed two PHP vulnerabilities, known as PHP2Shell. These security vulnerabilities affect all web servers running PHP 5.4 or later. On an unpatched server, these flaws allow an attacker to cause denial of service, execute remote code, and expose data without ever needing a password. This makes the vulnerability a widespread security concern because PHP is the programming language behind about 70% of the world’s websites.
This security flaw affects healthcare organizations because your website is often where patients request appointments, share intake details, and click through to their electronic health record (EHR) patient portal. Each one of these actions collects personally identifiable information, which becomes personal health information (PHI) when it is connected to healthcare. And all healthcare organizations are required to safeguard PHI under the HIPAA Security Rule.
Put simply, a flaw in the server running your website is as much a compliance question as it is a technical one.
How a Flaw in PHP Reaches Patient-Facing Systems
The majority of healthcare websites are marketing and informational portals. They tell your patients your office hours, your providers, and about your commitment to healthcare. They don’t necessarily hold patient records. healthcare websites are marketing and informational portals. They tell your patients your office hours, your providers, and your commitment to healthcare. They don’t necessarily hold patient records.
But the website does hold access points for patients to enter personal information, including the link patients click to reach their patient portal to request forms, submit intake questions, and even “Pay My Bill” buttons. These buttons often have links that point the patient to another website that does capture their PHI.
The PHP2Shell vulnerability allows an attacker to take control of a vulnerable web server without a username or password. That flaw gets exploited when it is a healthcare website because a bad actor could:
- Send patients to a fake login page that steals their portal credentials.
- Capture information patients submit through website forms, such as appointment requests or intake details.
- Use your trusted website to deliver malware or scam messages to patients.
The interconnected relationship between your website and external websites that may have credential-based access means a vulnerability in one system may expose sensitive data in another. While your organization’s EHR system may be secure, it won’t protect you if the website that links to it is compromised.
Four Questions to Ask About The Security of Your Website
Most healthcare organizations don’t run their own web servers. Who is responsible for the fix depends on how your website is built and hosted. While you may not be responsible for running the server or managing the website, as a covered entity or business associate, you are responsible for safeguarding PHI. The following questions will help you determine what steps to take.
“The PHP risk is particularly concerning since many websites and web-based software applications use PHP; it may only be for one obscure website or an embedded application, but any use must be patched!” – David Ginsberg, President, PrivaPlan
1. Who is responsible for updating PHP on your website?
It’s essential you know the answer to this question. Your website might be managed by the marketing department or an independent web designer. Once you’ve determined who manages your website, it’s time to decide who is responsible for making the PHP security updates.
Websites on a hosting account, such as WordPress, Drupal, or Joomla, are hosted by the provider or maintained by a web agency. These are affected if the server runs PHP. Updating WordPress plugins or its themes does not fix the vulnerability. Your hosting server must update the PHP itself. Many hosting providers are patching their shared servers automatically, but customers who manage their own virtual private or dedicated servers may need to update PHP themselves.
If your site runs on an all-in-one platform, the platform is responsible. For example, Automattic announced that sites hosted on WordPress.com, WordPress VIP, WP Cloud, and Pressable are already protected, with no action needed from customers. That covers sites hosted on those services, but not WordPress sites hosted elsewhere. If you’re on another platform, its status page or support team can confirm where things stand.
As of October 23, 2026, we have not found public statements from Squarespace, Wix, or Square. They likely will not make a statement because their services don’t use PHP. If your site is on one of these platforms, check out the platform’s status page or contact its support team for more information.
2. Do links go to the right place?
Two Risks Remain Even If Your Website Provider Says You’re Protected:
- Your patient portal link: Confirm the EHR patient portal login link still points to the correct address.
- Embedded tools from other vendors: Contact forms, scheduling widgets, intake forms, and payment tools embedded in your site often run on the vendor’s own servers. Each vendor is responsible for its own systems.
Take the time to review the links from your website. Confirm each one lands on the correct, legitimate web address. Next, compare link destinations in the site’s code against a known-good list of approved URLs.
You will also want to check your website for unexpected redirects, pop-ups, “verification” prompts, or scripts that were not added by your team.
3. What do your vendors say?
Your website may host tools from other companies such as contact forms, scheduling widgets, and payment pages. Each vendor runs its own servers and is responsible for its own security. Nevertheless, as part of your compliance, you need to know that they have addressed the security issue.
Contact vendors that host, build, or connect to your website, including:
- the web host
- website agency
- EHR system
- online forms provider
- scheduling or payment vendors
Ask vendors whether they’ve applied the PHP2Shell fixes and have them confirm this in writing. Then save this documentation as part of your compliance records. For vendors who handle PHI, this is exactly the kind of conversation your Business Associate Agreements are built for.
Learn more about who needs a HIPAA Business Associate Agreement in our latest article.
4. Is it written down?
When a website provider tells you they’re protected, your job shifts from patching to documenting. Save the confirmation, note the date, and file it with your security records.
Your Security Risk Analysis is the Map
The organizations moving smoothly through PHP2Shell aren’t lucky. They know which systems they have and which vendors touch PHI. This makes them adaptable to security threats and strong in compliance.
Events like PHP2Shell remind us why the Security Risk Analysis (SRA) matters. The HIPAA Security Rule calls for an accurate, thorough, and current risk analysis. Best practice is to complete one at least annually and again after significant events like this.
A current SRA is the map that makes weeks like this one manageable. It shows your systems, vendors, and exposure before the next headline arrives, so your response is routine, not a scramble.
How PrivaPlan Can Help
Compliance becomes a competitive advantage when you know your safeguards are in place. Our team of HIPAA experts can:
- Review your website and related systems to confirm PHP is patched and your patient portal links are secure
- Help you identify which vendors and business associates to contact, and keep track of their responses
- Guide you through a breach risk assessment and any required notifications, if something comes up
- Perform your annual Security Risk Analysis, including your website and patient portal
We’re here to make compliance work for you. Give us a call at 1-877-218-7707, or email us at info@privaplan.com.
Frequently Asked Questions About PHP2Shell
PHP2Shell is a pair of security flaws in PHP, the programming language that powers many websites, patient portals, and online intake forms. The two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, could let an unauthenticated attacker run their own code on a server. They affect PHP versions 5.4 through 8.5 and were publicly announced on October 20, 2026. The fix is already available. PHP released updated versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) on October 21, 2026, so the practical next step is confirming that your systems, and your vendors’ systems, are running a patched version. It can be, when the affected system creates, receives, stores, or transmits electronic protected health information (ePHI). The vulnerability itself is not a compliance failure. What the HIPAA Security Rule asks is that covered entities and business associates identify reasonably anticipated threats to ePHI and manage them. That means knowing which of your systems run PHP, applying the patch, and recording the review and response in your Security Risk Analysis (SRA). If your patient portal or electronic health record (EHR) is hosted by a vendor, a written confirmation that they have patched is part of the same process. Handled this way, a vulnerability like PHP2Shell becomes evidence of a risk management program that works as intended. It’s important to know who is responsible for PHP security updates to ensure your website remains protected against vulnerabilities. Depending on how your website is hosted, updates may be handled by your hosting provider, web agency, IT team, or website platform. Don’t assume updates are happening automatically. Confirm who is responsible and verify that PHP security updates are being applied promptly. Most EHR and patient portal systems are hosted by the EHR vendor, separate from your public website. The bigger concern is usually the path between them: the link on your website that sends patients to their portal. If that link were tampered with, patients could be sent to a fake login page. Checking the link and asking your EHR vendor to confirm that their systems are protected covers both sides. Document what you find and each out for support. Unexpected redirects, unfamiliar pop-ups, or content your team didn’t add are worth a closer look. Save what you’ve found, avoid deleting anything until it has been reviewed, and contact your IT team or a trusted compliance partner. From there, a structured review can determine whether patient information was involved and what, if anything, needs to happen next.
