mySCADA myPRO Manager: dos fallos sin autenticación dejan expuestas funciones críticas y el envío de SMS

Un atacante con acceso de red al mySCADA myPRO Manager puede entrar en funciones privilegiadas sin autenticarse y utilizar un módem GSM conectado para enviar SMS arbitrarios. CISA publicó la alerta el 15 de septiembre de 2026 y sitúa la vulnerabilidad principal, CVE-2026-73807, en una puntuación CVSS 3.1 de 9,8.

El fabricante, mySCADA Technologies, ha corregido ambos problemas en la versión 2.2. La recomendación práctica no tiene mucho misterio, aunque sí una condición que suele complicarla: actualizar, retirar el producto de Internet y verificar qué redes pueden alcanzar su API. El software está desplegado en sectores como fabricación crítica, energía, alimentación y agricultura, transporte y agua y saneamiento. Es decir, no hablamos de una aplicación de oficina que pueda quedarse sin servicio hasta el próximo comité de cambios.

La alerta ICSA-26-258-03 no comunica explotación pública conocida contra estas vulnerabilidades. Eso reduce la evidencia de riesgo inmediato, pero no convierte un endpoint sin autenticación en una buena idea. En tecnología industrial, la ausencia de explotación observada suele significar que todavía no se ha visto, no que el problema haya dejado de existir.

El problema no es solo un bug: son dos controles básicos ausentes

MySCADA myPRO Manager es una herramienta de gestión y notificación asociada a entornos industriales. La alerta de CISA identifica dos fallos en versiones iguales o anteriores a la 2.1. Ambos requieren acceso de red, pero ninguno exige credenciales válidas. Esa combinación merece separar los impactos en lugar de esconderlos bajo una única etiqueta de severidad.

CVE-2026-73807: funciones de administración sin autenticación

El command API del producto no aplica correctamente la autenticación a funciones privilegiadas. Un atacante que pueda alcanzar la API desde la red puede acceder a capacidades de gestión sin demostrar quién es. CISA clasifica el fallo como CWE-862, Missing Authorization, porque el sistema no aplica adecuadamente la autorización necesaria para una operación privilegiada.

La diferencia entre autenticación y autorización no es académica. La autenticación responde a quién eres; la autorización, a qué puedes hacer. En este caso, el problema descrito por CISA combina una entrada sin autenticación efectiva con acceso a funciones que deberían estar reservadas a usuarios autorizados. La puntuación CVSS 3.1 es 9,8, con el vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Traducido a lenguaje operativo: el ataque puede realizarse por red, con baja complejidad, sin privilegios previos ni interacción de una víctima, y puede afectar a la confidencialidad, integridad y disponibilidad del sistema.

La métrica CVSS 4.0 publicada para el mismo fallo es 9,3, también crítica. La variación no implica que el producto se haya vuelto menos peligroso; refleja una metodología distinta para valorar el impacto. Las organizaciones no deberían escoger la puntuación que les resulte más cómoda para retrasar el parche. Si una API de administración acepta peticiones privilegiadas sin una comprobación robusta de identidad, la decisión técnica sigue siendo la misma: eliminar la exposición o actualizar.

CVE-2026-82567: el módem GSM puede convertirse en una pasarela de abuso

El segundo fallo afecta al gateway de notificaciones. El producto expone un endpoint HTTP sin autenticación que permite indicar un número de teléfono y un mensaje. Si existe un módem GSM conectado, el sistema envía el SMS solicitado. No hace falta comprometer primero una cuenta ni superar un control de acceso.

CISA asigna a CVE-2026-82567 una puntuación CVSS 3.1 de 6,3 y la clasifica como media. Su vector indica acceso adyacente a la red, ausencia de privilegios y un impacto limitado en confidencialidad, integridad y disponibilidad. La calificación inferior a la de CVE-2026-73807 no debe interpretarse como irrelevancia. El envío arbitrario de mensajes puede generar costes, saturar canales de alerta, suplantar comunicaciones internas, provocar confusión durante un incidente o utilizar el número corporativo como infraestructura de spam.

Hay una ironía incómoda en este diseño: el canal creado para avisar de una condición industrial puede quedar disponible para que cualquiera con alcance de red fabrique sus propios avisos. En una planta, un SMS falso sobre una parada, una alarma o una intervención de mantenimiento no tiene que apagar directamente un proceso para causar daño. Basta con hacer que el personal reaccione ante información que parece proceder del sistema legítimo.

