OHIF corrige un fallo que puede filtrar el token OIDC de un clínico: por qué no es un bug más en software médico

Un visor médico no debería enviar el token autenticado de un clínico a un servidor controlado por un atacante. Suena obvio. Pues precisamente eso puede ocurrir en determinadas integraciones de OHIF Viewers DICOM, según el aviso publicado por CISA el 25 de junio de 2026 para la vulnerabilidad CVE-2026-12473.

La puntuación no es menor: CVSS v3.1 8,2 y CVSS v4.0 8,3. El problema afecta a OHIF DICOM Web Viewer Framework hasta la versión 3.12.0, y el mantenedor ya publicó una corrección en la versión 3.12.2 el 18 de mayo de 2026. CISA dice que no tiene constancia de explotación pública dirigida contra esta vulnerabilidad. Bien. Eso no la convierte en teórica. Solo significa que todavía no ha salido en una diapositiva de incidente.

La mecánica del fallo merece atención porque retrata un patrón cada vez más habitual en software sanitario y corporativo: una función legítima, un token de identidad reutilizado con demasiada alegría y una petición saliente que nadie ha encadenado con una lista de destinos permitidos. Resultado: el usuario hace clic en un enlace manipulado, la aplicación recupera una URL arbitraria y el sistema de autenticación inyecta automáticamente el Bearer token OIDC del clínico en la petición. El servidor del atacante recibe el regalo.

No estamos ante un ransomware con pantallas en negro ni ante una caída visible de sistemas. Estamos ante algo más incómodo: robo silencioso de credenciales delegadas en un entorno donde ver imágenes diagnósticas, abrir estudios y moverse entre servicios autenticados forma parte de la práctica clínica normal. Eso sitúa este aviso en una zona donde ciberseguridad, arquitectura de aplicaciones y cumplimiento regulatorio se pisan entre sí.

Qué ha dicho exactamente CISA, y qué parte importa de verdad

El aviso de CISA identifica una vulnerabilidad de tipo SSRF bajo CWE-918, pero conviene afinar. Aquí la etiqueta SSRF, siendo técnicamente correcta, se queda corta si uno se limita a la definición académica. Según el advisory, dos fuentes de datos incluidas en la configuración por defecto, DICOMWebProxy y DICOMJSON, recuperan un parámetro URL arbitrario sin validación. A continuación, un servicio global de autenticación de OHIF inyecta automáticamente el token OIDC Bearer del usuario autenticado en las solicitudes resultantes. Eso significa que el atacante no solo puede hacer que la aplicación salga a buscar contenido donde él quiera: puede conseguir que salga autenticada en nombre del clínico.

Ese matiz cambia mucho el análisis del riesgo. Una SSRF clásica suele preocupar por el acceso del servidor a recursos internos, metadatos cloud, endpoints administrativos o servicios no expuestos. Aquí el valor principal puede estar en la exfiltración del token. Si el token tiene ámbito suficiente, duración amplia o posibilidad de reutilización contra otros servicios, el incidente deja de ser “solo” un problema del visor DICOM. Pasa a ser un incidente de identidad federada.

CISA no dice que todas las implementaciones de OHIF sean vulnerables en el mismo grado. Y hace bien. El propio aviso aclara que el riesgo se materializa en una custom integration version y que las fuentes de datos DICOMweb no están afectadas. Eso importa porque evita el titular fácil de “todo OHIF está roto”. No lo está. Lo que sí queda claro es que determinadas configuraciones, incluidas funciones presentes por defecto, abren una vía peligrosa cuando el despliegue usa autenticación y no restringe adecuadamente a qué orígenes puede hablar la aplicación.

El remedio oficial tiene dos capas. La primera es obvia: actualizar a la versión 3.12.2 o posterior. La segunda es bastante más reveladora sobre la causa raíz: los operadores que necesiten dicomwebproxy o dicomjson en despliegues autenticados deben configurar una nueva lista de permitidos llamada dangerouslyAllowedOriginsForAuthenticatedEnvironments en app-config.js. El nombre de la variable casi hace el trabajo editorial por sí solo. Si un proyecto llama “dangerously” a una opción, no la trates como un detalle de configuración menor.

