A dental practice may have invested in antivirus software, secure email, encrypted backups, and HIPAA compliance.

Its clinical workstations may be professionally managed. Its electronic health record system may be hosted by a reputable vendor. Its network may be protected by a firewall.

But what about the practice’s website?

What about the patient intake portal, online appointment system, document upload application, or third-party web server?

And who is responsible for ensuring the underlying software supporting these systems is secure?

These questions have become especially important following the disclosure of PHP2Shell vulnerability, two critical vulnerabilities affecting PHP, one of the world’s most widely used server-side programming technologies.

On October 21, 2026, the PHP project disclosed two vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, each assigned a critical CVSS v4.0 score of 9.2.

Under vulnerable conditions, attackers may be able to execute commands on affected servers without possessing valid login credentials.

The vulnerabilities (PHP2Shell vulnerability) affect PHP itself—not merely a particular website plugin or application.

PHP is commonly used to power WordPress websites, content-management systems, custom business applications, and integrations.

For healthcare and dental practices, this raises a broader concern:

A practice can have well-protected clinical workstations and still face significant cybersecurity exposure through a vulnerable website or third-party application.

The PHP development team has released security updates and strongly recommends immediate patching.

This Velocis advisory explains what PHP2Shell is, which systems may be affected, what the business consequences could be, and what healthcare leaders should require from their IT and hosting providers.

1. What Exactly Is PHP2Shell / PHP2Shell vulnerability?

PHP2Shell is the name used for two serious vulnerabilities in the PHP runtime—the underlying software responsible for executing PHP application code on web servers.

The two vulnerabilities are:

Vulnerability	Technical issue	Severity
CVE-2026-109618	Memory corruption during out-of-memory error handling	Critical — 9.2
CVE-2026-109619	Stale internal state and use-after-free conditions	Critical — 9.2

Both weaknesses concern how PHP handles internal memory and request processing when certain abnormal conditions occur.

An attacker may be able to send specially crafted HTTP requests that trigger unsafe memory behavior and potentially gain the ability to execute commands on the affected server.

The risk is particularly serious because exploitation may not require authentication.

That means an attacker potentially does not need a username, password, or existing account to attempt the attack.

CrowdStrike’s technical analysis describes how these vulnerabilities affect core PHP runtime behavior and how exploitation could create an opportunity for remote code execution.

What does remote code execution actually mean?

Remote code execution, or RCE, means an attacker may be able to cause the vulnerable server to execute unauthorized commands.

Depending on the server’s configuration and the privileges available to the compromised process, an attacker could potentially:

• Access application configuration files.
• Retrieve database connection credentials.
• Modify website content.
• Install unauthorized scripts or web shells.
• Access information stored or processed by the application.
• Establish persistence for subsequent access.
• Attempt to reach other systems connected to the server.
• Disrupt the application or service.

Importantly, remote code execution does not automatically mean an attacker has full administrator access or that patient records have been stolen.

The consequences depend on the privileges of the affected process, the application’s design, network access, and other protections.

Nevertheless, a successful server compromise can provide an attacker with an important foothold.

Why this vulnerability (PHP2Shell vulnerability) is different from an ordinary WordPress plugin issue

Many website vulnerabilities originate in third-party plugins or themes.

In those cases, updating or removing the affected plugin may address the immediate vulnerability.

PHP2Shell is different.

The vulnerabilities exist in PHP’s underlying execution environment.

Therefore, updating WordPress, its themes, and its plugins is not sufficient if the website continues running a vulnerable PHP version.

The underlying runtime must also be updated or receive an equivalent vendor-supplied security fix.

2. Which PHP Versions Are Affected?

The PHP project released patched versions on October 21, 2026.

Organizations should verify that their environments are using these releases or an equivalent security-fixed package supplied by their operating-system or application vendor.

PHP Branch	Vulnerable Versions	Fixed Version
PHP 8.5	Before 8.5.12	8.5.12
PHP 8.4	Before 8.4.27	8.4.27
PHP 8.3	Before 8.3.36	8.3.36
PHP 8.2	Before 8.2.35	8.2.35
PHP 8.1 and earlier	Unsupported versions are affected	Upgrade to a supported, patched branch

