Octubre negro: qué pasó, qué plataformas de salud digital están expuestas y qué hacer

En menos de una semana se rompió una autoridad de certificación, se parcharon a toda prisa los lenguajes con los que está hecha buena parte de internet y cayeron plataformas que guardan las llaves de miles de desarrolladores. En redes ya lo llaman «Octubre negro». Esto es lo que pasó de verdad, qué significa para los sistemas de salud y qué deberían hacer hoy las organizaciones.

El nombre se popularizó con una publicación de la cuenta @AISafetyMemes del 22 de octubre: «Estas son las 48 horas más serias de la historia de la ciberseguridad. Lo están llamando "Octubre negro"». Medios como CNBC, Axios y 404 Media adoptaron el término, y varios lo vinculan con la velocidad con que las herramientas de IA están encontrando fallas. Las de PHP, por ejemplo, las encontraron en agosto investigadores de Wiz y Calif con modelos de IA de OpenAI y Google, según CNBC. El exdirector de CISA Chris Krebs dio la medida: el 3 % de todas las vulnerabilidades críticas descubiertas en la historia apareció en el último mes. Y el Informe Global de Amenazas 2026 de CrowdStrike ya registraba un aumento del 89 % en los ataques de adversarios que usan IA.

Conviene una precisión antes de seguir: en redes circularon versiones exageradas de casi todos estos casos. Como señala SecurityToday, lo que se concentró en estos días fueron sobre todo las divulgaciones; varios ataques llevaban semanas o meses en curso. Aquí contamos cada caso con lo que dicen las fuentes primarias, y señalamos dónde el rumor va más allá de los hechos.

La confianza en internet: eMudhra y sus llaves de un byte

eMudhra es una autoridad de certificación india: una de las empresas cuyas firmas usan los navegadores para confirmar que un sitio es quien dice ser. El 17 de octubre un investigador reportó a Google que ocho certificados intermedios de eMudhra tenían llaves privadas absurdamente débiles. Eran llaves de curva elíptica P-384, que deberían ser números de 384 bits elegidos al azar; en su lugar eran enteros menores que 256. Uno de ellos era, literalmente, el número 4. Los investigadores reportaron también 56, 66, 115, 155, 156, 230 y 237.

Con una llave así, cualquiera podía reconstruirla en menos de un segundo a partir del certificado público y emitir certificados válidos para cualquier sitio. Mozilla recuperó las llaves por su cuenta y las bloqueó esa misma noche, según su informe técnico y su aviso de seguridad. Chrome, Apple y Microsoft siguieron entre el 17 y el 20 de octubre, y se retiró la confianza en la raíz emSign ECC Root CA – G3. eMudhra atribuye el error a un paso defectuoso de su ceremonia de llaves de abril de 2025.

La acción cayó dos días seguidos al límite diario del 20 % en la bolsa de Bombay, alrededor de un 36–38 % en una semana según Business Standard. El 22 de octubre la empresa anunció que se retira del negocio global de certificados SSL/TLS. Entre sus razones citó el bajo peso del negocio en sus ingresos, la competencia de certificados gratuitos y que «la amplificación en redes sociales» trajo un escrutinio desproporcionado; no asumió la falla como causa. Ya antes, en el hilo técnico, eMudhra había culpado al «intenso escrutinio en redes sociales» de sus demoras, y el programa raíz de Chrome rechazó esa explicación.

Por qué importa más allá de los navegadores: los paquetes de certificados de Python (certifi), Node.js y Go también tuvieron que actualizarse. Un servidor o contenedor que no se reconstruye sigue confiando en las llaves comprometidas, aunque el navegador del usuario ya no lo haga.

Los lenguajes y servidores sobre los que corre todo

PHP: el caso que encendió las alarmas

PHP está detrás de cerca de 7 de cada 10 sitios web cuyo lenguaje de servidor es conocido, según W3Techs. El 21 de octubre el proyecto publicó parches de emergencia para PHP2Shell, dos fallas que permiten ejecutar código remoto sin autenticación, que ya analizamos en detalle a propósito de OpenEMR.

La reacción de los gobiernos no tiene precedentes recientes. Francia sacó de línea los sitios de sus prefecturas a la espera del parche, y Países Bajos, Finlandia, Luxemburgo y varias administraciones locales de Alemania y Reino Unido hicieron lo mismo por precaución. En Japón, la primera ministra Sanae Takaichi pidió públicamente a las organizaciones parchar esa misma noche, y la Oficina Nacional de Ciberseguridad recordó que suspender temporalmente un sitio es una medida válida para reducir el riesgo (nippon.com). En Estados Unidos, la NSA recomendó desconectar lo que no pudiera parcharse de inmediato (Defense One). La Unión Europea, a través de ENISA y CERT-EU, pidió considerar aislar las aplicaciones expuestas. No hubo apagones forzados ni se reportaron brechas en sitios gubernamentales: fueron decisiones preventivas.