Además, el mantenedor recomienda eliminar de la configuración desplegada todas las definiciones no utilizadas de DicomWebProxyDataSource y DicomJSONDataSource. Esta parte es quizá la más operativa y la más ignorada en la práctica. Muchas organizaciones actualizan versión, reinician el contenedor y dan el asunto por cerrado. Si permanecen activos conectores no usados o plantillas heredadas, el riesgo residual puede seguir ahí, esperando a alguien con tiempo y un enlace bien construido.

Por qué este fallo va más allá de una SSRF de manual

La industria lleva años tratando la SSRF como una vulnerabilidad de infraestructura: acceso al metadata service, pivoteo interno, descubrimiento de red, abuso de privilegios del servidor. Todo eso sigue siendo cierto. Pero en aplicaciones modernas, sobre todo las que integran OIDC, OAuth 2.0 y microservicios con autenticación delegada, el verdadero premio muchas veces está en cómo la aplicación adjunta credenciales automáticamente a peticiones que el desarrollador considera “de confianza”.

Ese es el corazón del problema en OHIF. No basta con preguntar si una URL externa puede resolverse. La pregunta buena es otra: ¿qué cabeceras, tokens o cookies viajan en esa petición saliente? Si la respuesta incluye un token de acceso reutilizable por un clínico autenticado, el impacto se dispara.

Y aquí aparece una paradoja bastante fea. Las organizaciones sanitarias han invertido, con razón, en autenticación centralizada, SSO y federación de identidad para reducir credenciales locales dispersas. El resultado operativo suele ser mejor. El resultado de seguridad también, salvo cuando una aplicación decide actuar de mensajero y reenviar el token al primer destino que pase por la URL. La centralización de identidad mejora la gobernanza, sí. También aumenta el radio de impacto de un fallo de diseño en la capa de integración.

El caso OHIF ilustra además un problema de producto muy extendido: la diferencia entre “configuración por defecto disponible” y “funcionalidad realmente necesaria en producción”. En demasiadas plataformas, se envían conectores, proxys, fuentes de datos y módulos genéricos listos para cubrir múltiples casos de uso. Cómodo para desplegar. Incómodo cuando nadie elimina lo que no utiliza. El ataque no necesita que la función sea central para el negocio; le basta con que siga ahí.

Otro detalle nada menor es el requisito de interacción del usuario. El vector CVSS v3.1 publicado por CISA es CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N. Ese UI:R significa que alguien debe hacer algo, normalmente pulsar un enlace o iniciar una acción inducida. Hay quien leerá eso y respirará demasiado rápido. Mala idea. En entornos clínicos, donde los usuarios se mueven deprisa entre estudios, referencias, enlaces internos, portales e integraciones, la fricción cognitiva es una materia prima escasa. Si el flujo de trabajo habitual ya incluye abrir recursos contextuales, el requisito de interacción no reduce tanto el riesgo como a algunos les gustaría creer.

De hecho, CISA remata el aviso con las recomendaciones clásicas contra ingeniería social: no hacer clic en enlaces no solicitados, precaución con adjuntos, etcétera. Son consejos correctos, claro. También son insuficientes como estrategia principal cuando el defecto real está en la arquitectura de confianza de la aplicación. Decir a un clínico que no pulse enlaces maliciosos siempre queda bien en el PowerPoint. Decir al proveedor y al hospital que deben impedir que un token autenticado salga hacia un origen arbitrario es bastante menos cómodo, pero mucho más útil.

El contexto técnico: DICOM, proxys y autenticación federada en hospitales reales

OHIF no es un juguete de laboratorio. Es un proyecto ampliamente conocido en el ecosistema de imagen médica, usado en visualización DICOM y en integraciones clínicas y de investigación. Precisamente por eso el advisory de CISA merece lectura atenta. Cuando una pieza de software sanitario se convierte en bloque de construcción para terceros, la superficie de riesgo deja de depender solo del código base y pasa a depender de cómo cada hospital, integrador o proveedor OEM lo empaqueta, autentica y expone.

En una arquitectura sanitaria moderna, el visor de imágenes ya no vive aislado en un rincón del PACS. Se integra con portales clínicos, visores web, sistemas de identidad, APIs de DICOMweb, servicios de autorización y, en algunos casos, capas de proxy para adaptar fuentes heterogéneas. Esa complejidad tiene una consecuencia simple: una decisión aparentemente menor en el frontend o en la configuración puede convertirse en un problema de seguridad transversal.

