Animación sin audio, de 42 segundos, ilustrativa y conceptual: no contiene un exploit real.
- El escenario. A la izquierda, un EHR en PHP expuesto a internet; a la derecha, la máquina del atacante.
- Reconocimiento. El atacante apunta al servidor sin necesitar credenciales, y el servidor responde que corre PHP 8.1, una versión vulnerable y sin parche oficial.
- La petición. El atacante envía una petición HTTP manipulada: un formulario multipart con "upload progress".
- Qué pasa dentro de PHP. La petición agota la memoria del proceso de PHP, un dato queda a medio inicializar, la limpieza lo trata como válido y el atacante controla ese dato para ejecutar código. El fallo está en PHP, no en la aplicación: se dispara antes de que corra una sola línea del EHR.
- Servidor comprometido. El atacante obtiene una shell con los privilegios del proceso web, sin usuario ni contraseña. Desde ahí puede leer todo lo que el EHR puede: la base de datos de pacientes, las credenciales, las llaves de API y los datos clínicos, o instalar un webshell.
- La corrección. Con PHP actualizado a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, la petición ya no corrompe la memoria y el ataque falla. Si sigue en PHP 7.x u 8.1, sáquelo de internet y planifique migrar: no habrá parche oficial.
- Revise su instalación hoy. Inventariar cada servidor con OpenEMR, AIOTP o PHP; parchar PHP o aislar lo que no tenga corrección; rotar secretos y buscar señales de compromiso.
El servidor, el dominio y los datos son ficticios.