La salud no quedó al margen. En Países Bajos, hospitales como el Jeroen Bosch Ziekenhuis, Amphia, Elisabeth-TweeSteden y Bravis desconectaron sus sitios web por precaución. El Jeroen Bosch aclaró que la atención no se vio afectada y que los pacientes seguían consultando su expediente y gestionando sus citas (Omroep Brabant). En Costa Rica, el MICITT, a través del CSIRT-CR, alertó el 20 de octubre a las instituciones públicas para que prepararan los parches, revisaran los registros de sus servidores y mantuvieran respaldos aislados (Delfino). Y los atacantes no esperaron: Cloudflare detectó miles de intentos de explotación en las 10 horas previas al anuncio, y millones después (The Guardian).

Python, Node.js, Java y Go

• Python. No hubo una falla crítica de ejecución remota en el intérprete, como se dijo en redes. Sí hubo publicaciones de seguridad aceleradas: Python 3.14.9 y sus pares actualizaron los certificados por el caso eMudhra, y se corrigió un salto de ruta en tarfile (CVE-2026-114583). La falla grave del mes estuvo en una librería muy usada, Pillow, que procesa imágenes y permitía ejecutar código con archivos EPS manipulados; se corrige en Pillow 13.0.0.
• Node.js. El lanzamiento de seguridad del 21 de octubre corrige 10 vulnerabilidades, cuatro de severidad alta. Una de ellas, en el descompresor Brotli, puede llevar a ejecución remota de código. Las versiones corregidas son 26.12.1, 24.22.1 y 22.23.4; Node 20 ya no recibe parches.
• Java. La actualización trimestral de Oracle del 20 de octubre trae 55 parches para Java SE, y el aviso de OpenJDK suma 47 vulnerabilidades. Ninguna supera 7,5 en CVSS: es una actualización de rutina, pero con muchas fallas explotables a distancia.
• Go. Dos publicaciones de seguridad en octubre: la del 8 corrige 15 fallas, sobre todo de denegación de servicio y contrabando de peticiones HTTP; la del 19 agrega a Go la desconfianza en los intermedios comprometidos de eMudhra.

NGINX y el kernel de Linux

NGINX, el servidor web y proxy inverso que usa alrededor del 30 % de los sitios cuyo servidor es conocido (W3Techs), publicó el 14 de octubre cinco correcciones. F5 califica tres de ellas como críticas (9,2 en CVSS v4.0); el propio proyecto NGINX las califica como medias porque solo son explotables con configuraciones específicas. Las versiones corregidas son 1.31.7 y 1.30.6.

En el kernel de Linux, Phoronix informó el 22 de octubre que la Zero Day Initiative envió por error seis reportes de vulnerabilidades a la lista pública del kernel, antes de que existieran parches. De los seis, dos permiten ejecución remota, ambos en KSMBD, el servidor SMB integrado al kernel, que es opcional y rara vez está activo. Los otros cuatro son escaladas de privilegios locales o fugas de información.

Plataformas y cadena de suministro

• Railway. Esta plataforma para publicar aplicaciones confirmó que entre el 20 y el 22 de octubre un atacante extrajo y descifró parte de las variables de entorno de sus clientes, buscando sobre todo llaves de proveedores de IA. Hasta un 1,85 % de los espacios de trabajo pudo quedar expuesto; no se vieron afectados todos los desarrolladores. Los despliegues estuvieron pausados alrededor de un día y Railway no ha recomendado cerrar cuentas. Lo que sí pide es rotar o revocar las variables sensibles y revisar el uso de los proveedores conectados.
• LiteLLM. La herramienta no roba credenciales; lo que ocurrió fue un ataque a su cadena de suministro. El 21 de octubre se publicó, durante unas dos horas, una versión maliciosa, la 1.107.0, en PyPI y Docker Hub. Esa versión instalaba un programa que robaba llaves de proveedores, credenciales de nube y SSH, y dejaba una puerta trasera (aviso oficial, Wiz). Quien la haya instalado debe dar por robadas todas las credenciales a las que ese equipo tenía acceso. Es el segundo compromiso de LiteLLM en 2026.
• Plex. Atacantes encadenaron cuatro fallas de Plex Media Server, bautizadas Plex2Shell, para instalar mineros de criptomonedas (BleepingComputer, Infobae). La corrección es la versión 1.43.3 y, según el aviso de Plex, en muchos equipos NAS hay que instalarla a mano. No hay una cifra pública de servidores infectados; sí hay más de 48 000 expuestos.