El advisory señala expresamente que las fuentes de datos DICOMWebProxy y DICOMJSON incluidas en la configuración por defecto son las afectadas, mientras que las DICOMweb data sources no lo están. Ese contraste es útil. Sugiere que el problema no reside en “DICOMweb” como estándar, sino en una ruta concreta de integración que permitía resolver URLs arbitrarias y adjuntar autenticación automáticamente. Dicho de forma más llana: no es la imagen médica lo que falla; es la manera en que la aplicación decide ir a buscar cosas y con qué credenciales.

Para un CISO hospitalario o para el responsable de arquitectura de una red sanitaria, la pregunta relevante no es si usan “OHIF” a secas, sino qué variante usan, qué conectores están activos, qué proveedor la integró y cómo gestiona los tokens. Muchos hospitales ni siquiera sabrán de entrada si llevan una versión customizada, una empaquetada por un tercero o un despliegue heredado de un proyecto mayor. Esa opacidad complica la respuesta inicial al advisory.

Añadamos otra capa. En entornos clínicos, los tokens OIDC no siempre abren una única puerta. Pueden formar parte de una sesión federada que da acceso a varias aplicaciones o que, como mínimo, identifica al usuario frente a servicios secundarios. Si un atacante obtiene el token y este no está suficientemente restringido por audiencia, duración o validaciones adicionales, el incidente puede derivar en acceso no autorizado, suplantación de usuario o consultas indebidas de información clínica. La explotación concreta dependerá del diseño del ecosistema. El problema es que esa dependencia juega en contra del hospital: obliga a entender de verdad su cadena de confianza, no solo a parchear una librería.

El nombre de la nueva allowlist ya lo dice todo

Hay veces en que un detalle de ingeniería cuenta más que una nota de prensa entera. Aquí lo tenemos en la nueva opción de configuración: dangerouslyAllowedOriginsForAuthenticatedEnvironments. Es un nombre largo, incómodo y, por una vez, honestísimo.

Lo que revela ese ajuste es que el mantenedor ha asumido una verdad básica: en un entorno autenticado, no puedes permitir libremente que ciertos componentes salgan a cualquier origen. Debes fijar una allowlist explícita. No “idealmente”. No “cuando haya tiempo”. Explícita.

Eso tiene varias implicaciones prácticas.

La primera: si tu despliegue depende de dicomwebproxy o dicomjson y trabajas con autenticación, la actualización a 3.12.2 no es el final del trabajo; es el principio. Tienes que revisar app-config.js, definir los orígenes estrictamente necesarios y validar que no has introducido comodines absurdos o dominios demasiado amplios. Una allowlist con media internet dentro no es una allowlist. Es teatro.

La segunda: si no necesitas esos conectores, elimínalos. CISA y el mantenedor lo dicen sin rodeos. No desactives mentalmente el riesgo dejando el bloque en la configuración “por si algún día”. El “por si acaso” en software suele traducirse como “superficie de ataque gratis”.

La tercera: esta corrección debería disparar una revisión más amplia. Si una aplicación ya ha mostrado este patrón en dos fuentes de datos, conviene preguntarse dónde más existen llamadas salientes que arrastren tokens, cabeceras o credenciales internas. El error visible rara vez es el único punto donde la lógica de confianza se ha relajado demasiado.

Y aquí aparece el toque irónico que la situación merece. Durante años, muchas organizaciones han comprado la idea de que el mayor avance en seguridad era “integrarlo todo”. Single sign-on, APIs, proxies, automatización, experiencia fluida. Todo muy razonable. El problema llega cuando “fluida” se convierte en “la aplicación manda credenciales donde le pidan con cero preguntas”. La diferencia entre integración elegante e integración temeraria suele caber en una allowlist bien hecha.

Qué deberían hacer ahora hospitales, integradores y proveedores

La respuesta útil no es “apliquen buenas prácticas”. La respuesta útil es separar decisiones inmediatas de revisiones estructurales.

Lo inmediato empieza por la identificación del activo. No basta con buscar “OHIF” en inventario. Hay que localizar despliegues directos, visores embebidos, integraciones OEM y cualquier aplicación que use el framework de visualización en versión 3.12.0 o anterior. Si el software lo integró un tercero, toca preguntar por la rama exacta, personalizaciones y fecha de parcheo. Más de una organización descubrirá que usa OHIF sin haberlo registrado así, porque figura bajo el nombre comercial de otra solución.

