Si su clínica, laboratorio o proyecto usa OpenEMR, esta semana tiene una tarea urgente: actualizar PHP. El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para dos fallas críticas que permiten ejecutar código remoto sin autenticación. OpenEMR está escrito en PHP, así que cada instalación expuesta a internet es, por defecto, un blanco.
En este artículo explicamos qué es la vulnerabilidad, qué es OpenEMR (y su derivado AIOTP, la plataforma "All in One" de la OPS) y qué acciones concretas deberían tomar hoy quienes lo operan.
Qué es PHP2Shell
PHP2Shell es el nombre con que la comunidad de seguridad bautizó a dos vulnerabilidades del núcleo de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas tienen severidad crítica, 9,2 en CVSS v4.0, y permiten que un atacante sin credenciales ejecute código en el servidor con los privilegios del proceso web.
La primera falla está en el manejo de errores por falta de memoria: si PHP se queda sin memoria mientras prepara los datos de una petición, esos datos quedan a medio inicializar y luego se tratan como válidos. La segunda ocurre porque PHP conserva estado de una petición después de liberar su memoria; si el mismo proceso atiende la siguiente petición, puede leer ese estado obsoleto. Esta segunda vía también permite filtrar memoria, lo que puede exponer contraseñas, tokens, llaves de API y certificados.
Lo que hace especialmente grave este caso:
- No depende de la aplicación. El fallo está en el intérprete, no en WordPress, Drupal u OpenEMR. Según PHP, toda instalación que atienda peticiones web está en riesgo: PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed. En modphp el ataque puede ocurrir antes de que corra una sola línea de código de la aplicación.
- Alcance histórico amplio. Afecta desde PHP 5.4 hasta 8.5.11.
- Se filtró antes del parche. Los detalles circularon el 20 de octubre, antes de la divulgación coordinada; PHP adelantó la publicación al 21 de octubre y ese mismo día aparecieron análisis técnicos detallados.
- Versiones sin soporte quedan fuera. PHP 8.1 y anteriores no recibirán parche oficial.
Fuentes: Huntress, Google Cloud.
Qué es OpenEMR
OpenEMR es el expediente electrónico de salud (EHR) de código abierto más conocido del mundo: una aplicación web gratuita, escrita en PHP sobre MySQL/MariaDB, que integra historia clínica, agenda, facturación y portal del paciente. Lleva más de dos décadas de desarrollo comunitario y es mantenido por una comunidad de voluntarios y empresas proveedoras de servicios.
Sus capacidades más relevantes para quienes trabajamos en interoperabilidad:
- Certificación ONC en Estados Unidos (2015 Cures Update). La certificación de la versión 7 se retiró el 27 de febrero de 2026; hoy la rama certificada es OpenEMR 8.
- API FHIR R4 alineada con US Core y SMART on FHIR para autorización de aplicaciones de terceros.
- Módulos clínicos y administrativos: prescripción electrónica, reportes de calidad (eCQM), determinantes sociales de la salud, facturación X12, telemedicina y portal del paciente.
- Internacionalización: traducido a decenas de idiomas, incluido el español, y usado en clínicas de muchos países.
En América Latina tiene además respaldo institucional: el BID lo incluye en su catálogo de soluciones de código abierto y figura como bien público digital reconocido por la Digital Public Goods Alliance. Por eso es una opción frecuente en clínicas privadas, ONG, proyectos académicos y pilotos de salud digital en la región.
Esa misma popularidad es la que lo convierte en un objetivo atractivo: un EHR concentra datos de salud, identificación y facturación, justo lo que más valor tiene para un atacante.
Por qué OpenEMR está directamente expuesto
OpenEMR usa sesiones PHP y permite subir archivos (documentos clínicos, imágenes, consentimientos). Según el aviso oficial de OpenEMR del 21 de octubre, cualquier sitio con sesiones o carga de archivos habilitadas, ambas activas por defecto, es explotable. El mismo aviso indica que la vulnerabilidad ya se está explotando y que existe código de prueba de concepto público.
Este vídeo muestra, en 42 segundos y sin audio, cómo se ve el ataque contra un EHR en PHP expuesto a internet: el atacante detecta una versión vulnerable, envía una petición manipulada y obtiene una shell sin usuario ni contraseña. Es una animación ilustrativa y conceptual; no contiene un exploit real.
También pueden verlo en su propia página: PHP2Shell: cómo funciona el ataque.
Cuántas instalaciones están a la vista
Una consulta a Shodan, el buscador de dispositivos conectados a internet, encontró el 21 de octubre de 2026 1.386 servidores con OpenEMR visibles desde internet, en 46 países. El 62 % está en Estados Unidos, y la mayoría corre en nubes públicas. Censys, otro buscador del mismo tipo, contó ese día 487 buscando por el título de la página, con la misma tendencia: el 70 % en Estados Unidos. Las cifras no se suman, porque cada buscador indexa de forma distinta.
La misma búsqueda devolvió 405 señuelos (honeypots) que imitan la página de OpenEMR. Son trampas que suelen montar investigadores y equipos de seguridad para observar a los atacantes, y su número muestra que OpenEMR ya está bajo vigilancia activa. En China, además, casi todos los resultados no marcados como señuelo siguen el mismo patrón: páginas de instalación en nubes públicas y en puertos al azar. Censys encuentra solo 13 servidores en China.
En América Latina y el Caribe se ven apenas 28 servidores en Shodan y 8 en Censys, pero eso dice poco del riesgo real:
El punto delicado está en las imágenes Docker oficiales, que es como se despliega hoy la mayoría de instalaciones. La corrección depende de la versión de Alpine Linux sobre la que se construyó cada imagen:
Tres detalles que pueden sorprender a un equipo de operaciones:
- Descargar la imagen más reciente no basta. La imagen 8.4.x publicada se construyó antes del parche, así que un
docker pullsigue entregando PHP vulnerable. - El parche aplicado dentro del contenedor es frágil. Vive en la capa escribible: un
docker compose downoup --force-recreatelo revierte. Hay que usarrestart. - La cadena de construcción del proyecto estaba detenida por una caída de un repositorio de Ubuntu/Launchpad, así que las imágenes reconstruidas podrían tardar.
Las instalaciones fuera de Docker (paquetes del sistema operativo, XAMPP en Windows, servidores compartidos) dependen del ritmo de su distribución o proveedor de hosting. Las que todavía corren PHP 7.x u 8.1 están en la peor posición, porque no habrá parche oficial.
AIOTP: la plataforma "All in One" de la OPS basada en OpenEMR
El riesgo no termina en el repositorio oficial. En la organización ciips-code de GitHub está la All In One Telehealth Platform (AIOTP), una suite de telesalud de código abierto encargada por la Organización Panamericana de la Salud (OPS/OMS) al CIIPS del Instituto de Efectividad Clínica y Sanitaria (IECS), dentro de la iniciativa IS4H. Su objetivo es mejorar el acceso a la atención en poblaciones remotas de América Latina y el Caribe, y se ha planteado su evolución hacia interoperabilidad con OpenHIE, HL7 FHIR y CDS Hooks.
AIOTP tiene dos módulos principales, y ambos corren sobre PHP:
| Componente | Repositorio | Base técnica | PHP declarado |
|---|---|---|---|
| Historia clínica | openemr-telesalud | OpenEMR 7.0.0 (parche 1); el despliegue de producción usa la imagen oficial openemr/openemr:7.0.0 | Plataforma Composer fijada en PHP 7.4; entorno de desarrollo sobre php:8.1.9-fpm |
| Videoconsulta | ciips-telesalud | Laravel + Jitsi | Imágenes php:8.1-fpm |
Eso lo pone en la situación más delicada de todas:
- Todas las ramas de PHP en juego están fuera de soporte. PHP 7.4 y 8.1 no recibirán parche oficial de PHP2Shell; solo hay backports mínimos de código fuente o los que ofrezca cada distribución.
- La imagen 7.0.0 no está cubierta por el aviso de OpenEMR, que solo da instrucciones para las imágenes 8.0 a 8.4. Además, la certificación ONC de OpenEMR 7 se retiró en febrero de 2026.
- Poca actividad reciente. El último cambio de código en el paquete OpenEMR de AIOTP es de diciembre de 2024 y el del módulo de videoconsulta, de octubre de 2023, así que no cabe esperar una corrección inmediata desde el proyecto.
- Es un bien público regional. Precisamente por venir de la OPS, puede estar desplegado en ministerios, programas de enfermedades crónicas o pilotos de telesalud, a veces por equipos que no saben que debajo corre OpenEMR.
Si usted opera AIOTP o una instalación derivada, trátela como una instalación sin parche: sáquela de internet o póngala detrás de VPN, desactive session.upload_progress.enabled en php.ini de ambos módulos, revise señales de compromiso y planifique la migración a una rama soportada de OpenEMR 8 y de PHP. Lo mismo aplica a cualquier otro derivado de OpenEMR: identifique la imagen base y la versión exacta de PHP en su Dockerfile o instalador antes de dar por resuelto el problema.
Qué hacer si usa OpenEMR o un derivado
La única corrección completa es actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35; tanto PHP como OpenEMR lo dicen explícitamente. Todo lo demás es contención mientras llega el parche.
En las próximas horas
- Inventariar. Identifique cada servidor, contenedor o máquina donde corre OpenEMR o un derivado, incluidos ambientes de pruebas, demos y equipos de capacitación. Para cada uno, anote la versión de OpenEMR y ejecute
php -v. - Sacar OpenEMR de internet. Un EHR con datos de pacientes no debería estar expuesto directamente. Restrinja el acceso a redes de confianza o VPN; si no puede, considere apagarlo hasta tener el parche.
- Parchar según su caso.
- Imagen oficial 8.4.x: actualice los paquetes php85 dentro del contenedor y reinícielo con docker compose restart, no con down/up. Confirme con php -v que ve 8.5.12 o superior.
- Imágenes 8.2.x u 8.3.x: espere el backport de Alpine 3.23 o migre a 8.4.x y aplique el mismo procedimiento.
- Imagen 8.0.x: no recibirá corrección dentro del contenedor; migre a 8.4.x o compile PHP 8.4.27.
- Instalaciones sin Docker: aplique los paquetes de su distribución o de su proveedor de hosting.
- Si está atrapado en PHP 8.1 o anterior, desactive
session.upload_progress.enabledenphp.iniy reinicie el servicio web. Reduce los vectores conocidos, pero no reemplaza la actualización.
En los próximos días
- Buscar señales de compromiso. Revise si el proceso de PHP o Apache ha lanzado shells (
sh,bash), intérpretes o herramientas comocurlowget. Busque archivos PHP nuevos en el directorio web, tareas cron o cuentas desconocidas. - Rotar secretos. Como una de las fallas permite filtrar memoria, cambie contraseñas de base de datos, llaves de API, secretos de clientes OAuth/SMART y certificados de servidores que estuvieron expuestos.
- Preservar evidencia. Si encuentra algo sospechoso, aísle el servidor y conserve los registros del servidor web y de PHP antes de reinstalar.
- Evaluar la obligación de notificar. Un compromiso de un EHR es un incidente con datos sensibles. En Costa Rica, la Ley 8968 de protección de datos personales obliga a evaluar la notificación a la PRODHAB y a los titulares afectados; en otros países aplican normas equivalentes.
De forma permanente
- Mantenerse en versiones soportadas de OpenEMR, de PHP y del sistema operativo base. OpenEMR 8.4.1 es la versión estable actual.
- Reconstruir imágenes, no parcharlas a mano. Cuando se publiquen las imágenes oficiales corregidas, migre a ellas para que el parche no dependa de la capa escribible del contenedor.
- Poner capas delante: proxy inverso, WAF y límites de tamaño de petición y de memoria en el contenedor.
- Suscribirse a los avisos del foro de OpenEMR y del proyecto PHP, y designar a una persona responsable de seguirlos.
Lo que nos deja PHP2Shell
El código abierto no es el problema: OpenEMR publicó un aviso detallado el mismo día de la divulgación, algo que muchos proveedores propietarios no hacen. El problema es operar un sistema clínico sin un responsable de seguridad que esté atento a la pila completa: aplicación, lenguaje, imagen base y sistema operativo.
Desde la interoperabilidad hay una lección adicional. Un EHR que expone una API FHIR y conexiones SMART on FHIR es un punto de entrada a todo un ecosistema de intercambio. Su seguridad ya no es solo un asunto de la clínica, sino de cada sistema con el que comparte datos.
En Meddyg acompañamos a instituciones de salud en la evaluación de sus despliegues, la gestión de vulnerabilidades y la integración segura con estándares como HL7 FHIR. Si necesita apoyo para revisar su instalación de OpenEMR o de un derivado, escríbanos.
Fuentes
- OpenEMR: aviso php2shell
- PHP: aviso de seguridad CVE-2026-109618
- PHP: aviso de seguridad CVE-2026-109619
- Huntress: Rapid Response php2shell
- Google Cloud: respuesta a las vulnerabilidades de PHP
- Shodan: servidores con OpenEMR visibles desde internet, sin honeypots, consulta del 21 de octubre de 2026
- Censys: servidores con OpenEMR por título de página, consulta del 21 de octubre de 2026
- OpenEMR: funcionalidades
- BID: OpenEMR en el catálogo de soluciones de código abierto
- AIOTP: All In One Telehealth Platform
- AIOTP: paquete OpenEMR (openemr-telesalud)