Source: Official PHP security release and NHS England’s October 21, 2026 cyber alert. 

An important qualification: some Linux distributions and commercial vendors backport security fixes without changing the displayed upstream PHP version to the exact number above.

Consequently, an older-looking version string is not always conclusive evidence of vulnerability. Providers should supply the relevant package build, vendor advisory, or patch evidence.

Likewise, a fixed version number is necessary evidence of remediation but does not prove that a server was never compromised before patching.

What about PHP 8.1 and older?

Older unsupported branches deserve special attention.

A medical practice might still have a legacy website or patient-facing application that depends on an outdated PHP release.

In these cases, simply asking whether automatic updates are enabled is not enough.

The business should ask its service provider whether the application can be migrated to a supported PHP release and what compensating controls are necessary until migration is complete.

3. Which Healthcare and Dental Systems May Be Exposed?

PHP2Shell vulnerability does not exclusively target healthcare.

However, healthcare organizations commonly depend on externally hosted applications and service providers, making it important to determine where PHP is used.

Potentially relevant systems include:

Practice websites

Many medical and dental practices operate WordPress-based websites.

These may contain appointment request forms, practice announcements, physician biographies, contact information, educational content, and patient inquiries.

A vulnerable PHP runtime supporting the website may expose the server, regardless of whether the visible website appears to function normally.

Patient intake and online forms

Some practices use custom web forms for registrations, health histories, insurance details, referrals, or appointment requests.

Where these applications are built with PHP, the underlying hosting environment must be checked.

The impact can be more serious when the application processes sensitive patient information.

Patient portals and specialty applications

Certain patient-facing systems and custom integrations may use PHP.

However, not every patient portal or electronic health record system uses PHP.

The appropriate response is to identify the technology in use and obtain a vendor-specific statement of applicability.

Dental practice websites and integrations

Dental practices may operate several interconnected services, including website appointment forms, patient communication tools, financing applications, payment systems, and document collection systems.

Even if the primary practice-management software does not use PHP, an associated website or custom integration might.

Third-party hosted applications

A hosting company, MSP, marketing agency, web development firm, or SaaS vendor may manage the application infrastructure.

That does not eliminate the need for verification.

It changes who must provide technical evidence that the vulnerability has been assessed and addressed.

Internal PHP applications

Although internet-facing systems deserve immediate priority, internal PHP applications should not be ignored.

A vulnerable internal application could become an additional attack opportunity after an attacker gains access through another route.

The key point: Exposure is determined by the technology and its configuration—not by the type of business using it.

4. Why Should Healthcare and Dental Practices Be Concerned?

A vulnerable website does not automatically mean that an organization’s clinical systems or patient databases are exposed.

However, a successful attack against a connected application could create consequences far beyond the website itself.

For healthcare leaders, the risks fall into several important categories.

Patient information and confidentiality

Consider a dental practice that uses a custom website form to collect patient registration information, insurance details, or medical histories.

If an attacker compromises the application server, the attacker may be able to access information processed or stored by the application.

Depending on the architecture, this could include database credentials, application files, uploaded documents, or sensitive records.

If electronic protected health information is involved, the organization may need to evaluate its obligations under HIPAA.

The important distinction is that a vulnerable server creates potential exposure; an actual breach determination requires evidence and investigation.

Operational disruption

A website or patient-facing service can be an important business system.

If an attacker compromises it, the organization could experience unavailable appointment requests, interrupted online intake, fraudulent website redirects, or compromised forms.

If the server also supports other business applications, the operational impact could be greater.

For a busy medical or dental practice, even a relatively short interruption can affect scheduling, staff productivity, and patient communications.

Ransomware and lateral movement

A compromised PHP server could potentially provide attackers with an initial foothold.

They may attempt to retrieve credentials, discover connected resources, or move toward other systems.

Whether that is possible depends on the environment’s segmentation, permissions, and network architecture.