Después viene la validación de exposición funcional. ¿Está habilitada autenticación? ¿Se usan DicomWebProxyDataSource o DicomJSONDataSource? ¿Siguen en la configuración aunque nadie los emplee? ¿Se ha desplegado ya la versión 3.12.2 o superior? ¿Existe una allowlist de orígenes para entornos autenticados y, si existe, está restringida a destinos concretos? Estas preguntas no son burocracia; determinan si el advisory te afecta de forma material o periférica.

La tercera tarea es más delicada: analizar el modelo del token. No todas las implantaciones OIDC son iguales. Conviene revisar al menos cuatro puntos:

• La audiencia del token: si sirve solo para un servicio concreto o si puede reutilizarse en varios.
• La duración y renovación: un token con vida corta limita daño; uno generoso amplía la ventana de abuso.
• La presencia de claims que habiliten acceso clínico sensible o perfiles amplios.
• La existencia de controles compensatorios como validación de origen, backend token exchange o separación entre token de usuario y token técnico.

El cuarto paso es revisar registros y telemetría. CISA dice que no tiene constancia de explotación pública, no que tu entorno no haya sido tanteado. Si tienes capacidad de logging a nivel de proxy, gateway o aplicación, busca solicitudes salientes anómalas desde componentes OHIF hacia dominios no esperados, especialmente si se produjeron con cabeceras de autorización. En muchos hospitales esa visibilidad será imperfecta. Precisamente ese es uno de los problemas de fondo.

La quinta medida es operativa y antipática, pero necesaria: reducir confianza por defecto. Si un visor necesita obtener recursos remotos en nombre del usuario, esa capacidad debe estar encapsulada con reglas explícitas, no asumida como comportamiento general. Para algunos equipos esto implicará cambiar configuraciones. Para otros, rediseñar integración.

Los proveedores e integradores tienen un deber adicional. No basta con publicar una versión corregida. Deben comunicar activamente a clientes si distribuyen OHIF empaquetado, en qué versiones, bajo qué configuraciones y si el parche exige intervención manual en app-config.js. Un boletín ambiguo del tipo “se recomienda actualizar cuando sea posible” es exactamente la clase de prosa que produce incidentes evitables meses después.

Lo que este caso enseña sobre seguridad en software sanitario

El sector sanitario lleva años escuchando dos mensajes a la vez. El primero: digitalizar e interoperar más. El segundo: proteger mejor datos y sistemas. Ambos son correctos. El problema es que la velocidad de integración suele ir por delante de la madurez con la que se diseñan fronteras de confianza entre componentes.

OHIF no es una anomalía aislada; es un ejemplo muy visible de un patrón incómodo. En sanidad abundan aplicaciones web con acceso a datos sensibles, despliegues híbridos, autenticación federada, componentes de código abierto integrados por terceros y configuraciones arrastradas de una implementación a otra. Esa combinación genera valor clínico y deuda de seguridad a la vez.

El advisory también desmonta una ficción muy extendida: la de que las vulnerabilidades críticas en hospitales son siempre las que afectan a dispositivos médicos cerrados, firmware opaco o sistemas legacy imposibles de tocar. Esos problemas existen, claro. Pero cada vez más riesgo real está en la capa web de acceso clínico, justo donde identidad, experiencia de usuario e integración se encuentran. Un visor aparentemente “de presentación” puede convertirse en una puerta lateral a la sesión autenticada del profesional.

Esto enlaza con una discusión regulatoria y de gobernanza que no debería quedar reservada al departamento jurídico. Cuando una aplicación sanitaria maneja credenciales de usuario y datos clínicos, la seguridad de configuración deja de ser un asunto cosmético. Es control esencial. Si el hospital delega la integración en un proveedor, el riesgo no desaparece: cambia de manos durante el proyecto y vuelve en forma de responsabilidad cuando algo falla.

Privacidad y cumplimiento: no hace falta que haya ransomware para tener un problema serio

El aviso de CISA es técnico, no regulatorio. Aun así, el encaje con obligaciones de privacidad y ciberseguridad es bastante directo. Si la explotación de CVE-2026-12473 permite obtener el token de un clínico y ese token se usa para acceder a información de pacientes, la organización podría estar ante una violación de seguridad de los datos personales en el sentido del artículo 4.12 del RGPD: una brecha que ocasiona destrucción, pérdida, alteración, comunicación o acceso no autorizado a datos personales.