La exposición real depende de la arquitectura, no solo del CVSS

La alerta identifica como requisito el acceso de red. Eso es relevante porque elimina una lectura simplista: CISA no afirma que cualquier equipo conectado a Internet sea automáticamente explotable desde cualquier lugar. Pero tampoco permite relajarse. El riesgo se calcula a partir de todas las rutas que alcanzan el producto: Internet, redes de planta, saltos de administración remota, VPN, estaciones de ingeniería, redes corporativas y conexiones de proveedores.

Un servidor no necesita estar publicado en Internet para ser alcanzable por un atacante. Puede estar detrás de una VPN con credenciales robadas, en una red plana donde una estación de trabajo comprometida vea los mismos puertos, o en una zona de gestión accesible desde un salto remoto mal segmentado. Por eso la frase «no está expuesto a Internet» no es una prueba de seguridad. Es, como mucho, una observación parcial sobre una de las rutas posibles.

La recomendación de CISA es concreta: minimizar la exposición de los dispositivos y sistemas de control, situar las redes de control y los equipos remotos detrás de cortafuegos y aislarlos de las redes de negocio. Cuando sea necesario el acceso remoto, propone métodos más seguros como las redes privadas virtuales, con una advertencia que suele desaparecer en las presentaciones corporativas: una VPN también puede contener vulnerabilidades y solo es tan segura como los dispositivos conectados a ella.

Para evaluar la situación de myPRO Manager, el equipo de seguridad debería responder a cinco preguntas técnicas antes de cerrar el ticket:

1. ¿Qué instancias de mySCADA myPRO Manager existen y qué versión ejecuta cada una?
2. ¿Qué interfaces, puertos y endpoints del command API son accesibles desde cada segmento de red?
3. ¿Existe un módem GSM conectado y qué números o proveedores pueden recibir mensajes?
4. ¿Puede una estación de usuario, una cuenta de proveedor o un sistema de salto alcanzar el gateway de notificaciones?
5. ¿Qué registros permiten distinguir una notificación legítima de una petición HTTP que ordena enviar un SMS?

La última pregunta suele ser la más débil. Muchas organizaciones saben dónde está el servidor, pero no pueden reconstruir qué comandos administrativos recibió ni qué mensajes envió durante las últimas semanas. Sin registros de acceso, solicitudes, cambios de configuración y actividad del módem, una investigación posterior se convierte en una colección de suposiciones.

La prioridad es actualizar, pero el parche no sustituye a la contención

MySCADA Technologies ha corregido los fallos en la versión 2.2 y recomienda actualizar a la última versión. El fabricante indica que el producto puede notificar la disponibilidad de una nueva versión si el dispositivo está conectado a Internet; si no lo está, los usuarios pueden descargar mySCADA Pro Manager desde la página de descargas del proveedor.

La actualización debe tratarse como una intervención controlada sobre un activo industrial, no como una descarga rutinaria. Antes de cambiar la versión, el responsable técnico debe identificar dependencias, confirmar una ventana de mantenimiento, preservar la configuración necesaria y comprobar cómo se comportan el API y el módem GSM tras la actualización. La presión por aplicar el parche no justifica introducir una interrupción no evaluada en un proceso crítico; pero la criticidad del proceso tampoco es una excusa para dejar un servicio de administración sin autenticación.

Si la actualización no puede realizarse de inmediato, la contención debe reducir la superficie de ataque hasta que la versión 2.2 esté desplegada. El orden importa:

• Bloquear cualquier acceso directo desde Internet al command API y al gateway HTTP.
• Limitar mediante reglas de cortafuegos las redes, estaciones y cuentas de salto que pueden alcanzar el producto.
• Separar la red de control de la red corporativa y revisar las rutas permitidas entre ambas.
• Desactivar o desconectar el módem GSM si las notificaciones no son imprescindibles para la operación, después de analizar el impacto.
• Aplicar controles de acceso temporal y monitorizar solicitudes al API, especialmente aquellas relacionadas con funciones privilegiadas y envío de SMS.
• Actualizar el sistema operativo, el servidor web, la VPN y los equipos desde los que se administra la herramienta, porque el aislamiento pierde valor si el punto de acceso está comprometido.