Datos personales a gran escala

• Estudiantes de California. Alguien usó un acceso robado al servidor de archivos de ETS, la organización que aplica las pruebas estatales, y copió entre mayo y septiembre datos de estudiantes de los últimos tres años escolares: nombre, fecha de nacimiento, dirección, puntajes, condición de discapacidad y otros (SecurityWeek, Malwarebytes). Solo en el ciclo 2025-26 hay más de 5,7 millones de estudiantes matriculados. No tiene relación con las fallas del kernel de Linux, como se afirmó en redes: el robo empezó meses antes y se hizo con una credencial válida.
• Facturación de Medi-Cal. Paradigm Healthcare Services, que procesa la facturación de Medi-Cal, el programa público de salud de California, informó que una intrusión expuso nombres, fechas de nacimiento y números de afiliado de más de 970 000 personas (SecurityWeek). El acceso ocurrió en octubre de 2025 y las cartas a los afectados salieron en septiembre de 2026, casi un año después. Es el riesgo de los terceros que procesan datos de salud por cuenta de otros.
• Capcom. La empresa japonesa de videojuegos confirmó que se expusieron 11 774 247 registros de cuentas CAPCOM ID, principalmente correo electrónico y datos de inicio de sesión, y que a 196 cuentas les cambiaron la contraseña sin autorización. En 19 de ellas los atacantes vieron datos personales y de compras (actualización del 23 de octubre).

Ni las herramientas de privacidad se salvaron

• Signal. Malwarebytes informó de una falla (CVE-2026-113380) por la que otro participante de una llamada podía impedir que esta se cerrara del todo al colgar, de modo que el audio, y posiblemente el video, seguía llegándole. No es un ataque de un desconocido ni rompe el cifrado, y no hay evidencia de explotación. Ya está corregida desde septiembre: hay que tener Signal actualizado.
• Tor. Un investigador detectó 333 relays de salida, alrededor del 10 % del total, que redirigían el tráfico SSH hacia servidores del atacante. No eran relays creados por el atacante, sino equipos de voluntarios comprometidos. Robaban contraseñas a quienes ignoraban la advertencia de cambio de llave del servidor. El Tor Project los retiró de la red entre el 4 y el 5 de octubre (lista tor-relays).

La IA entra a las cuentas bancarias

La periodista Madison Mills reveló en Axios que grandes bancos de Estados Unidos están encontrando agentes de IA de terceros operando dentro de cuentas de clientes, casi siempre con usuario y contraseña que el propio cliente entregó. Un ejecutivo admitió que les cuesta distinguir si un agente fue autorizado por el usuario o actúa por su cuenta. No es un ataque a los fondos, como aclaró la misma periodista a CBS, sino algo más de fondo: los sistemas no saben quién está actuando en nombre de quién. JPMorgan, Bank of America, Citi y Morgan Stanley ya restringen o bloquean estos agentes.

¿Y la prensa?

PHP llegó a los noticieros generales. En la cobertura en vivo de la BBC se resumió que su corresponsal de ciberseguridad, Joe Tidy, no sabía que PHP existía hasta el día anterior, y que es «una de esas cosas que damos por sentadas» (HackerNoon recoge la captura). Más allá de la burla en redes, la frase retrata algo cierto: la infraestructura más crítica es la que nadie ve. Si a la prensa especializada le cuesta seguirla, a una junta directiva de hospital le cuesta más, y por eso esa conversación no puede quedar solo en manos del equipo de TI.

¿Qué plataformas de salud digital están expuestas?

A la fecha no se ha reportado un hospital o un sistema de salud comprometido por estos casos en particular. Pero casi todo el software que sostiene la salud digital está construido sobre estas piezas, y eso lo hace exposición directa. Esta es una guía rápida:

Mención aparte para Java. Buena parte de la infraestructura de interoperabilidad en salud está escrita en este lenguaje, incluidos varios bienes públicos digitales en los que se apoyan ministerios y organismos de cooperación. Las fallas de octubre en el JDK no son las más graves del mes, pero estas plataformas acumulan además sus propias vulnerabilidades: en 2026, DHIS2 corrigió una ejecución remota crítica y Mirth Connect, unas XXE explotables sin iniciar sesión. Y CVE-2023-43208, una ejecución remota en Mirth, sigue en el catálogo de vulnerabilidades explotadas de CISA. Un motor de integración que recibe mensajes HL7 de toda la red es, por diseño, un punto que conviene tener al día.