Eso no significa que cada instalación vulnerable deba notificarse a la autoridad. No funciona así. Lo que sí implica es que, si existe un incidente con compromiso real o razonablemente probable de datos personales, entra en juego la lógica del artículo 33 del RGPD, con notificación a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia, salvo que sea improbable que la brecha constituya un riesgo para los derechos y libertades de las personas físicas. Si el riesgo es alto para los afectados, también puede activarse el artículo 34 sobre comunicación a los interesados.

En el ámbito sanitario, además, hablamos de categorías especiales de datos bajo el artículo 9 del RGPD. No es un matiz ornamental. Cuando el dato potencialmente expuesto es clínico, la valoración de riesgo cambia de tono y de intensidad.

Si miramos a la ciberseguridad operativa europea, también asoma NIS2. La directiva exige a entidades esenciales e importantes medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de seguridad, incluyendo políticas de análisis de riesgos, gestión de incidentes, seguridad en adquisición, desarrollo y mantenimiento de redes y sistemas, y evaluación de la eficacia de las medidas, entre otros elementos recogidos en el artículo 21 de NIS2. Un fallo que nace de una combinación de configuración por defecto, validación insuficiente y manejo inseguro de tokens encaja bastante bien en lo que NIS2 pretende que se gobierne mejor, especialmente en operadores sanitarios cubiertos por la norma en su transposición nacional.

Para organizaciones que ya trabajan con marcos como NIST CSF 2.0, el caso toca funciones muy concretas: gobernanza de dependencias externas, gestión de identidades, protección de datos, validación de configuración y monitorización. No hace falta forzar la lectura. La pregunta práctica es simple: ¿tu programa de seguridad identifica y controla de forma explícita las aplicaciones que pueden emitir peticiones autenticadas a destinos variables?

Y hay un punto adicional que muchas auditorías todavía infravaloran: la evidencia de configuración efectiva. Una política interna que diga “se restringen comunicaciones a orígenes autorizados” vale poco si nadie puede demostrar qué orígenes están permitidos hoy en producción, en qué fichero, bajo qué cambio aprobado y para qué caso de uso.

Lo que un comité de riesgos debería preguntar esta semana

Si esta noticia llega a comité, no conviene reducirla a “hay un parche”. El comité útil pregunta algo más incómodo.

Primero: ¿tenemos visibilidad de componentes open source clínicos integrados por terceros? Si la respuesta honesta es “parcial”, el problema no es solo OHIF. Es la dependencia estructural de software cuyo nombre real ni siquiera aparece en el inventario ejecutivo.

Segundo: ¿sabemos qué aplicaciones sanitarias reenvían tokens de usuario en llamadas salientes? No qué aplicaciones “usan SSO”, sino cuáles actúan en nombre del usuario hacia otros destinos. Ahí está el quid.

Tercero: ¿tenemos capacidad para retirar o neutralizar funciones no utilizadas en configuraciones heredadas? Muchas organizaciones descubren demasiado tarde que su deuda de configuración es mayor que su deuda de parcheo.

Cuarto: ¿podemos detectar si una aplicación clínica ha realizado solicitudes autenticadas a dominios no previstos? Si la respuesta es no, el problema ya no es solo prevención, sino capacidad de investigación forense.

Quinto: ¿los contratos con integradores obligan a comunicar componentes embebidos, versiones y acciones manuales post-parche? Porque el parche automático es estupendo hasta que no lo es, y este caso exige cambios de configuración además de actualización.

Un comité serio también debería mirar la dimensión humana sin convertirla en excusa. Sí, la explotación requiere interacción del usuario. No, la mitigación principal no puede consistir en culpar al clínico por abrir un enlace. Cuando un flujo de trabajo normal y una arquitectura permisiva permiten exfiltrar el token, el fallo es de diseño y control, no de “concienciación insuficiente” como comodín universal.

Lecciones para desarrollo seguro: lo que los equipos deberían dejar de hacer

Este advisory debería circular entre equipos de producto, no solo entre administradores de sistemas. Hay varias lecciones de desarrollo seguro muy concretas.