For example, a website hosted separately by a third-party provider may present a different level of risk from a PHP application running on a server directly connected to the practice’s internal network.

This is why network isolation and least privilege matter.

Website manipulation and patient trust

Attackers controlling a web application may attempt to alter website content, create fraudulent pages, redirect visitors, or insert malicious code.

Patients may continue trusting the website because it uses the practice’s legitimate domain.

For a healthcare business, the resulting damage could involve reputational harm, fraudulent communications, and loss of patient confidence.

Regulatory and contractual exposure

If a PHP2Shell incident results in unauthorized access to ePHI, HIPAA’s Security Rule, Breach Notification Rule, and applicable contractual obligations may become relevant.

The organization may need to preserve evidence, investigate the scope, perform a breach-risk assessment, and determine notification obligations.

Not every exploited server creates a reportable HIPAA breach. The facts—including whether PHI was involved—must be evaluated.

Nevertheless, relying entirely on a service provider without independently understanding its responsibilities can leave important governance gaps.

5. Is PHP2Shell Actively Being Exploited?

As of October 28, 2026, security advisories report exploitation attempts against the vulnerabilities.

Singapore’s Cyber Security Agency reported widespread exploitation attempts, while Sophos cited an attempt observed as early as October 17, before public disclosure. 

However, there is an important distinction between attempted exploitation, a proof-of-concept that causes a crash, and reliable remote code execution in a real-world environment.

CrowdStrike’s October 23 analysis concluded that technical obstacles could constrain immediate widespread weaponization. Some public demonstrations established crashes or memory-corruption behavior without demonstrating a reliable server takeover. 

The practical conclusion for healthcare leaders is clear:

• These are critical vulnerabilities requiring urgent remediation.
• Exploitation attempts have been reported.
• Not every vulnerable PHP installation is equally exploitable.
• Successful exploitation of a particular healthcare organization should not be assumed without evidence.
• A clean vulnerability scan does not necessarily establish that a server was never compromised.

Organizations should avoid both extremes: unnecessary panic and complacency.

An additional PHP security development

On October 23, PHP published information about a related session-upload-progress issue, CVE-2026-115560, involving an unusual application configuration.

The issue may remain relevant even on PHP releases patched for the original two PHP2Shell vulnerabilities. The PHP team recommends disabling session.upload_progress.enabled in certain circumstances while awaiting a subsequent fix.

The PHP team describes the conditions as unusual and involving specific session-serialization behavior. Service providers should review applicability rather than assuming the additional issue affects every PHP application. 

6. What Should a Healthcare Business Leader Do Immediately?

The business owner, CEO, practice administrator, or compliance officer does not need to become a PHP developer.

However, they should ensure that the responsible technical personnel have identified the exposure, completed remediation, and documented the results.

The following checklist is designed for healthcare practices, dental clinics, and organizations relying on external IT or hosting providers.

PHP2Shell Executive Action Checklist

Track your organization’s readiness

Check each action once it has been completed and supported by evidence.

Actions completed

0 / 14

[ ] 1. Confirm ownership — Identify the person or company responsible for each website, portal, and PHP-based application.
[ ] 2. Inventory affected systems — Review websites, patient forms, custom integrations, internal applications, and third-party hosting.
[ ] 3. Verify PHP versions — Obtain active runtime versions and vendor patch/build evidence.
[ ] 4. Apply security fixes — Verify remediation for CVE-2026-109618 and CVE-2026-109619.
[ ] 5. Check related PHP advisory — Review CVE-2026-115560 and relevant PHP configuration mitigations.
[ ] 6. Review external exposure — Prioritize internet-facing systems and document any necessary temporary restrictions.
[ ] 7. Validate security monitoring — Confirm WAF, server, and appropriate workload detection coverage.
[ ] 8. Review possible compromise — Analyze relevant logs and investigate suspicious activity since the potential exposure period.
[ ] 9. Check credentials and connections — Review application secrets, database accounts, permissions, and network access.
[ ] 10. Validate backups — Ensure recoverable copies and tested restoration procedures exist.
[ ] 11. Assess HIPAA implications — Determine whether ePHI is processed and whether any incident warrants a formal review.
[ ] 12. Obtain written attestation — Request a dated, system-specific response from the IT, hosting, or software provider.
[ ] 13. Assign accountability — Track exceptions, remediation owners, deadlines, and final approval.
[ ] 14. Plan ongoing monitoring — Confirm responsibility for future PHP security advisories, patching, and vulnerability assessments.