Plan de acción

Jason Clinton, subdirector de seguridad de la información de Anthropic, se lo dijo así a los responsables de seguridad: vayan ahora a sus juntas directivas y pidan ayuda, «no para IA, para lo básico» (CNBC). Sin entrar en detalle técnico, estos son los pasos que toda organización de salud debería tener en marcha:

1. Saber qué tiene. Un inventario de sistemas, versiones y componentes (lo que se conoce como SBOM). Sin él no hay forma de responder a la pregunta «¿esto nos afecta?».
2. Parchar por prioridad. Primero lo expuesto a internet: portales, APIs FHIR, motores de integración. Lo que no pueda parcharse hoy, se aísla. Para decidir el orden, el catálogo de vulnerabilidades explotadas de CISA pesa más que la puntuación CVSS: entre la divulgación de una falla grave y su explotación ya pasan en promedio tres días, según Rapid7 (SecurityToday).
3. Rotar los secretos. Si usó Railway, LiteLLM 1.107.0 o tiene llaves en variables de entorno de servicios afectados, cámbielas, revise su uso y póngales fecha de vencimiento.
4. Cuidar la cadena de suministro. Fijar versiones de las dependencias, reconstruir los contenedores en lugar de parcharlos a mano, y no actualizar a ciegas a la versión «latest».
5. Revisar la confianza. Actualizar los almacenes de certificados de servidores y contenedores, y saber qué autoridad firma los certificados con los que sus sistemas se hablan entre sí.
6. Gobernar la identidad de los agentes de IA. Ningún agente debería entrar con la contraseña de una persona; debe tener su propia identidad, permisos limitados y registro de lo que hace.
7. Estar listo para responder y notificar. Un responsable definido, un plan de respuesta probado y claridad sobre la obligación de notificar: en Costa Rica, ante la PRODHAB y a los titulares afectados.

Lo que esto dice sobre estándares, interoperabilidad y arquitectura

Octubre negro no es solo una lista de parches. Pone a prueba la forma en que diseñamos el intercambio de información en salud, y deja cinco lecciones.

La interoperabilidad multiplica el alcance de una falla. Un expediente que expone una API FHIR, o un motor de integración que recibe mensajes de diez hospitales, ya no es un sistema aislado: es una puerta a toda la red. Por eso la seguridad tiene que formar parte de la arquitectura desde el inicio. Un ejemplo es una capa FHIR que se interpone entre el sistema heredado e internet, en lugar de exponerlo directamente. Lo mostró el Jeroen Bosch Ziekenhuis: apagó su sitio institucional y su portal de pacientes siguió funcionando. Separar lo público de lo clínico es una decisión de arquitectura.

El estándar no es la implementación. Que un sistema hable FHIR no lo hace seguro. Lo mostró en 2021 la investigadora Alissa Knight en Playing with FHIR: Hacking and Securing FHIR API Implementations, un estudio patrocinado por Approov. Analizó APIs FHIR en producción que daban servicio a un ecosistema de 48 aplicaciones y APIs, con datos agregados de 25 000 proveedores y aseguradoras, y con una sola cuenta de paciente llegó a 4 millones de registros de pacientes y clínicos (resumen de Approov). Cinco años antes, sus hallazgos ya anticipaban lo que este mes se repitió:

• Todas las APIs FHIR probadas dejaban ver datos de otros pacientes con las credenciales de uno solo. Es la falla de autorización por objeto (BOLA) que encabeza el OWASP API Security Top 10, y el mismo problema de fondo de los bancos: el sistema no verifica quién actúa en nombre de quién.
• El 53 % de las apps móviles tenía llaves y tokens incrustados en el código: el mismo tipo de secretos que se robaron en Railway y LiteLLM.
• Ninguna app impedía ataques de intermediario. Es la confianza en certificados que rompió eMudhra.
• La mitad de los agregadores no separaba las bases de datos de sus clientes, lo contrario de guardar menos y separar lo sensible.

Un matiz importante: no se vulneró el estándar ni los repositorios FHIR de los fabricantes de expedientes. HL7 International aclaró que el estudio no encontró fallas en FHIR ni en las APIs de los EHR probados; los huecos estaban en las aplicaciones y en los agregadores intermedios, y por eso la autora cambió el título original. La seguridad de un ecosistema FHIR la define su eslabón más débil, y ese eslabón casi nunca es el estándar.