La primera: nunca adjuntes automáticamente credenciales de usuario a peticiones cuyo destino pueda estar influido por entrada externa sin validación estricta. Parece básico. Se sigue haciendo. A veces por conveniencia, a veces por herencia, a veces porque nadie modeló la amenaza completa.

La segunda: el frontend no es un espacio inocente. En aplicaciones clínicas, una URL manipulada puede ser suficiente para disparar una acción con contexto autenticado. Si el equipo de seguridad solo revisa backend y red, llega tarde a media película.

La tercera: las configuraciones por defecto son parte del producto. Si una fuente de datos vulnerable viaja incluida y activable por defecto, la distinción entre “código” y “configuración” consuela poco al cliente afectado. La seguridad del producto incluye el diseño de defaults, la documentación y la fricción impuesta a opciones peligrosas.

La cuarta: los nombres honestos ayudan, pero no sustituyen controles. Que una variable se llame dangerouslyAllowedOriginsForAuthenticatedEnvironments es mejor que llamarla origins. Aun así, si luego nadie la define o la rellena con dominios demasiado amplios, el nombre solo servirá para adornar el informe post-incidente.

La quinta: minimiza privilegios del token y separa contextos. Siempre que sea posible, conviene evitar que componentes de recuperación genérica operen con el mismo token amplio del usuario. Diseños con intercambio de tokens, audiencias acotadas y backend intermediario reducen daño. Exigen más trabajo, sí. También evitan sustos bastante caros.

No hay explotación pública conocida. Esa frase merece una lectura adulta

CISA indica que no tiene conocimiento de explotación pública dirigida específicamente a esta vulnerabilidad. Es una frase útil y, a la vez, una de las más malinterpretadas en gestión de vulnerabilidades.

No significa que el fallo sea poco explotable. El vector CVSS ya sugiere lo contrario: acceso por red, baja complejidad, sin privilegios previos, con interacción del usuario y alto impacto en confidencialidad. Tampoco significa que no haya pruebas de concepto privadas o explotación oportunista no reportada. Significa exactamente lo que dice: CISA no tiene constancia pública en este momento.

Para un hospital o proveedor sanitario, esa frase debería servir para priorizar sin entrar en pánico, no para posponer. Hay una corrección disponible desde el 18 de mayo de 2026. El advisory público salió el 25 de junio de 2026. Ese mes largo entre corrección y difusión oficial deja una ventana suficiente para que actores atentos analicen cambios, entiendan la ruta vulnerable y preparen explotación. No hace falta que exista una campaña masiva para que el riesgo sea real en objetivos concretos.

Además, las vulnerabilidades que combinan enlace manipulado, autenticación federada y exfiltración silenciosa tienen algo que gusta mucho a un atacante paciente: poca visibilidad inicial. No bloquean sistemas. No fuerzan cifrado. No necesariamente disparan alarmas obvias. Encajan bien en fases de acceso o reconocimiento más discretas.

La conclusión incómoda: el problema no es solo parchear OHIF, es dejar de confiar a ciegas en la integración

La noticia inmediata es clara: OHIF Viewers DICOM hasta la versión 3.12.0 tiene una vulnerabilidad, CVE-2026-12473, que puede permitir el robo del token OIDC de un clínico mediante un enlace manipulado en determinadas integraciones. La corrección existe en la v3.12.2. Si usas autenticación y determinados conectores, debes además definir una allowlist de orígenes y limpiar fuentes de datos no utilizadas.

La noticia importante, la que merece algo más que un ticket de parcheo, es otra. El software sanitario moderno está lleno de componentes que hacen peticiones en nombre del usuario, transportan identidad federada y operan bajo una confianza implícita que no siempre está justificada. Ese es el verdadero mensaje detrás del advisory de CISA.

Si diriges seguridad, infraestructura, arquitectura clínica o cumplimiento, esta vulnerabilidad te plantea una pregunta desagradablemente concreta: ¿qué aplicaciones en tu entorno pueden mandar el token de un profesional a un destino equivocado sin que nadie lo note? Si no puedes responderla con precisión, el problema no empieza ni termina en OHIF.

Actualizar hoy es obligatorio. Revisar la arquitectura de confianza que hizo posible este fallo es lo que separa una reacción decente de una estrategia madura. Lo demás, incluida la tentación de resolverlo con una campaña de phishing awareness y dos diapositivas, es maquillaje.