Completing the checklist should not be treated as a certification that an environment is secure. It provides an accountability framework for the technical assessment.

7. What Should You Ask Your IT Service Provider?

This may be the most important section for small and midsize healthcare organizations.

Many practices outsource website development, hosting, cloud operations, and day-to-day IT management.

That is often necessary and appropriate.

However, outsourcing the technical work does not remove the organization’s need to understand the risks associated with its systems and protected information.

A verbal assurance that a website is secure is not enough.

Healthcare leaders should request written answers to specific questions.

Question 1: Are any of our systems running PHP?

Ask the provider to review websites, patient-facing portals, custom business applications, and other managed infrastructure.

The answer should distinguish between systems running PHP and systems that do not use it.

Question 2: Are we affected by PHP2Shell?

Request explicit confirmation addressing both:

• CVE-2026-109618
• CVE-2026-109619

A response stating that WordPress is up to date does not fully answer this question.

Question 3: What PHP versions are currently running?

Ask for the active versions associated with each relevant production application.

If the provider uses vendor-maintained packages with backported security fixes, request documentation identifying the fixed package.

Question 4: Have the security updates been applied?

Request the patch completion date and confirmation that the updated runtime is active—not merely installed.

Question 5: Are any unsupported PHP versions still in use?

If so, obtain a remediation or migration plan with clear deadlines.

Question 6: Have you checked for evidence of exploitation?

The provider should explain the scope of its review.

Depending on the environment, this may include web-server logs, PHP errors, abnormal process activity, suspicious file changes, and unexpected outbound connections.

Question 7: Is our website protected by a Web Application Firewall?

If a WAF is deployed, ask whether relevant rules are enabled, what traffic is covered, and whether bypass paths exist.

A WAF can help reduce exposure to known attack patterns, but should not replace patching.

Question 8: Are our PHP servers monitored by EDR or other workload-security controls?

Clarify whether the relevant servers are monitored—not simply office desktops and laptops.

If the provider uses a managed hosting platform without traditional EDR agents, ask what equivalent workload, platform, or server-side monitoring is available.

Question 9: Could the affected application access patient information or internal systems?

Ask whether the application processes or stores ePHI and whether it has access to databases, internal networks, shared credentials, or connected applications.

Question 10: Can you provide a written confirmation?

The provider should provide a dated response showing the systems reviewed, findings, remediation completed, any unresolved exposure, and the person responsible for follow-up.

8. Suggested Email to Your MSP, Hosting Company, or Website Developer

Healthcare organizations can send the following message directly to their service providers.

Hello,

We are requesting an urgent review of our website, hosting environment, patient-facing applications, and any other systems managed by your organization in light of the recently disclosed critical PHP2Shell vulnerabilities:

• CVE-2026-109618
• CVE-2026-109619

Both vulnerabilities have been assigned a critical CVSS v4.0 score of 9.2 and may allow unauthenticated remote code execution on affected PHP systems.

Please provide written confirmation addressing the following:

1. Whether any systems or applications supporting our organization use PHP.
2. The affected assets and their current PHP versions or vendor-maintained package builds.
3. Whether the required security patches have been applied, including patch dates.
4. Whether any unsupported PHP versions remain in use.
5. Whether your team has reviewed relevant logs and security telemetry for possible exploitation.
6. Whether applicable WAF, server, and workload security controls are active.
7. Whether any exposed applications process patient information or connect to sensitive internal systems.
8. Whether you have evaluated the additional PHP session-upload-progress advisory, CVE-2026-115560.
9. Any outstanding risks, compensating controls, and remediation timelines.

