mySCADA myPRO Manager corrige dos fallos de autenticación, uno clasificado como crítico
mySCADA myPRO Manager enfrenta ahora dos fallos de seguridad divulgados, incluido uno con una puntuación de 9.8, debido a que interfaces sensibles aceptaban solicitudes sin autenticación. Las versiones 2.1 y anteriores están afectadas. La versión 2.2 incorpora las correcciones del proveedor.
La vulnerabilidad más grave expone funciones de gestión privilegiadas a través de la API de comandos del producto. La segunda expone un endpoint HTTP capaz de enviar mensajes de texto arbitrarios mediante un módem GSM conectado. Ninguna de las dos vías exige una cuenta autenticada antes de aceptar la solicitud correspondiente.
Esto crea un marcado conflicto entre la gestión industrial práctica y el control de acceso básico. myPRO Manager ayuda a los operadores a configurar entornos conectados, pero las interfaces vulnerables no verificaban quién emitía comandos sensibles. El problema va más allá de una aplicación web convencional porque los productos mySCADA parecen estar presentes en entornos de tecnología operativa de todo el mundo.
La respuesta inmediata es clara. Los operadores deben localizar las instalaciones afectadas, actualizarlas y verificar qué redes pueden alcanzar sus interfaces de gestión. El trabajo más difícil comienza después, especialmente en sistemas aislados, instalaciones no gestionadas y entornos donde el tiempo de inactividad complica las actualizaciones.
Qué cambió en mySCADA myPRO Manager
La divulgación identifica dos fallos de autorización independientes, pero la vulnerabilidad de la API de comandos conlleva un mayor riesgo operativo.
El 15 de septiembre de 2026, CISA publicó un aviso industrial sobre mySCADA myPRO Manager. Identifica CVE-2026-73807 y CVE-2026-82567 en las versiones 2.1 y anteriores.
La versión 2.2 figura como no afectada. mySCADA Technologies afirma que esta versión resuelve ambos problemas y recomienda actualizar a la versión disponible más reciente.
CVE-2026-73807 afecta a la API de comandos, es decir, la interfaz que utilizan los componentes de software para emitir solicitudes de gestión. Según el registro oficial, la API no aplica correctamente la autenticación para las funciones privilegiadas.
Un atacante no necesita una cuenta existente. Necesita acceso de red a la interfaz afectada y, a continuación, puede intentar invocar funciones normalmente reservadas para un administrador autorizado.
El registro CVE asigna al fallo una puntuación CVSS 3.1 de 9.8, dentro del rango crítico. Su vector describe una vulnerabilidad accesible por red, con baja complejidad de ataque, sin privilegios necesarios ni interacción del usuario requerida.
El registro también asigna una puntuación CVSS 4.0 de 9.3. Ambas evaluaciones indican un alto impacto potencial sobre la confidencialidad, la integridad y la disponibilidad dentro del sistema vulnerable.
Esta puntuación no demuestra que todas las instalaciones estén igual de expuestas. CVSS mide la gravedad técnica bajo supuestos estandarizados. No sabe si una API de comandos concreta está detrás de varios cortafuegos o si es accesible desde una red no confiable.
CVE-2026-82567 afecta a la pasarela de notificaciones, que conecta myPRO Manager con la entrega de SMS mediante un módem GSM. El endpoint HTTP vulnerable acepta un número de teléfono y un mensaje, y después indica al módem que envíe ese texto.
El endpoint no exige autenticación previamente. Por ello, un atacante con acceso de red adecuado puede enviar destinatarios y mensajes arbitrarios mediante el módem conectado.
Esta segunda vulnerabilidad tiene una puntuación CVSS 3.1 de 6.3, clasificada como media. Su vector utiliza una vía de ataque de red adyacente, en lugar de la vía de red más amplia asignada a CVE-2026-73807.
Esa diferencia importa. El fallo de SMS generalmente requiere que el atacante alcance la red local o adyacente pertinente. El fallo crítico de la API de comandos tiene una clasificación de ataque por red más amplia.
Sin embargo, ambos problemas comparten la misma debilidad subyacente. Una operación sensible acepta entradas antes de determinar si el solicitante tiene permiso para realizarla.
CISA atribuye los hallazgos a los investigadores de SECNORA Rajivarnan R. y Shirshak. Las vulnerabilidades fueron descubiertas externamente y coordinadas mediante el proceso de divulgación de sistemas de control industrial de la agencia.
El aviso sitúa los despliegues afectados en los sectores de fabricación crítica, energía, alimentación y agricultura, transporte, y agua y aguas residuales. Describe el despliegue como mundial y señala que la sede del proveedor está en Chequia.
Estas etiquetas sectoriales no demuestran que cada instancia afectada controle directamente un proceso físico. Sí muestran por qué una brecha de autenticación en este producto merece una atención estrecha por parte de los equipos de tecnología operativa.
Por qué la falta de autenticación importa más en las redes industriales
Una solicitud que llega a una interfaz de gestión industrial puede tener consecuencias que van mucho más allá del proceso de software que la recibe.
La autenticación responde una pregunta básica: ¿quién realiza esta solicitud? La autorización responde la siguiente: ¿qué puede hacer esa identidad?
CVE-2026-73807 vulnera ese límite en torno a las funciones de gestión privilegiadas. La descripción oficial no enumera todas las funciones expuestas, por lo que los defensores no deben asumir un resultado concreto más allá del acceso documentado.
Aun así, “funciones de gestión privilegiadas” indica un fallo significativo de confianza. Una interfaz diseñada para la administración aceptaba solicitudes de red sin aplicar el control que debería separar a los administradores de otros sistemas.
El vector CVSS refleja esta preocupación. Asume que no se requieren privilegios ni interacción del usuario, que la complejidad es baja y que existe un posible impacto elevado sobre la confidencialidad, la integridad y la disponibilidad.
En un sitio web empresarial, un fallo de control de acceso puede exponer datos o configuraciones de la aplicación. En un entorno de tecnología operativa, el software de gestión puede estar cerca de sistemas que supervisan equipos, recopilan datos de procesos, distribuyen alarmas o respaldan decisiones de los operadores.
La consecuencia exacta depende de cada despliegue. El diseño de red, los equipos conectados, la configuración del producto y las funciones expuestas determinan el riesgo real.
Esa variabilidad hace esencial el contexto de los activos. Una instalación de laboratorio desconectada no presenta la misma exposición que un gestor de producción accesible desde un segmento corporativo compartido.
Una instalación expuesta a Internet representa un caso aún más urgente. Aunque el aviso no publica un recuento de sistemas expuestos, cualquier acceso directo no confiable elimina una barrera defensiva importante.
La debilidad de SMS presenta un impacto más limitado, pero ilustra el mismo problema arquitectónico. Las pasarelas de notificaciones suelen transportar alertas operativas en las que se espera que los usuarios confíen.
Un atacante que envíe mensajes arbitrarios mediante un módem conocido podría generar confusión, suplantar notificaciones rutinarias o consumir capacidad de mensajería. El registro oficial no afirma que los atacantes puedan leer mensajes existentes ni reconfigurar el módem.
Los defensores deben mantener esa distinción. La capacidad divulgada es la transmisión no autorizada de SMS, no un control demostrado de todas las funciones de notificación.
Aun así, los mensajes arbitrarios pueden importar durante un incidente. Los operadores pueden depender de las alertas de texto cuando están fuera de una sala de control o cuando falla otro canal de comunicación.
Un mensaje fraudulento podría confundirse con una alerta legítima del sistema. Una oleada de mensajes no deseados también podría dificultar el reconocimiento de las notificaciones reales.
Estos escenarios son consideraciones razonables de riesgo, no informes de explotación documentada. El aviso establece la vía de envío no autorizado, mientras que cada organización debe evaluar sus consecuencias operativas.
El contexto industrial también modifica la rapidez con la que los equipos pueden aplicar parches. Los entornos de producción pueden requerir interrupciones planificadas, pruebas de compatibilidad, coordinación con el proveedor o revisión de seguridad antes de modificar el software de gestión.
Estos controles reducen las interrupciones accidentales, pero pueden prolongar el período durante el que permanece instalado código vulnerable. Por ello, las restricciones de red son importantes antes, durante y después del proceso de actualización.
La comodidad chocó con el control de acceso
El problema central no es una cadena de explotación avanzada, sino una funcionalidad sensible expuesta sin un control efectivo de identidad.
Las API de gestión existen porque la administración manual no escala. Permiten que componentes de software, consolas y servicios intercambien comandos mediante solicitudes definidas.
Las pasarelas de notificaciones ofrecen una comodidad similar. Conectan eventos industriales con canales de comunicación, permitiendo al software entregar alertas mediante un módem GSM.
Ambos diseños pueden ser útiles. Su seguridad depende de tratar cada solicitud entrante como no confiable hasta que el solicitante demuestre una identidad aceptada y reciba permiso explícito.
Los fallos divulgados muestran qué ocurre cuando esta secuencia se rompe. En la API de comandos, un solicitante puede acceder a funcionalidades privilegiadas sin la aplicación de autenticación esperada.
En la pasarela de notificaciones, el endpoint HTTP acepta los datos de destino y del mensaje antes de verificar a un usuario autorizado. Después transmite el mensaje solicitado al módem conectado.
No se requiere ingeniería social en ninguna de las vías documentadas. Ningún administrador necesita abrir un archivo malicioso ni aprobar una solicitud.
Eso no hace que la explotación sea automática. El atacante aún debe obtener la conectividad de red necesaria, identificar la interfaz y enviar una solicitud que el servicio acepte.
Estos requisitos explican por qué la arquitectura de red sigue siendo importante. Un servicio vulnerable aislado dentro de una zona de gestión estrictamente controlada ofrece menos vías de ataque que uno expuesto en amplias redes internas.
Sin embargo, la segmentación es un control compensatorio, no una corrección de la falta de autenticación. Las redes cambian, las reglas de cortafuegos se acumulan, las vías de acceso remoto se amplían y los dispositivos internos comprometidos pueden eludir los supuestos sobre ubicaciones confiables.
El diseño más seguro combina capas. La aplicación autentica cada solicitud sensible, la autorización limita las acciones disponibles y la red restringe qué sistemas pueden alcanzar la interfaz.
Los registros deben documentar después la actividad aceptada y rechazada. La supervisión debe identificar comandos inusuales, direcciones de origen inesperadas y destinos SMS irregulares.
CVE-2026-73807 y CVE-2026-82567 importan porque debilitan la capa de aplicación de ese modelo. La versión 2.2 restaura la corrección de software respaldada por el proveedor, mientras que los controles de red reducen la exposición a su alrededor.
El contraste también explica la diferencia de gravedad. El problema de la API de comandos se puntúa por sus posibles efectos elevados sobre las tres propiedades centrales de seguridad del sistema vulnerable.
El endpoint SMS recibe calificaciones de impacto más bajas y una clasificación de red adyacente. Su resultado documentado se limita al envío de mensajes arbitrarios mediante un módem conectado.
Tratar ambos hallazgos como idénticos ocultaría las prioridades de corrección. Ignorar el problema con menor puntuación pasaría por alto una vía práctica de abuso a través de un canal de notificación confiable.
Por tanto, los equipos deben priorizar la exposición crítica de la API de comandos mientras corrigen ambas vulnerabilidades mediante la misma actualización. Un único límite de versión simplifica la decisión de software, aunque el trabajo de despliegue siga siendo complicado.
El proveedor afirma que los dispositivos conectados notifican a los usuarios dentro de mySCADA Pro Manager cuando hay una nueva versión disponible. Los entornos sin conexión requieren que los operadores obtengan la actualización por separado desde la página de descarga del gestor.
Los sistemas desconectados merecen especial atención. Su aislamiento puede reducir la exposición, pero también elimina las notificaciones automáticas de actualización y puede ocultar software desactualizado a las herramientas centralizadas de inventario.
Una brecha de aire nunca debe sustituir el conocimiento de las versiones. Los medios portátiles, las conexiones temporales de mantenimiento, los portátiles y el enrutamiento mal configurado pueden crear rutas que no existían durante el diseño original.
El parche está claro, pero persiste el riesgo de despliegue
La versión 2.2 cierra la brecha de software documentada, pero las organizaciones aún necesitan pruebas de que cada instalación afectada alcanzó el estado corregido.
La corrección del proveedor es sencilla: actualizar mySCADA myPRO Manager a la versión 2.2 o posterior. El rango afectado termina en la versión 2.1.
Esta claridad elimina una fuente habitual de confusión. Los equipos no necesitan comparar varios parches con distintas ramas para estos dos CVE.
El desafío operativo es el inventario. Las organizaciones deben identificar dónde se ejecuta el producto, qué versión utiliza cada instalación y qué interfaces son accesibles desde cada zona de red.
Esta tarea puede revelar brechas no relacionadas con el nuevo aviso. El software industrial puede estar instalado en estaciones de trabajo de ingeniería, sistemas de gestión dedicados, dispositivos temporales de puesta en marcha o equipos mantenidos fuera de los procesos empresariales habituales.
Un inventario fiable debe incluir la versión de la aplicación, la identidad del host, la ubicación de red, el propietario del sistema, la función operativa y las rutas de comunicación permitidas. También debe registrar si hay un módem GSM conectado.
El detalle del módem determina si la ruta SMS documentada existe en un despliegue determinado. Una instalación sin ese componente no presenta el mismo escenario práctico de CVE-2026-82567.
La API de comandos requiere un análisis independiente. Los equipos deben identificar todas las fuentes autorizadas a acceder a ella y verificar si alguna ruta se origina en redes de usuarios, segmentos inalámbricos, sistemas de acceso de proveedores o la internet pública.
Una regla de firewall por sí sola no demuestra aislamiento. Las pruebas de flujo de paquetes y la revisión de la configuración ofrecen pruebas más sólidas de que solo los sistemas de gestión previstos pueden conectarse.
Antes de actualizar, los operadores deben confirmar los procedimientos de copia de seguridad y recuperación. También deben comprender las dependencias que podrían fallar si el gestor cambia su comportamiento tras la actualización.
Las pruebas deben centrarse en las operaciones normales de gestión, la entrega de alarmas, las notificaciones SMS, la autenticación y la conectividad con los sistemas gestionados. El objetivo es detectar problemas de compatibilidad antes del despliegue en producción.
Después, los equipos deben registrar la versión instalada tras el cambio. Una notificación de actualización o un instalador descargado no demuestra que todos los hosts hayan completado correctamente la actualización.
Cuando no sea posible aplicar el parche de inmediato, reducir la exposición se vuelve urgente. El acceso a las interfaces de gestión debe limitarse a sistemas explícitamente autorizados mediante firewalls y zonas de red segmentadas.
La administración remota debe utilizar rutas de acceso controladas en lugar de exponer la aplicación directamente. La guía industrial consolidada de CISA recomienda minimizar la exposición, separar las redes de control de las redes empresariales y utilizar métodos seguros de acceso remoto.
Su guía de defensa en profundidad considera la arquitectura de red, el control de acceso, la monitorización y la respuesta a incidentes como salvaguardas complementarias. Ninguna debe considerarse un reemplazo permanente del software corregido.
Los controles temporales deben tener responsables y fechas de vencimiento. De lo contrario, una restricción de firewall de emergencia puede convertirse silenciosamente en la respuesta a largo plazo mientras la versión vulnerable sigue instalada.
La monitorización también necesita señales específicas del despliegue. Los equipos pueden revisar las conexiones a la API de comandos, los eventos de autenticación rechazados tras la actualización y las solicitudes inusuales a los puntos de conexión de notificaciones.
En los sistemas habilitados para SMS, los operadores deben comparar la actividad del módem con las alertas esperadas. Los números de destino no reconocidos, el contenido inusual de los mensajes y una frecuencia de envío anómala merecen investigación.
Los registros históricos pueden ayudar a determinar si se produjo actividad sospechosa antes de la corrección. Sin embargo, la ausencia de una entrada de registro no puede demostrar que no hubo ningún intento si el punto de conexión vulnerable carecía de un registro adecuado.
Los equipos de respuesta a incidentes deben conservar los registros relevantes de red, host, aplicación y módem. Si la actividad parece sospechosa, deben seguir los procedimientos establecidos de escalado y notificación.
El aviso no proporciona una narrativa pública de explotación. Esto limita lo que los defensores pueden concluir sobre el comportamiento de los atacantes, las herramientas o las víctimas observadas.
No reduce la gravedad técnica de una ruta de gestión sin autenticación. La exposición y el impacto en la misión deben determinar la rapidez de la respuesta de cada organización.
mySCADA ha afrontado hallazgos graves anteriormente
Las nuevas fallas forman parte de un patrón más amplio en el que las funciones de gestión se convierten en límites de seguridad que los atacantes pueden poner a prueba directamente.
CISA ha publicado avisos anteriores relacionados con productos mySCADA. Estos casos previos no demuestran una causa técnica compartida, pero aportan contexto útil para los defensores.
En 2022, CISA describió una vulnerabilidad de inyección de comandos en mySCADA myPRO versiones 8.26.0 y anteriores. Un usuario autenticado podía modificar parámetros y ejecutar comandos del sistema operativo.
Ese problema anterior de myPRO tenía una puntuación CVSS 3 de 9.9. El proveedor recomendó actualizar a la versión 8.27.0 o posterior.
La falla de la API de comandos de 2026 difiere de forma crucial. Su vector publicado no requiere privilegios, mientras que el problema de 2022 requería un usuario autenticado.
Los productos y los esquemas de versiones también difieren en los registros, por lo que los operadores no deben inferir una ruta de actualización directa entre esos avisos. Cada instalación afectada debe compararse con la información específica del producto y la versión.
Un aviso independiente de 2025 cubrió varias vulnerabilidades de myPRO Manager, incluida la inyección de comandos del sistema operativo. Ese historial refuerza la necesidad de tratar los componentes de gestión como activos de alto valor.
La lección no es que un proveedor sea especialmente vulnerable. Las interfaces administrativas de los productos industriales concentran regularmente capacidades que los atacantes valoran.
Exponen configuración, comunicaciones, credenciales, actualizaciones o conexiones con entornos controlados. Por tanto, un único control ausente puede socavar varias salvaguardas posteriores.
Por ello, la gestión de vulnerabilidades debe rastrear los productos por función, no solo por número de CVE. Un servidor de gestión merece prioridad porque su función puede amplificar el impacto de una vulneración.
El mismo razonamiento se aplica a los dispositivos de acceso remoto, las estaciones de trabajo de ingeniería, los historiadores de datos y las pasarelas de notificaciones. Su proximidad a las operaciones otorga a las debilidades de software comunes una mayor relevancia dependiente del contexto.
Las organizaciones también deben evitar depender por completo de las puntuaciones destacadas. CVE-2026-82567 tiene una puntuación media, pero su abuso aún podría interrumpir el proceso de alertas de confianza de una instalación.
A la inversa, una puntuación de 9.8 no demuestra que una instancia aislada pueda ser atacada desde internet. Indica características técnicas graves una vez que un atacante alcanza el servicio vulnerable.
La priorización eficaz combina gravedad, exposición, explotabilidad, función operativa y dificultad de recuperación. También considera si un sistema dispone de una versión corregida fácilmente disponible.
En este caso, la versión corregida existe. Esto hace cada vez más difícil justificar el uso prolongado de la versión 2.1 o anterior, salvo que una limitación operativa impida el despliegue.
Si existe tal limitación, la dirección debe documentarla. El registro debe identificar al responsable, explicar la dependencia, enumerar los controles temporales y definir la próxima fecha de revisión.
Esto convierte el retraso del parche en una decisión de riesgo gestionada. Sin ese proceso, el retraso se convierte en una opción predeterminada invisible.
Lo que los operadores deben vigilar a continuación
Las próximas señales útiles son una cobertura de actualización verificada, pruebas de explotación y la confirmación de que las interfaces sensibles ya no son ampliamente accesibles.
Primero, las organizaciones deben medir la adopción de la versión 2.2 o posterior. La métrica interna más importante no es si se descargó un parche, sino si cada activo afectado informa ahora de una versión corregida.
Esta medición debe incluir sistemas fuera de las herramientas empresariales habituales. Las instalaciones desconectadas, los dispositivos gestionados por contratistas y los entornos de prueba pueden conservar versiones vulnerables mucho después de que terminen las actualizaciones de producción.
Un resultado completo refuerza la conclusión de que el riesgo inmediato de software ha sido contenido. Los activos no identificados o inaccesibles debilitan esa conclusión.
Segundo, los defensores deben vigilar las fuentes autorizadas en busca de cambios en el estado de explotación. Nuevo código de prueba de concepto, ataques confirmados o la inclusión en un catálogo gubernamental de explotación cambiarían la urgencia de la respuesta.
En el momento de la publicación, el material disponible del aviso describe las vulnerabilidades y las correcciones sin establecer una campaña de explotación activa. Los lectores deben distinguir esa ausencia de una prueba de que la explotación sea imposible.
La información sobre amenazas puede cambiar rápidamente tras la divulgación. Los atacantes obtienen un nombre de producto claro, el rango de versiones afectadas, la categoría de debilidad y una descripción de la funcionalidad expuesta.
Tercero, los operadores deben validar la arquitectura circundante. Actualizar la aplicación no debe poner fin a la revisión de la exposición de las interfaces de gestión.
Un escaneo desde zonas de red apropiadas puede confirmar si la API de comandos y la pasarela de notificaciones aceptan conexiones únicamente de fuentes aprobadas. La revisión del firewall debe producir la misma respuesta.
Si un segmento amplio todavía puede acceder a estos servicios, el entorno sigue innecesariamente expuesto a defectos futuros. Un parche cierra vulnerabilidades conocidas, mientras que la segmentación limita el radio de impacto de la próxima vulnerabilidad desconocida.
Los equipos también deben verificar el comportamiento de la aplicación tras la actualización. Los comandos sensibles deben requerir acceso autenticado y autorizado, y el punto de conexión SMS debe rechazar solicitudes no autenticadas.
Estas pruebas deben utilizar procedimientos aprobados en un entorno controlado. Realizar sondeos en producción sin coordinación puede generar riesgo operativo.
Los hallazgos también justifican revisar el diseño de cuentas y accesos. Las organizaciones deben identificar quién administra el gestor, qué cuentas de servicio interactúan con él y cómo se protegen las credenciales.
El principio de mínimo privilegio sigue siendo importante después de restablecer la autenticación. Una cuenta válida debe recibir únicamente las funciones necesarias para su función.
Los registros merecen una comprobación final. Los equipos de seguridad necesitan suficiente detalle para vincular una solicitud con una fuente, identidad, acción, resultado y hora.
Para las notificaciones respaldadas por módem, los registros deben vincular cada mensaje con el evento o usuario que lo inició. Esto ayuda a distinguir la automatización legítima del uso no autorizado.
Por tanto, la respuesta práctica a mySCADA myPRO Manager es más amplia que instalar una versión. Primero aplique el parche; después, verifique la accesibilidad, la aplicación de controles de acceso, los registros y la cobertura de activos.
Si su organización utiliza myPRO Manager, ¿puede demostrar que cada instalación está en la versión 2.2 o posterior? ¿También puede demostrar que los sistemas no confiables no pueden acceder a interfaces privilegiadas?
Estas dos respuestas definen el resultado a corto plazo. Una actualización confirmada cierra las fallas documentadas. El acceso restringido a la red y la autenticación probada reducen la probabilidad de que la próxima interfaz pasada por alto se convierta en un incidente operativo.