Estas medidas no corrigen el defecto. Solo reducen la probabilidad de que una ruta disponible pueda utilizarlo. CISA recomienda realizar un análisis de impacto y una evaluación de riesgos antes de desplegar medidas defensivas. En una instalación industrial, bloquear una ruta puede afectar a alarmas, mantenimiento remoto o continuidad operativa; la decisión debe quedar documentada con el servicio afectado, la excepción aprobada y la fecha prevista de revisión.

Qué debería buscar un SOC y qué debería pedir compliance

La alerta no incluye una indicación de explotación pública conocida. Aun así, la respuesta no termina con una comprobación de versiones. El SOC debería buscar señales que encajen con los dos fallos, sin limitarse a buscar el identificador CVE en los logs, porque muchas aplicaciones no registran esa cadena.

Para CVE-2026-73807, son relevantes las peticiones al command API desde direcciones no habituales, solicitudes sin una secuencia normal de autenticación, llamadas a funciones de gestión fuera de las ventanas de mantenimiento y cambios administrativos realizados por cuentas, equipos o segmentos que no suelen operar la herramienta. También conviene revisar modificaciones de configuración, altas o bajas de usuarios, cambios en destinos de notificación y cualquier alteración de parámetros que afecten a la comunicación con el proceso industrial.

Para CVE-2026-82567, el indicador más directo es un volumen o patrón de SMS que no coincide con las reglas operativas: mensajes fuera de horario, destinatarios desconocidos, contenido no utilizado por los procedimientos de emergencia o peticiones procedentes de una estación que no debería tener acceso al gateway. El análisis debe incorporar los registros del operador de telecomunicaciones cuando estén disponibles. El propio producto puede no conservar una trazabilidad suficiente de cada mensaje.

El equipo de compliance debería pedir evidencias que permitan demostrar tres cosas: que la organización conocía el inventario afectado, que había valorado la exposición y que había aplicado una medida proporcional. No se trata de fabricar una carpeta para el auditor. Es la única forma de contestar con precisión si el producto se actualizó, quién aprobó una demora, qué rutas quedaron abiertas y si se detectó actividad anómala.

La evidencia útil incluye el inventario de activos y versiones, diagramas de segmentación, reglas de cortafuegos antes y después del cambio, tickets de actualización, resultados de pruebas, registros de acceso al API, trazas de SMS y la aceptación formal de cualquier riesgo residual. Si existe un proveedor externo con acceso remoto, también deben conservarse los permisos concedidos, el método de conexión y la revisión de sus dispositivos.

El vínculo con NIS2: no toda vulnerabilidad es un incidente notificable

La noticia afecta a productos desplegados en sectores que pueden coincidir con ámbitos cubiertos por la Directiva NIS2, pero no permite afirmar automáticamente que cada usuario de myPRO Manager esté sujeto a sus obligaciones. La aplicación depende del tipo de entidad, su tamaño, el sector y la transposición nacional correspondiente.

Cuando NIS2 resulte aplicable, el artículo 21 exige medidas de gestión de riesgos de ciberseguridad proporcionadas, incluida la seguridad de la cadena de suministro, la gestión de vulnerabilidades y la evaluación de la eficacia de las medidas. La existencia de un producto vulnerable no prueba por sí misma un incumplimiento. Lo que puede resultar difícil de defender es no disponer de un inventario, no conocer la versión instalada, mantener una interfaz administrativa expuesta sin justificación o ignorar una alerta del fabricante y de CISA sin evaluación documentada.

El artículo 23 de NIS2 establece obligaciones de notificación de incidentes significativos. Una alerta sobre CVE-2026-73807 no es automáticamente un incidente que deba notificarse. La pregunta es si ha existido un incidente real y si ha producido, o puede producir, una perturbación significativa de los servicios, pérdidas financieras sustanciales o daños considerables a terceros. Un acceso no autorizado a funciones privilegiadas, un envío masivo de SMS durante una emergencia o una alteración de un sistema conectado podrían cambiar la valoración. La organización necesita un proceso de decisión, no una regla mecánica basada en el nombre de la vulnerabilidad.

