HAPI FHIR deja tres fallos sin corregir tras la divulgación de cuatro CVE
CISA publicó cuatro CVE sobre aislamiento, autorización y agotamiento de memoria en HAPI FHIR. El investigador dice que tres rutas seguían sin corregir y que una cuarta tenía cambio en la rama principal sin release etiquetada; las pruebas sintéticas no demuestran impacto en cada despliegue.
CISA publicó el 22 de octubre un aviso con cuatro CVE para HAPI FHIR, una implementación Java de FHIR usada para intercambiar recursos sanitarios. Los hallazgos cubren límites distintos: agotamiento de memoria ante datos comprimidos, controles de autorización y separación entre particiones de clientes. El investigador que coordinó la divulgación dice que tres rutas seguían sin corrección en la rama principal cuando publicó el análisis; una cuarta tenía un cambio en desarrollo, pero la disponibilidad en una versión distribuible no estaba clara. No hay en esos registros una confirmación de que un hospital o un despliegue concreto haya sufrido una intrusión.
-SecureCrew dice: en sistemas multi-tenant, una prueba que devuelve el paciente equivocado ya es suficiente para parar el café y abrir el ticket.-
Cuatro problemas, cuatro condiciones
CVE-2026-113873 afecta al procesamiento de cuerpos comprimidos: una petición sin autenticar puede hacer que el servidor reserve demasiada memoria al descomprimir el contenido y termine degradado o caído. CISA publica para este caso un CVSS 3.1 de 7,5, con impacto en disponibilidad y sin privilegios requeridos. Es un DoS por agotamiento de recursos; no es ejecución de código ni prueba de que los datos almacenados hayan sido leídos.
CVE-2026-113874 es el hallazgo más serio para un servicio con particiones por cliente. Según el aviso de CISA, un usuario ya autorizado para un tenant podría alterar la identidad de partición que llega en un bundle y leer o escribir datos en otra partición cuando el despliegue no impone la autorización de almacenamiento correspondiente. El CVE lleva CVSS 3.1 de 8,1; hace falta un usuario con privilegios, así que no debe describirse como acceso anónimo a toda la base.
-SecureCrew dice: “multi-tenant” es una promesa de aislamiento; la autorización de cada partición es la cerradura, no la etiqueta de la puerta.-
Los otros dos fallos son más dependientes de permisos y funciones habilitadas. CVE-2026-113875 puede permitir lectura no autorizada a una persona con permiso para crear suscripciones si el servidor tiene activo REST-hook; el investigador aclaró que su ejemplo era una lectura dentro de la misma partición, no un cruce entre tenants. CVE-2026-113876 trata de una operación de creación condicional: una cuenta con permiso CREATE, pero sin READ, podría recibir el contenido de un recurso existente cuando la condición coincide. CISA los publica con puntuaciones CVSS 3.1 de 3,1 y 4,3, respectivamente.
La diferencia entre una rama y una corrección disponible
El aviso de CISA identifica versiones afectadas y no ofrece corrección para los tres primeros CVE. En el cuarto, su registro CSAF marca como corregida una versión de septiembre de 2026. El investigador, por su parte, encontró el cambio correspondiente en la rama principal, sin una etiqueta de release que lo incluyera a 22 de octubre, y señaló HAPI 9.0.0 como la entrega prevista para noviembre. Esa diferencia importa: una corrección en el repositorio no actualiza por sí sola los paquetes que consume una organización, y las distribuciones comerciales pueden llevar sus propios parches.
El análisis reproduce los cuatro problemas en HAPI FHIR upstream 8.10.0 con datos sintéticos y describe revisión de código en otras versiones. Eso aporta evidencia técnica, pero no demuestra que todas las instalaciones de Smile CDR tengan el mismo comportamiento ni que existan registros sanitarios expuestos. CISA nombra SmileCDR HAPI FHIR en su aviso; el alcance concreto debe contrastarse con la edición, los componentes y los controles de cada despliegue.
-SecureCrew dice: “está en main” es una coordenada de desarrollo, no una versión que el gestor de paquetes pueda instalar.-
Para quienes operan HAPI FHIR, la primera tarea es identificar versión y configuración: distribución, uso de particiones, suscripciones REST-hook y creación condicional. Después, revisa qué roles pueden enviar bundles o crear esas suscripciones y valida las rutas con datos de prueba no sensibles. Mientras no haya una corrección distribuible confirmada para cada CVE, conviene acordar con el proveedor qué mitigación soporta la edición instalada y vigilar solicitudes inusuales; no conviene desactivar funciones clínicas sin evaluar el efecto operativo.
Diccionario de la Crew
FHIR — Estándar para representar e intercambiar información sanitaria mediante recursos y operaciones definidos.
Tenant — Partición lógica que separa los datos y permisos de una organización dentro de un servicio compartido.
DoS — Denegación de servicio: pérdida o degradación de disponibilidad al agotar recursos o bloquear una función.
REST-hook — Suscripción que envía una notificación HTTP cuando ocurre un cambio que coincide con sus criterios.
Creación condicional — Operación que crea un recurso solo si no existe otro que cumpla una búsqueda o condición.