La confianza descansa en certificados, y los certificados también fallan. El caso eMudhra afecta de lleno a la salud. El intercambio entre instituciones usa TLS mutuo, el perfil IHE ATNA exige nodos autenticados con certificados, la firma digital de documentos clínicos depende de una cadena de confianza y las redes nacionales como X-Road, que adopta Costa Rica con su Decreto de Interoperabilidad, descansan sobre servicios de confianza. Elegir bien la autoridad de certificación, controlar los almacenes de confianza y poder revocar rápido son decisiones de arquitectura. Es lo que resolvemos con Kivú eSignature.

Los estándares ya resuelven el problema de los bancos. Que un agente entre con la contraseña del usuario es justo lo que evita el perfil IHE Internet User Authorization (IUA). IUA se apoya en OAuth 2.1: cada aplicación o sistema obtiene su propio token de acceso, de duración limitada y revocable. Ese token dice quién es el usuario, a qué organización pertenece, con qué rol y con qué propósito actúa (atención, emergencia, investigación) y bajo qué consentimiento del paciente. El servidor que guarda los datos decide con esa información, no con una contraseña compartida. A eso se suma la trazabilidad: IHE ATNA y IHE BALP definen cómo registrar cada acceso en recursos AuditEvent de FHIR y, junto con Provenance, dejan constancia de quién hizo qué, en nombre de quién y con qué autorización. Cuando lleguen los agentes de IA a los portales de pacientes, y van a llegar, cada agente debería tener su propio token y su propia identidad, no la del paciente. La diferencia entre un sistema preparado y uno expuesto estará en haber implementado estos perfiles, no en bloquear a ciegas.

Guardar menos es exponer menos. La brecha de California expuso datos de discapacidad y puntajes de millones de menores que quedaron en un servidor de archivos. En salud, la minimización de datos, la seudonimización y un modelado de datos que separe lo identificable de lo clínico reducen el daño cuando algo falla. Y algo siempre falla.

Cómo podemos ayudar

En Meddyg acompañamos a instituciones de salud a revisar su arquitectura con estos riesgos en mente:

• Evaluación de interoperabilidad: qué sistemas tiene, qué expone, sobre qué tecnologías corre y qué tan preparada está su organización.
• Definición de arquitecturas: intercambio seguro con HL7 FHIR, perfiles IHE como IUA y ATNA, y X-Road, con identidad, auditoría y confianza diseñadas desde el inicio.
• Capa FHIR y Kivú FHIR: exponer los datos mediante estándares sin abrir los sistemas heredados a internet.
• Kivú eSignature: firma digital y gestión de certificados verificables.

Si quiere saber cuánto de su operación depende de las piezas que se rompieron este mes, conversemos.

Fuentes

• @AISafetyMemes: publicación sobre el «Octubre negro», 22 de octubre de 2026
• CNBC: el «Octubre negro» de la IA
• The Guardian: expertos advierten de una nueva era de ataques con IA
• CrowdStrike: Informe Global de Amenazas 2026
• Omroep Brabant: sitios de hospitales neerlandeses fuera de línea
• Delfino: el MICITT alerta a las instituciones públicas por PHP2Shell
• SecurityWeek: la brecha de Paradigm Healthcare
• SecurityToday: muchos ataques llevaban meses en curso
• Mozilla Bugzilla 2083449: llaves débiles de los intermedios de eMudhra
• Mozilla: protección de Firefox tras el compromiso de eMudhra
• eMudhra: salida del negocio de certificados SSL/TLS
• W3Techs: uso de PHP y uso de NGINX
• nippon.com: llamado de la primera ministra Takaichi
• Defense One: advertencia de la NSA sobre PHP
• ENISA: declaración conjunta de la UE sobre PHP
• Python: anuncios de seguridad
• Node.js: lanzamientos de seguridad de octubre de 2026
• Oracle: Critical Patch Update de octubre de 2026 y aviso de OpenJDK
• Go: historial de versiones
• NGINX: avisos de seguridad
• Phoronix: vulnerabilidades del kernel publicadas por error
• Railway: informe preliminar del incidente
• LiteLLM: incidente de seguridad del 21 de octubre
• Plex: actualización de seguridad para la versión 1.43.2 y anteriores
• SecurityWeek: datos de estudiantes de California
• Capcom: aviso del 22 de octubre y actualización del 23 de octubre
• Malwarebytes: la falla de Signal
• kaba.cx: relays de salida de Tor secuestrados
• Axios: agentes de IA no verificados en cuentas bancarias
• Approov y Alissa Knight: Playing with FHIR: Hacking and Securing FHIR API Implementations, octubre de 2021
• HL7 International: declaración sobre el estudio Playing with FHIR, 27 de octubre de 2021
• CISA: aviso médico ICSMA-26-253-01 (Mirth Connect)
• DHIS2: avisos de seguridad