También hay una lección para la gestión de terceros. mySCADA Technologies tiene su sede en Chequia y CISA señala despliegues mundiales. Una empresa que opera una planta en España puede recibir la alerta estadounidense y, al mismo tiempo, tener obligaciones nacionales y europeas de gestión de riesgos. El origen de la alerta no determina la obligación, pero sí aporta inteligencia accionable que debería entrar en el proceso de vulnerabilidades.

DORA no convierte una alerta industrial en un incidente financiero, pero sí cambia la conversación

DORA se aplica a entidades financieras y a determinados proveedores de servicios de tecnologías de la información y la comunicación que les prestan servicios, no a cualquier software industrial utilizado en cualquier sector. Por tanto, no sería correcto presentar esta alerta como una obligación DORA universal.

La conexión puede aparecer cuando myPRO Manager forma parte de un servicio tecnológico utilizado por una entidad financiera o por un proveedor ICT crítico para prestar servicios a una entidad financiera. En ese caso, la organización deberá analizar si el componente queda dentro del servicio ICT relevante, qué dependencia operativa crea y qué controles contractuales y de gestión de riesgos resultan aplicables. El artículo 28 de DORA regula la gestión del riesgo de terceros ICT y exige que las entidades mantengan una estrategia para ese riesgo y un registro de información sobre sus acuerdos contractuales de servicios ICT. El artículo 30 establece elementos contractuales que deben cubrir, entre otros aspectos, la seguridad, la disponibilidad, el acceso y la asistencia.

La utilidad de DORA aquí no está en pegar la etiqueta regulatoria a cualquier vulnerabilidad. Está en obligar a preguntar quién controla el componente, qué servicio financiero depende de él, cómo se comunica una vulnerabilidad, qué derechos de auditoría existen y qué ocurre si el proveedor no puede corregirla con la rapidez necesaria. La pregunta incómoda para una entidad financiera es sencilla: ¿su inventario de terceros identifica solo el proveedor contratado o también los componentes técnicos que pueden afectar al servicio?

El error más caro sería tratarlo como un parche aislado

Las dos vulnerabilidades tienen un rasgo común: controles fundamentales que no deberían depender de una configuración sofisticada. La primera afecta a la autorización de funciones privilegiadas; la segunda, a la autenticación de una función capaz de provocar comunicaciones externas con coste y potencial de engaño. Son controles básicos, pero su ausencia aparece en sistemas que han crecido alrededor de una necesidad operativa concreta y rara vez han recibido el mismo escrutinio que una aplicación financiera.

El caso también expone una debilidad habitual en la gestión de activos OT: el inventario técnico puede saber que existe un servidor, pero no quién responde por el módem, qué proceso depende de él, qué proveedor tiene acceso y qué impacto tendría apagarlo. Sin esa información, la clasificación CVSS se queda corta como herramienta de decisión. La criticidad nace de la combinación entre vulnerabilidad, exposición, conectividad y función operativa.

El responsable de seguridad debería integrar el aviso en tres flujos que a menudo viven separados. El primero es la gestión de vulnerabilidades, para confirmar versiones y parchear. El segundo es la gestión de cambios, para probar y documentar la intervención. El tercero es la respuesta a incidentes, para definir qué se revisará si aparecen accesos anómalos o SMS no autorizados. Si cada equipo trabaja por su lado, el resultado será un parche aplicado sin pruebas, una regla de firewall que rompe las alertas o unos logs que nadie sabe interpretar.

La alerta ICSA-26-258-03 fue publicada el 15 de septiembre de 2026. La versión corregida es la 2.2. Esos dos datos deberían aparecer en el registro de decisión de cualquier organización afectada, junto con la versión instalada, la fecha de verificación y la justificación si la actualización no se ha completado. No hace falta esperar a que CISA anuncie explotación activa para hacer ese trabajo.

El mensaje final es menos espectacular que una intrusión confirmada, pero más útil: una red industrial aislada no es una licencia para descuidar la autenticación, y una VPN no convierte mágicamente en seguro un sistema vulnerable. Actualizar myPRO Manager a la versión 2.2, limitar sus rutas de red, revisar la actividad del API y conservar evidencias de la decisión son medidas concretas. La ciberseguridad industrial no mejora con la esperanza de que nadie mire ese endpoint. Mejora cuando nadie puede alcanzarlo sin autorización y cuando la organización puede demostrar por qué.