Los productos Schneider Electric SCADAPack x70 enfrentan una advertencia sobre credenciales en todas las versiones
Schneider Electric ha revelado una vulnerabilidad de credenciales que afecta a siete familias SCADAPack en todas las versiones, pese a que Secure Lock fue diseñado para proteger funciones sensibles de las RTU. La advertencia pone bajo escrutinio a los productos Schneider Electric SCADAPack x70 porque los operadores no pueden resolver el problema mediante un parche de firmware convencional.
CVE-2026-81861 afecta a Secure Lock, un mecanismo heredado de contraseñas utilizado para restringir el acceso a funciones de unidades terminales remotas. Schneider recomienda sustituir ese mecanismo por control de acceso basado en roles allí donde sea compatible. Los modelos más antiguos requieren en su lugar protecciones de red.
Esa diferencia importa. El problema central no es simplemente si un operador instaló la versión más reciente. Es si un controlador desplegado sigue dependiendo de un método de protección cuyas credenciales pueden quedar expuestas.
Los equipos afectados operan en entornos industriales distribuidos, incluidos los sectores de energía, fabricación, agua e infraestructuras remotas. Estos controladores suelen permanecer en servicio durante años, lo que hace que una migración de control de acceso sea más compleja que actualizar software empresarial convencional.
Los productos Schneider Electric SCADAPack x70 están afectados en todas las versiones
El alcance inusualmente amplio convierte una vulnerabilidad de producto en un problema de descubrimiento de activos y configuración.
CISA publicó su aviso sobre SCADAPack el 15 de septiembre de 2026. Identifica CVE-2026-81861 como una vulnerabilidad de credenciales insuficientemente protegidas que afecta a unidades terminales remotas Schneider Electric SCADAPack.
Los productos enumerados son:
SCADAPack 47x, todas las versiones
SCADAPack 47xi, todas las versiones
SCADAPack 47xd, todas las versiones
SCADAPack 470R, todas las versiones
SCADAPack 57x, todas las versiones
SCADAPack 3xx, todas las versiones
SCADAPack 32, todas las versiones
Una unidad terminal remota, o RTU, conecta equipos de campo con sistemas que supervisan y controlan operaciones distribuidas geográficamente. Una RTU puede recopilar mediciones, retransmitir alarmas, ejecutar lógica configurada y recibir comandos de una plataforma de supervisión.
Schneider publicó su notificación de seguridad inicial el 8 de septiembre. La empresa indicó que no aplicar sus mitigaciones incrementa el riesgo de acceso no autorizado mediante Secure Lock, con la posible exposición de información confidencial de configuración de las RTU.
El registro CVE clasifica el problema como CWE-522, o credenciales insuficientemente protegidas. Esta categoría abarca información de autenticación que un sistema almacena o transmite sin protección adecuada frente a su recuperación o uso indebido.
La vulnerabilidad recibió una puntuación base CVSS 4.0 de 5.9, clasificada como de gravedad media. El vector describe un ataque de red de baja complejidad, sin privilegios previos, con interacción activa del usuario y requisitos de ataque adicionales. Su impacto técnico evaluado es una alta pérdida de confidencialidad, sin impacto directo en integridad o disponibilidad en la puntuación base.
El aviso de CISA presenta una puntuación CVSS v3 de 6.5. Esas cifras utilizan versiones de puntuación distintas, por lo que los lectores no deberían interpretar la diferencia como una contradicción. Ambas evaluaciones describen un problema relevante de exposición de credenciales, no una vulnerabilidad de ejecución remota de código sin autenticación.
La vulnerabilidad no figuraba en el catálogo de Vulnerabilidades Conocidas Explotadas de CISA cuando se publicó el aviso. Los datos de decisión asociados de CISA tampoco informaron de explotación conocida y clasificaron el ataque como no fácilmente automatizable.
Esos detalles reducen la alarma inmediata, pero no eliminan el riesgo operativo. Una puntuación base media no tiene en cuenta la arquitectura de cada despliegue, la conectividad remota, la criticidad del proceso ni las limitaciones de recuperación.
La designación de “todas las versiones” también requiere una interpretación cuidadosa. Significa que el registro de productos afectados del proveedor no identifica una versión segura dentro de esas familias de productos. No significa que todos los controladores instalados presenten una exposición idéntica.
La exposición real depende del modo de control de acceso, la ruta de red, el modelo de dispositivo y los controles compensatorios disponibles. Un controlador aislado que utiliza controles basados en roles más sólidos presenta un riesgo distinto al de un dispositivo gestionado remotamente que sigue usando Secure Lock.
Esa distinción debería orientar la priorización. Los operadores deben identificar qué modelos poseen, qué método de control de acceso utiliza cada unidad y qué sistemas pueden observar o alcanzar su tráfico de gestión.
Esto va más allá de un hallazgo de un escáner. Los escáneres de vulnerabilidades pueden reconocer una familia de productos o una versión de firmware, pero quizá no determinen si Secure Lock sigue activo o si la RTU se encuentra detrás de una segmentación efectiva.
Secure Lock protegía el mensaje, pero no el secreto
La vulnerabilidad cuestiona el modelo de confianza de Secure Lock, no los algoritmos criptográficos mencionados en su diseño.
El investigador independiente Abhinav Agarwal informó de que la implementación probada protege los mensajes de Secure Lock con envoltura de claves AES-128 y un código de autenticación de mensajes HMAC-SHA256. La envoltura de claves AES protege el material de las claves, mientras que HMAC verifica que un mensaje no fue alterado sin conocer un secreto.
Según el análisis técnico del investigador, la implementación deriva ambas protecciones de constantes incrustadas en el componente de configuración de Windows y el firmware de la RTU. Sus pruebas hallaron que las claves resultantes eran idénticas en ambos componentes.
La consecuencia es más específica que una omisión de autenticación sin contraseña. Un atacante que capture un intercambio relevante de Secure Lock podría recuperar la contraseña sin conexión. La recuperación sin conexión implica que el atacante analiza tráfico registrado sin consultar repetidamente al dispositivo objetivo.
El investigador probó mensajes de establecimiento, cambio y desbloqueo de contraseña. Informó de que el intercambio protegido carecía de una entrada por dispositivo o por sesión, dejando a las instalaciones probadas dependientes de material criptográfico compartido.
Un valor por dispositivo haría que la clave derivada de una unidad fuera distinta de la de otra. Un valor por sesión haría que el material capturado fuera menos reutilizable entre intercambios separados. El investigador no encontró ninguna de esas propiedades en la ruta probada.
Por tanto, el mecanismo revelado crea una inversión incómoda. Secure Lock cifra y autentica sus mensajes, pero la confianza depositada en secretos compartidos incrustados debilita esas protecciones.
Los algoritmos sólidos no pueden compensar una clave que, en la práctica, es común a múltiples instalaciones. Si un adversario puede derivar las mismas claves de envoltura y autenticación, la envoltura criptográfica deja de proporcionar la separación esperada.
La contraseña probada controla funciones importantes. El investigador afirma que esas funciones incluyen escrituras de configuración, ejecución de comandos, actualizaciones de firmware, cambios de seguridad y acceso a determinados servicios de transferencia de archivos o terminal.
Sin embargo, recuperar una contraseña no equivale a controlar inmediatamente una RTU. El atacante aún necesita observar un intercambio de Secure Lock que cumpla los requisitos y disponer de una ruta de red para acceder posteriormente.
El vector CVSS divulgado refleja esas condiciones mediante “requisitos de ataque presentes” e “interacción activa del usuario”. Un administrador legítimo debe realizar una acción afectada, como establecer o utilizar la contraseña, antes de que un observador pasivo pueda obtener tráfico útil.
El atacante también necesita visibilidad de ese intercambio. Esa visibilidad podría derivarse de una intrusión previa en la red, acceso a una ruta de comunicaciones segmentada de forma inadecuada o monitorización desde otra posición dentro de la red operativa.
El investigador probó explícitamente una supuesta ruta de desbloqueo sin contraseña e informó de que no funcionó. Ese resultado limita la afirmación. CVE-2026-81861 afecta a la exposición de credenciales y su posterior uso no autorizado, no a una omisión universal de un solo paquete.
Sus pruebas públicas también abarcaron artefactos específicos de software y firmware. Identificó SCADAPack x70 Device DTM versión 2.0.18103.4 de RemoteConnect R3.5.5 y una imagen concreta de firmware 47x.
Un gestor de tipos de dispositivos, o DTM, es un componente de software que permite a una herramienta de ingeniería configurar y comunicarse con un dispositivo industrial concreto. En este caso, el DTM probado participa en el flujo de trabajo de Secure Lock.
La declaración de productos afectados de Schneider es más amplia que las pruebas directas del investigador. El proveedor enumera siete familias de productos y todas las versiones, incluidos los dispositivos SCADAPack 3xx y 32 más antiguos.
Ese alcance más amplio es autoritativo para la planificación de la remediación, pero la diferencia debería mantenerse visible. El investigador estableció el mecanismo en artefactos de prueba definidos, mientras que Schneider amplió el estado de afectación a toda su cartera de productos.
Por ello, los operadores deberían evitar dos errores opuestos. No deberían limitar la remediación a la compilación exacta probada, pero tampoco deberían afirmar que todos los dispositivos se demostraron de forma independiente bajo todas las configuraciones posibles.
La migración a RBAC sustituye la corrección de firmware inexistente
La respuesta principal de Schneider modifica la arquitectura de control de acceso en lugar de reparar Secure Lock en su lugar.
Para los dispositivos SCADAPack 47x y 470R compatibles, Schneider recomienda implementar control de acceso basado en roles, o RBAC. RBAC asigna permisos a roles y usuarios definidos, en lugar de depender de una contraseña compartida de bloqueo del dispositivo.
La empresa dirige a los administradores a su documentación de seguridad, incluidas las secciones que cubren la orientación para administradores y el funcionamiento de RBAC. Su guía de ciberseguridad más amplia describe la gestión de cuentas, la zonificación de red, los cortafuegos, las comunicaciones seguras y las prácticas de auditoría para despliegues SCADAPack.
Schneider caracteriza Secure Lock como una funcionalidad heredada conservada para mantener la compatibilidad con versiones anteriores. Recomienda RBAC como el mecanismo de control de acceso preferido para productos compatibles.
Esta orientación significa que la respuesta inmediata no es “instalar la versión X”. Schneider no ha identificado una versión de firmware corregida que conserve Secure Lock y elimine CVE-2026-81861.
Para los controladores más nuevos compatibles, la migración exige algo más que seleccionar una contraseña más robusta. Los administradores deben pasar de un flujo de bloqueo compartido a usuarios identificados, roles asignados y permisos gestionados.
Esta transición puede mejorar la rendición de cuentas. Una contraseña compartida informa a un operador de si alguien conocía el secreto, pero no identifica de forma fiable quién realizó una acción. Las cuentas y los roles identificados pueden restringir privilegios y reforzar la auditoría.
La migración también introduce trabajo. Los operadores deben definir roles administrativos, aprovisionar cuentas, probar el acceso desde herramientas de ingeniería, actualizar procedimientos y confirmar que el mantenimiento de emergencia siga siendo posible.
Las organizaciones que utilizan directorios centralizados podrían tener que validar las dependencias entre el entorno de RTU y la infraestructura de identidad. También deben considerar cómo se comportan los sitios remotos cuando los servicios de directorio o las conexiones de área amplia no están disponibles.
Los cambios en sistemas de control industrial requieren pruebas cuidadosas porque un error de autenticación puede bloquear el acceso autorizado de ingeniería. Una migración apresurada podría crear un problema operativo incluso mientras reduce el riesgo cibernético.
Por esa razón, los operadores deberían documentar las rutas de acceso actuales antes de modificarlas. El registro debería incluir estaciones de trabajo de ingeniería, conexiones de soporte remoto, cuentas de servicio, procedimientos de recuperación local y opciones de acceso físico.
Las familias SCADAPack 57x, 3xx y 32 más antiguas plantean un caso más complejo. Las recomendaciones de mitigación de Schneider hacen hincapié en la segmentación de red y el firewall de la RTU, ya que estos dispositivos no ofrecen la misma vía de migración a RBAC.
La segmentación de red separa los sistemas en zonas controladas y restringe la comunicación entre ellas. Un firewall de RTU aplica reglas que limitan qué hosts, protocolos o servicios pueden llegar al controlador.
Estos controles no corrigen el mecanismo de protección de credenciales. Reducen el número de sistemas capaces de observar un intercambio de Secure Lock o reutilizar credenciales expuestas.
Los operadores deben limitar el tráfico de gestión a estaciones de ingeniería aprobadas y rutas de administración de confianza. También deben eliminar la exposición directa a internet e impedir que los endpoints corporativos ordinarios lleguen a los servicios de gestión de la RTU.
Las recomendaciones de reducción de exposición de CISA aconsejan identificar activos industriales accesibles desde internet, eliminar exposiciones innecesarias, usar hosts de salto monitorizados y añadir autenticación multifactor cuando sea posible.
Un host de salto es un intermediario controlado que los administradores deben utilizar antes de acceder a dispositivos sensibles. Puede centralizar el registro, la autenticación y las restricciones de acceso en un punto donde los equipos de campo más antiguos carecen de esas capacidades.
Las redes privadas virtuales pueden proteger el tráfico que atraviesa infraestructura no confiable. Sin embargo, una VPN no debería crear acceso sin restricciones desde un portátil remoto a toda una red de control.
El enfoque más restringido es mejor. Los usuarios remotos deben autenticarse en un servicio de acceso monitorizado, llegar solo a los activos necesarios y recibir únicamente los permisos requeridos para una tarea definida.
La monitorización del tráfico también importa porque la exposición de credenciales depende de observar un intercambio. Los operadores deben investigar tráfico inesperado de DNP3 Virtual Terminal, actividad inusual de desbloqueo, accesos repetidos a la configuración o nuevas comunicaciones entre zonas de ingeniería y sitios remotos.
DNP3 es un protocolo ampliamente utilizado para la comunicación entre centros de control y dispositivos de campo. Su función Virtual Terminal proporciona un canal que las aplicaciones pueden utilizar para interacciones orientadas al dispositivo, incluidos los mensajes Secure Lock descritos por el investigador.
Cambiar únicamente una contraseña de Secure Lock no es una respuesta duradera. Si la contraseña de reemplazo vuelve a circular mediante el mismo mecanismo vulnerable, un observador capacitado puede recuperar el nuevo secreto a partir de otro intercambio capturado.
El objetivo práctico es dejar de depender del flujo de trabajo afectado. Cuando la migración no está disponible, los operadores deben dificultar sustancialmente la observación y reutilización mediante controles de red por capas.
Una puntuación media puede ocultar una remediación OT compleja
El impacto directo limitado de la vulnerabilidad no mide el esfuerzo necesario para proteger despliegues de campo de larga vida útil.
CVE-2026-81861 no tiene el perfil de una vulneración inmediata de un sistema de seguridad. Su vector base no asigna impacto directo sobre integridad ni disponibilidad, y no había evidencia pública de explotación activa en el momento de la divulgación.
Esas limitaciones importan. Los equipos de seguridad no deben describir el problema como manipulación demostrada de procesos, interrupción automática de plantas o ejecución de código no autenticada.
El impacto identificado es una pérdida de confidencialidad que involucra información de autenticación. Puede producirse acceso no autorizado a la RTU, pero la explotación sigue dependiendo de las condiciones de red y de la actividad administrativa.
Al mismo tiempo, una etiqueta de severidad media puede subestimar la complejidad operativa. Los productos Schneider Electric SCADAPack x70 están diseñados para la supervisión y el control remotos, a menudo en sitios con personal local limitado.
Una aplicación empresarial suele poder parchearse de forma centralizada. Los controladores de campo pueden requerir acceso programado, aprobación operativa, pruebas especializadas y coordinación con equipos responsables de procesos físicos.
La lista de afectados también abarca equipos actuales y heredados. Algunas unidades pueden adoptar RBAC. Otras deben depender de segmentación, filtrado y una arquitectura de acceso remoto seguro.
Esto divide el programa de remediación en diferentes líneas de trabajo. Un único ticket de vulnerabilidad no puede representar con precisión el trabajo de cada modelo y sitio.
La primera línea cubre los despliegues compatibles 47x y 470R. Los equipos deben confirmar el uso de Secure Lock, diseñar roles RBAC, probar los flujos de trabajo administrativos y retirar el modo heredado.
La segunda cubre los despliegues 57x, 3xx y 32. Los equipos deben validar las reglas de firewall, reducir los servicios accesibles, aislar las rutas de gestión y monitorizar el tráfico, porque el reemplazo preferido de control de acceso no está disponible.
Puede ser necesaria una tercera línea para dispositivos que no puedan cumplir el umbral de riesgo residual de la organización. Esas unidades pueden requerir planificación de reemplazo, especialmente cuando su posición en la red no puede restringirse de manera suficiente.
La calidad del inventario de activos resulta decisiva. Una organización no puede migrar ni aislar controladores que no ha identificado, y las etiquetas de producto en los registros de mantenimiento pueden no coincidir con la nomenclatura utilizada en el aviso.
Los equipos deben conciliar las bases de datos de ingeniería, las observaciones de red, los registros de compras y la documentación del sitio. Deben registrar el modelo exacto, el firmware, el modo de acceso configurado, la ruta de comunicaciones y el propietario responsable.
La configuración importa tanto como la versión. Dado que todas las versiones enumeradas están afectadas, un escáner basado únicamente en versiones puede producir un conjunto grande de resultados sin identificar qué sistemas usan realmente Secure Lock.
Eso no hace inútil el escaneo. Significa que la salida del escáner debe iniciar una investigación, no completarla.
La prueba de concepto pública también merece un tratamiento equilibrado. El investigador publicó un verificador depurado que demuestra la derivación de claves sin divulgar los secretos recuperados completos.
Esa cautela reduce el uso indebido inmediato, pero el detalle técnico público aún modifica el calendario defensivo. Otros investigadores o atacantes pueden examinar el método e intentar una reproducción independiente.
El estado de CISA de “sin explotación conocida” es una instantánea, no una predicción. Los defensores deben monitorizar cambios en el registro CVE, el catálogo de CISA, la notificación de Schneider y la inteligencia de amenazas sobre redes industriales.
La ausencia de un parche también cambia el significado del cierre. Una plataforma de gestión de vulnerabilidades puede seguir señalando todas las versiones afectadas incluso después de que un operador implemente RBAC o una segmentación efectiva.
Las organizaciones necesitan excepciones basadas en evidencia o registros de controles compensatorios. De otro modo, los paneles de seguridad pueden mostrar hallazgos sin resolver sin distinguir entre despliegues expuestos de Secure Lock y sistemas migrados.
Esos registros no deben convertirse en sustitutos permanentes de la remediación mediante papeleo. Cada excepción necesita un propietario de control definido, un método de validación, una fecha de revisión y un desencadenante de reemplazo.
El problema también ilustra por qué CVSS no puede ser el único método de priorización en tecnología operativa. CVSS mide la severidad intrínseca de la vulnerabilidad, mientras que los operadores deben añadir criticidad del proceso, exposición de red, capacidad de recuperación y posibles consecuencias físicas.
Una vulnerabilidad media en un controlador de pruebas aislado puede situarse por debajo de un fallo crítico en una aplicación empresarial. La misma vulnerabilidad en una RTU administrada remotamente con segmentación débil puede exigir una acción más rápida.
Por ello, los equipos de riesgo deben combinar la puntuación publicada con evidencia específica del sitio. Entre las preguntas útiles están si el tráfico de gestión atraviesa redes compartidas, si es plausible la captura de paquetes y si el dispositivo controla un proceso crítico.
También deben preguntarse si un atacante que recuperase la contraseña podría acceder a la interfaz normal de desbloqueo. La divulgación de credenciales solo tiene valor cuando esa credencial puede utilizarse.
Tres señales mostrarán si el riesgo está contenido
La siguiente fase depende de evidencia de migración, actualizaciones del proveedor y señales de que los atacantes pasan de la investigación al uso operativo.
La primera señal es la velocidad con la que los operadores identifican y retiran Secure Lock. Las organizaciones afectadas deberían poder informar cuántos dispositivos usan RBAC, cuántos dependen del bloqueo heredado y cuántas unidades antiguas se apoyan en controles compensatorios.
Una tasa creciente de migración a RBAC respaldaría la estrategia de mitigación de Schneider. La incertidumbre persistente sobre los modos de acceso desplegados debilitaría la confianza, incluso si no aparecen ataques públicamente.
La métrica operativa más útil no es simplemente el número de activos afectados. Es el porcentaje que cuenta con un estado de control de acceso verificado y una remediación probada.
Para los dispositivos compatibles con RBAC, la verificación debe confirmar que Secure Lock ya no es el límite de seguridad efectivo. También debe demostrar que los roles administrativos funcionan correctamente y que los procedimientos de emergencia siguen disponibles.
Para las unidades heredadas, la verificación debe probar las rutas de red permitidas. Una política de segmentación escrita tiene un valor limitado si una estación de trabajo ordinaria aún puede conectarse a los servicios de gestión de la RTU.
La segunda señal es si Schneider emite recomendaciones revisadas, detalles técnicos ampliados o una actualización de producto. La respuesta inicial se basa en mitigación arquitectónica, en lugar de una implementación corregida de Secure Lock.
Un cambio posterior de firmware o herramientas alteraría el panorama de remediación. Podría proporcionar una ayuda para la migración, eliminar el comportamiento vulnerable, mejorar el registro o restringir las configuraciones afectadas.
Por el contrario, la dependencia continuada de controles compensatorios confirmaría que los operadores deben tratar esto como un problema arquitectónico a largo plazo. Eso aumentaría la presión para reemplazar dispositivos heredados que no pueden admitir controles de acceso más sólidos.
Los equipos de seguridad deben monitorizar la notificación del proveedor en vez de depender solo de resúmenes copiados de avisos. Los avisos de producto pueden cambiar a medida que se amplían las pruebas o se precisan los pasos de mitigación.
La tercera señal es la evidencia de explotación o reproducción más amplia. En el momento de la divulgación, CISA informó de que no se conocía explotación, y CVE-2026-81861 no figuraba en el catálogo de Vulnerabilidades Explotadas Conocidas.
Esa situación cambiaría sustancialmente si los defensores encuentran actividad de recuperación de credenciales, intentos de desbloqueo no autorizados o herramientas que automaticen el análisis de tráfico. La inclusión en el catálogo aportaría otra señal sólida de escalamiento.
La reproducción pública por sí sola no demostraría ataques contra instalaciones operativas. Sin embargo, reduciría la incertidumbre técnica a la que se enfrenta un adversario y aumentaría el valor del tráfico Secure Lock capturado.
Los operadores deben preservar ahora los registros y la telemetría de red relevantes. Esperar un informe de explotación puede dejar a los investigadores sin los datos históricos necesarios para determinar si antes se observaron intercambios sensibles.
La monitorización debe centrarse en la actividad administrativa, no solo en las alarmas de proceso. El acceso a la configuración, los cambios de contraseña, las operaciones de desbloqueo, los nuevos hosts de ingeniería y las sesiones remotas inusuales pueden revelar un problema de control de acceso antes de que cambien las operaciones físicas.
Los productos Schneider Electric SCADAPack x70 siguen siendo plataformas de campo útiles, y el aviso no establece que los sitios desplegados hayan sido comprometidos. Sí establece que cada versión enumerada requiere una revisión a nivel de configuración.
La pregunta inmediata para los propietarios de activos es concreta: ¿puede la organización demostrar qué controladores aún utilizan Secure Lock, quién puede observar su tráfico de gestión y qué control se interpone ahora entre una contraseña expuesta y el acceso a la RTU?
Empiece por ese inventario y, después, migre los dispositivos compatibles a RBAC. Aísle los modelos que no pueden migrar, pruebe sus reglas de firewall y monitorice cada ruta de administración aprobada. La vulnerabilidad no puede gestionarse únicamente mediante comprobaciones de versión.