If our environment is not affected, please confirm the technical basis for that determination.

As a healthcare organization, we would appreciate a written response identifying the systems reviewed, the status of remediation, and any follow-up action required from our team.

Please treat this as a priority security request.

Thank you.

Recommended practice: Ask for an initial response within one business day, with critical internet-facing exposure addressed urgently. If a provider cannot complete remediation immediately, request a documented interim risk-reduction plan and specific remediation deadline.

9. What Does a Meaningful Service-Provider Attestation Look Like?

An assurance such as “We are protected” provides little information about what was actually checked.

A useful attestation should include evidence and clear scope.

Required element	What to look for
Provider identity	Company and responsible technical contact
Systems reviewed	Websites, domains, hosting instances, relevant applications
Applicability	Whether PHP2Shell affects each system
PHP runtime status	Active versions or vendor patch identifiers
Remediation	Fixes applied and completion dates
Security review	Logs and activity examined
Findings	Vulnerable assets, suspected compromise, or no findings
Exceptions	Outstanding issues and compensating controls
Follow-up	Responsible owner and target completion date

Providers should avoid unqualified statements asserting that an environment is entirely safe.

A more meaningful conclusion is that the specified assets were assessed against the identified vulnerabilities, defined remediation actions were completed, and the stated security checks did or did not identify suspicious activity.

That distinction supports both cybersecurity governance and future incident investigation.

10. What If Your Provider Says the Website Is Protected by Cloudflare or Another WAF?

A Web Application Firewall can be a valuable layer of defense against malicious HTTP traffic.

Cloudflare, for example, published PHP2Shell-specific rules and mitigation information following the disclosure. 

However, several questions remain important.

Does the WAF protect every relevant hostname and application?

Can attackers reach the origin server without passing through the WAF?

Are the specific rules enabled and configured correctly?

Are logs being reviewed?

Have the underlying PHP vulnerabilities been patched?

The PHP project’s advisory makes clear that patching is the definitive remediation for the two original vulnerabilities; temporary measures do not provide a complete substitute. 

WAF protection is useful. Verified patching is essential.

11. What If the Website Is Already Compromised?

If suspicious activity suggests successful exploitation, the organization should treat the situation as a potential security incident rather than simply a patching exercise.

Patching a vulnerable server does not automatically remove an attacker who has already established persistence.

The response should include four stages.

Contain

Restrict further attacker access while considering business continuity and preserving evidence.

Depending on the environment, containment may involve isolating the affected workload, restricting inbound access, or temporarily taking the application offline.

Preserve

Collect relevant evidence before rebuilding or deleting systems.

Important evidence may include web-server and reverse-proxy logs, PHP error logs, filesystem and database snapshots, process telemetry, authentication events, and suspicious files.

Investigate

Determine whether the vulnerability was exploited, which permissions were obtained, whether files or credentials were accessed, and whether additional systems were affected.

Recover

Restore the application from verified clean sources, apply security fixes, remove persistence, rotate compromised credentials, and validate the environment before returning it to normal operation.

For healthcare organizations, an investigation should also determine whether ePHI was involved and whether further compliance or notification review is required.

12. PHP2Shell and HIPAA: What Business Leaders Must Understand

HIPAA does not require organizations to respond to every vulnerability in exactly the same technical manner.

However, the Security Rule requires covered entities and business associates to assess risks and implement appropriate safeguards for electronic protected health information.

A critical vulnerability affecting an application that processes ePHI is therefore relevant to the organization’s risk management.

Healthcare leaders should be able to establish whether the vulnerable application was within the scope of systems handling ePHI, whether the exposure was assessed, what remediation occurred, and whether any suspected compromise was investigated.

In the event of a security incident, documentation becomes particularly important.

Where a breach of unsecured PHI is determined, applicable notification requirements must be evaluated.

A vulnerable PHP installation is not automatically a HIPAA violation or reportable breach. The compliance implications depend on the actual circumstances and the organization’s obligations.

