The PHP vulnerability and OpenEMR: what those who run it need to know and do

If your clinic, laboratory or project runs OpenEMR, you have an urgent task this week: upgrade PHP. On October 21, 2026 the PHP project released emergency patches for two critical flaws that allow unauthenticated remote code execution. OpenEMR is written in PHP, so every installation exposed to the internet is, by default, a target.

In this article we explain what the vulnerability is, what OpenEMR is (along with its derivative AIOTP, PAHO's "All in One" platform) and what concrete actions those who run it should take today.

What PHP2Shell is

PHP2Shell is the name the security community gave to two vulnerabilities in the PHP core: CVE-2026-109618 and CVE-2026-109619. Both are rated critical, 9.2 in CVSS v4.0, and let an attacker without credentials run code on the server with the privileges of the web process.

The first flaw is in out-of-memory error handling: if PHP runs out of memory while preparing a request's data, that data is left half-initialized and later treated as valid. The second happens because PHP keeps state from a request after freeing its memory; if the same process serves the next request, it can read that stale state. This second path also allows memory leaks, which can expose passwords, tokens, API keys and certificates.

What makes this case especially serious:

• It does not depend on the application. The bug is in the interpreter, not in WordPress, Drupal or OpenEMR. According to PHP, every installation that serves web requests is at risk: PHP-FPM, Apache with modphp, php-cgi, FrankenPHP and LiteSpeed. With modphp the attack can happen before a single line of application code runs.
• Broad historical reach. It affects PHP 5.4 through 8.5.11.
• It leaked before the patch. Details circulated on October 20, ahead of coordinated disclosure; PHP moved publication up to October 21 and detailed technical analyses appeared that same day.
• Unsupported versions are left out. PHP 8.1 and earlier will not get an official patch.

Sources: Huntress, Google Cloud.

What OpenEMR is

OpenEMR is the best-known open source electronic health record (EHR) in the world: a free web application, written in PHP on MySQL/MariaDB, that brings together the clinical record, scheduling, billing and a patient portal. It has more than two decades of community development and is maintained by a community of volunteers and service provider companies.

Its most relevant capabilities for those of us working in interoperability:

• ONC certification in the United States (2015 Cures Update). Certification for version 7 was withdrawn on February 27, 2026; the certified branch today is OpenEMR 8.
• FHIR R4 API aligned with US Core, and SMART on FHIR for third-party app authorization.
• Clinical and administrative modules: e-prescribing, quality reporting (eCQM), social determinants of health, X12 billing, telehealth and a patient portal.
• Internationalization: translated into dozens of languages, including Spanish, and used in clinics in many countries.

In Latin America it also has institutional backing: the IDB lists it in its catalog of open source solutions and it is a digital public good recognized by the Digital Public Goods Alliance. That is why it is a frequent choice for private clinics, NGOs, academic projects and digital health pilots in the region.

That same popularity is what makes it an attractive target: an EHR concentrates health, identity and billing data, exactly what an attacker values most.

Why OpenEMR is directly exposed

OpenEMR uses PHP sessions and allows file uploads (clinical documents, images, consent forms). According to OpenEMR's official advisory of October 21, any site with sessions or file uploads enabled, both on by default, is exploitable. The same advisory says the vulnerability is already being exploited and that public proof-of-concept code exists.

This 42-second silent video shows what the attack against an internet-exposed PHP EHR looks like: the attacker spots a vulnerable version, sends a crafted request and gets a shell with no username or password. It is an illustrative, conceptual animation; it contains no real exploit. The on-screen text is in Spanish.

You can also watch it on its own page: PHP2Shell: how the attack works.

How many installations are in plain sight

A query to Shodan, the search engine for internet-connected devices, found 1,386 OpenEMR servers visible from the internet on October 21, 2026, across 46 countries. 62% are in the United States, and most run on public clouds. Censys, another search engine of the same kind, counted 487 that day by page title, with the same pattern: 70% in the United States. The figures do not add up, because each engine indexes differently.

The same search returned 405 honeypots imitating the OpenEMR page. These are traps that researchers and security teams typically set up to observe attackers, and their number shows that OpenEMR is already under active watch. In China, moreover, nearly all results not tagged as honeypots follow the same pattern: setup pages on public clouds and random ports. Censys finds only 13 servers in China.

Latin America and the Caribbean show only 28 servers in Shodan and 8 in Censys, but that says little about the real risk:

The tricky part is the official Docker images, which is how most installations are deployed today. The fix depends on the Alpine Linux version each image was built on:

Three details that may surprise an operations team:

• Pulling the latest image is not enough. The published 8.4.x image was built before the patch, so a docker pull still delivers vulnerable PHP.
• A patch applied inside the container is fragile. It lives in the writable layer: a docker compose down or up --force-recreate reverts it. Use restart.
• The project's build pipeline was stalled by an Ubuntu/Launchpad repository outage, so rebuilt images may take a while.

Installations outside Docker (operating system packages, XAMPP on Windows, shared hosting) depend on the pace of their distribution or hosting provider. Those still running PHP 7.x or 8.1 are in the worst position, because there will be no official patch.

AIOTP: PAHO's "All in One" platform built on OpenEMR

The risk does not end with the official repository. The ciips-code organization on GitHub hosts the All In One Telehealth Platform (AIOTP), an open source telehealth suite commissioned by the Pan American Health Organization (PAHO/WHO) from CIIPS at the Institute for Clinical Effectiveness and Health Policy (IECS), as part of the IS4H initiative. Its goal is to improve access to care for remote populations in Latin America and the Caribbean, and its evolution toward interoperability with OpenHIE, HL7 FHIR and CDS Hooks has been proposed.

AIOTP has two main modules, and both run on PHP:

That puts it in the most delicate position of all:

• Every PHP branch involved is out of support. PHP 7.4 and 8.1 will not get an official PHP2Shell patch; there are only minimal source backports or whatever each distribution offers.
• The 7.0.0 image is not covered by OpenEMR's advisory, which only gives instructions for the 8.0 to 8.4 images. In addition, ONC certification for OpenEMR 7 was withdrawn in February 2026.
• Little recent activity. The last code change in AIOTP's OpenEMR package dates from December 2024 and the video module's from October 2023, so an immediate fix from the project is unlikely.
• It is a regional public good. Precisely because it comes from PAHO, it may be deployed in ministries, chronic disease programs or telehealth pilots, sometimes by teams that do not know OpenEMR runs underneath.

If you run AIOTP or a derived installation, treat it as unpatched: take it off the internet or put it behind a VPN, disable session.upload_progress.enabled in php.ini for both modules, look for signs of compromise and plan the migration to a supported branch of OpenEMR 8 and PHP. The same applies to any other OpenEMR derivative: identify the base image and the exact PHP version in its Dockerfile or installer before considering the problem solved.

What to do if you run OpenEMR or a derivative

The only complete fix is to upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35; both PHP and OpenEMR say so explicitly. Everything else is containment until the patch arrives.

In the next few hours

1. Take inventory. Identify every server, container or machine running OpenEMR or a derivative, including test environments, demos and training machines. For each one, note the OpenEMR version and run php -v.
2. Take OpenEMR off the internet. An EHR holding patient data should not be directly exposed. Restrict access to trusted networks or a VPN; if you cannot, consider shutting it down until you have the patch.
3. Patch according to your case.

- Official 8.4.x image: upgrade the php85 packages inside the container and restart it with docker compose restart, not with down/up. Confirm with php -v that you see 8.5.12 or later.
- 8.2.x or 8.3.x images: wait for the Alpine 3.23 backport, or move to 8.4.x and follow the same procedure.
- 8.0.x image: it will not get a fix inside the container; move to 8.4.x or build PHP 8.4.27.
- Installations without Docker: apply your distribution's or hosting provider's packages.

1. If you are stuck on PHP 8.1 or earlier, disable session.upload_progress.enabled in php.ini and restart the web service. It reduces the known vectors but does not replace upgrading.

In the next few days

• Look for signs of compromise. Check whether the PHP or Apache process has spawned shells (sh, bash), interpreters or tools such as curl or wget. Look for new PHP files in the web directory, cron jobs or unknown accounts.
• Rotate secrets. Since one of the flaws allows memory leaks, change database passwords, API keys, OAuth/SMART client secrets and certificates on servers that were exposed.
• Preserve evidence. If you find something suspicious, isolate the server and keep the web server and PHP logs before reinstalling.
• Assess your duty to notify. A compromised EHR is an incident involving sensitive data. In Costa Rica, Law 8968 on personal data protection requires assessing notification to PRODHAB and to the affected data subjects; other countries have equivalent rules.

Ongoing

• Stay on supported versions of OpenEMR, PHP and the base operating system. OpenEMR 8.4.1 is the current stable release.
• Rebuild images, do not patch them by hand. When the fixed official images are published, move to them so the patch does not depend on the container's writable layer.
• Put layers in front: reverse proxy, WAF, and request size and memory limits on the container.
• Subscribe to advisories from the OpenEMR forum and the PHP project, and assign one person to follow them.

What PHP2Shell leaves us with

Open source is not the problem: OpenEMR published a detailed advisory on the very day of disclosure, something many proprietary vendors do not do. The problem is running a clinical system without a security owner who watches the whole stack: application, language, base image and operating system.

From an interoperability standpoint there is one more lesson. An EHR that exposes a FHIR API and SMART on FHIR connections is an entry point to an entire exchange ecosystem. Its security is no longer just the clinic's business, but that of every system it shares data with.

At Meddyg we support health institutions in assessing their deployments, managing vulnerabilities and integrating securely with standards such as HL7 FHIR. If you need help reviewing your OpenEMR installation or a derivative, contact us.

Sources

• OpenEMR: php2shell advisory
• PHP: security advisory CVE-2026-109618
• PHP: security advisory CVE-2026-109619
• Huntress: Rapid Response php2shell
• Google Cloud: responding to the core PHP vulnerabilities
• Shodan: OpenEMR servers visible from the internet, excluding honeypots, queried on October 21, 2026
• Censys: OpenEMR servers by page title, queried on October 21, 2026
• OpenEMR: features
• IDB: OpenEMR in the open source solutions catalog
• AIOTP: All In One Telehealth Platform
• AIOTP: OpenEMR package (openemr-telesalud)