Nevertheless, failing to assess and address a known critical vulnerability affecting a sensitive system could create substantial security and compliance concerns.

Relevant authoritative resources include the HHS HIPAA Security Rule and HHS Breach Notification Rule.

13. A Practical 72-Hour Response Plan for Healthcare Executives

The following is a recommended management response framework, not a guarantee that every environment can be fully remediated within 72 hours.

Time frame	Leadership action	Expected evidence
First 24 hours	Notify providers, inventory PHP applications, identify exposed systems, prioritize critical remediation	Asset list, applicability statement, initial patch status
24–48 hours	Verify fixes, review logs, investigate anomalies, assess connected PHI systems	Patch evidence, security-review results, documented exceptions
48–72 hours	Review residual risk, confirm monitoring and backups, receive written attestation	Provider report, remediation plan, owner and deadlines

If credible evidence of compromise exists, incident-response activity should begin immediately, without waiting for this schedule to finish.

14. The Bigger Problem: Who Is Responsible for the Security of Your Website?

PHP2Shell highlights a wider problem affecting small and midsize healthcare businesses.

Responsibility for cybersecurity may be divided among several providers.

A web design agency maintains the website.

A hosting company manages the server.

An MSP protects office computers and the network.

A software company supports the EHR.

A separate vendor manages online forms.

Each provider may reasonably believe another organization is responsible for PHP patching, server security, or incident monitoring.

This can create an accountability gap.

The practice owner may assume that everything is covered because the organization pays several technology vendors.

But without clearly defined responsibility, important systems may fall between contracts.

Healthcare organizations should therefore establish a simple responsibility model for every critical system.

For each application, identify the service owner, hosting provider, party responsible for patching, party responsible for monitoring, incident contact, and person accountable for approving remediation.

This is not only about PHP2Shell.

It is a sustainable control for managing future vulnerabilities.

15. How Velocis Technologies Can Help

Velocis Technologies helps healthcare organizations and dental practices translate cybersecurity concerns into actionable assessments, remediation plans, and security operations.

For PHP2Shell, relevant capabilities include:

External Attack Surface Management

Identify internet-facing applications and externally visible systems requiring investigation.

Vulnerability Assessment

Evaluate affected PHP runtimes, relevant application dependencies, and remediation status.

Endpoint and Workload Security

Assess appropriate detection coverage for exposed server workloads.

Managed Security Operations

Review available security telemetry and investigate suspicious activity.

Digital Forensics and Incident Response

Support containment, evidence preservation, investigation, and recovery when compromise is suspected.

Healthcare Security and HIPAA Risk Management

Connect technical findings with business impact, protected information, and risk-management responsibilities.

Velocis can also help business leaders independently evaluate the technical assurances provided by their existing MSP, hosting provider, or website developer.

This can be particularly valuable when a practice does not have its own cybersecurity leadership or internal security operations team.

The Bottom Line for Healthcare and Dental Practices

PHP2Shell is a serious vulnerability that deserves attention.

But the most important action for a healthcare executive is not to learn the technical details of PHP memory management.

It is to establish clear answers to four questions:

1. Are any of our systems affected?

2. Have the vulnerabilities been remediated?

3. Have the relevant systems been reviewed for possible compromise?

4. Can our service provider document what was checked and what was done?

If those questions cannot be answered, the organization may have a cybersecurity visibility and accountability problem that extends beyond PHP2Shell.

Healthcare cybersecurity must protect more than computers and websites.

It must support the confidentiality of patient information, the availability of critical systems, and the operational resilience of the organization.

Request a Velocis PHP2Shell Exposure Assessment

A Velocis assessment can help healthcare and dental practices establish whether relevant systems may be exposed, review remediation evidence, evaluate potential compromise, and determine next steps with their technology providers.

Velocis Technologies — Cybersecurity & Incident Response

velocistech.com

info@velocistech.com

903-436-4044

Schedule a cybersecurity consultation

Additional resource: Velocis Healthcare Cybersecurity Readiness Checklist