TroutTrout
Back to Blog
OT SecurityICS AdvisoriesSCADARemote Access

El SCADA que no puedes parchear el martes: AVEVA Enterprise SCADA (ICSA-26-225-01)

Trout Team6 min read

La versión corta

El 13 de agosto de 2026, CISA publicó ICSA-26-225-01 para AVEVA Enterprise SCADA y Enterprise SCADA HMI, el software de supervisión que controla procesos industriales en Critical Manufacturing. La vulnerabilidad, CVE-2025-7639, es un problema de deserialización de datos no confiables: una carga serializada manipulada enviada al software puede alterarse y desencadenar ejecución de código durante la deserialización. Puntuación base CVSS v3 de 7,1, alta complejidad de ataque y sin explotación pública conocida.

La condición previa es la habitual en OT. Un atacante debe poder alcanzar el servicio SCADA o HMI para enviarle esa carga. Ese alcance es la parte que usted controla.

Lo que dice el aviso

Directamente del aviso y del registro CVE:

  • Productos: AVEVA Enterprise SCADA y Enterprise SCADA HMI.
  • La falla: CVE-2025-7639, deserialización de datos no confiables que conduce a ejecución de código durante la deserialización.
  • Versiones afectadas: Enterprise SCADA 2025 y anteriores hasta los niveles de service pack indicados (2024 hasta 2024 SP1 P01, 2023 hasta 2023 SP1, 2022 hasta 2022 SP2 P2, 2021 hasta SP2 P5), más Enterprise SCADA HMI 2024 y 2023 y anteriores.
  • Severidad: CVSS v3 7,1, alta complejidad de ataque.
  • Cómo se alcanza: un atacante que puede entregar un objeto serializado manipulado al servicio. La ejecución de código es el resultado.
  • Remediación: AVEVA ha publicado correcciones en el boletín de seguridad AVEVA-2026-005. CISA añade su orientación habitual para ICS: mantener el sistema fuera de internet público, aislarlo de la red corporativa y enrutar el acceso remoto a través de una ruta controlada.

CISA no reportó explotación activa. Trátelo como una exposición que cerrar en sus propios términos, no como un incendio que apagar.

Por qué esto sigue ocurriendo

SCADA y su HMI son aplicaciones alojadas en Windows con bases de datos y servicios de red, y supervisan un proceso físico que no puede simplemente detenerse. Esa es toda la tensión de la seguridad OT en una sola frase. El software presenta las mismas clases de fallas que cualquier aplicación empresarial, la deserialización entre ellas, pero no se puede parchear un martes. Una corrección espera una ventana de mantenimiento validada que puede estar a semanas o a una temporada de distancia, si el proveedor la certifica para su versión. Mientras tanto, el proceso sigue ejecutándose y el servicio vulnerable sigue escuchando.

Esa brecha entre "existe una corrección" y "podemos aplicarla de forma segura" es donde vive realmente el riesgo OT. No es un fallo del equipo de planta. Es la naturaleza de ejecutar software que controla maquinaria que no se puede reiniciar a demanda.

Qué se explota realmente

Reduzca el CVE a su mecánica. Un atacante que puede abrir una conexión al servicio SCADA o HMI le envía un objeto serializado manipulado y, durante la deserialización, ese objeto se convierte en código que se ejecuta en el host que supervisa el proceso. La alta complejidad de ataque eleva el listón para la carga, pero el primer ingrediente que necesita el atacante es simple: alcance de red al servicio. En un segmento OT plano, la mayor parte de la planta lo tiene.

Por tanto, la pregunta que vale la pena hacerse en su propia red no es solo si AVEVA está parcheado. Es qué puede abrir actualmente una conexión a los servidores SCADA y HMI, y si usted lo notaría si algo lo hiciera. En una red de control plana, las respuestas honestas suelen ser "casi todo" y "no".

El control que realmente lo acota

Usted cierra esto sin esperar la ventana de mantenimiento haciendo que SCADA y HMI solo sean accesibles a través de un punto de aplicación.

El Access Gate se sitúa en la ruta de acceso a esos servidores y gestiona cada sesión que los alcanza. En la práctica:

  • Los servidores dejan de responder a clientes arbitrarios en la subred. La única vía hacia ellos es una sesión que el gate ya ha autenticado, por lo que una falla de deserialización pierde lo que más necesita: un llamante no autenticado en el cable.
  • Cada sesión está vinculada a una persona o servicio con nombre, acotada a la tarea, con MFA gestionado en el gate y registrada. No se modifica nada en la pila de AVEVA, por lo que nada debe revalidarse ni reiniciarse para que esto se mantenga.
  • Dado que el Access Gate es cómputo en el cable, un punto de aplicación sin agente colocado frente al activo en lugar de un servicio en la nube, aplica identidad y mínimo privilegio junto al servidor SCADA sin instalar nada en él.

Esto no reemplaza la actualización. Aplique las correcciones de AVEVA cuando su proceso de cambios lo permita. Lo que el punto de aplicación le compra es tiempo que el parche no puede: la exposición se cierra ahora, permanece cerrada ante el próximo aviso de SCADA que aún no ha leído, y nada de esto depende de una ventana de mantenimiento. La mecánica está en qué es un proxy industrial, el lado de la segmentación está en seguridad de red OT, y el lado del acceso está en acceso remoto seguro OT y de proveedores para los integradores que mantienen estos sistemas.

Por dónde empezar esta semana

  1. Localice cada instancia de Enterprise SCADA y SCADA HMI, y anote qué segmentos pueden abrir actualmente una conexión hacia ellas.
  2. Confirme que los servidores no son accesibles desde la red corporativa ni desde internet. Si lo son, cierre eso primero.
  3. Aplique las correcciones de AVEVA en su proceso de cambios habitual y haga seguimiento, pero no permita que la fecha del parche sea lo único que se interponga entre un cliente con acceso de red y la ejecución de código.
  4. Coloque los servidores SCADA y HMI detrás de un punto de aplicación para que el acceso esté vinculado a identidad, con mínimo privilegio y registrado, incluido el de los integradores que los mantienen.
  5. Ejecute la misma verificación en el resto de la pila OT. El próximo aviso nombrará un producto diferente, y la respuesta no cambiará.

ICSA-26-225-01 es un buen motivo para corregir algo más amplio que un solo servidor. El software que ejecuta el proceso sigue siendo solo un servidor en su red, y en OT rara vez se puede parchear la falla en sus propios plazos. Por eso se establecen las condiciones sobre qué puede alcanzarlo.

FAQ

Frequently Asked Questions

What is CISA advisory ICSA-26-225-01?
It is an ICS advisory CISA published on 13 August 2026 for AVEVA Enterprise SCADA and Enterprise SCADA HMI, the supervisory software behind industrial processes in Critical Manufacturing. It covers CVE-2025-7639, a deserialization of untrusted data flaw that can lead to code execution, with a CVSS v3 base score of 7.1 and high attack complexity.
Is the AVEVA Enterprise SCADA vulnerability exploitable remotely?
CVE-2025-7639 is a deserialization of untrusted data issue: an attacker who can send a crafted serialized payload to the software can tamper with it and trigger code execution during deserialization. CISA rates the attack complexity high and reports no known public exploitation. The common precondition is the ability to reach the SCADA or HMI service on the network.
Which products and versions are affected?
Per the advisory: AVEVA Enterprise SCADA 2025 and earlier through the listed service-pack levels (2024 up to 2024 SP1 P01, 2023 up to 2023 SP1, 2022 up to 2022 SP2 P2, and 2021 up to SP2 P5), plus Enterprise SCADA HMI 2024 and 2023 and earlier. AVEVA has published fixes in security bulletin AVEVA-2026-005. Check your own build against the advisory before you act.
How do I protect AVEVA SCADA if I cannot upgrade right away?
Put a compensating control in front of the SCADA and HMI servers instead of waiting on your maintenance window. An agentless industrial proxy takes them off the open network, requires an identity-bound session for anything that connects, and records every one. The AVEVA stack does not change, so nothing has to be re-validated or rebooted, and an unauthenticated client on the subnet no longer has a service to reach. Apply the vendor fix on your normal process in parallel.
Why does a SCADA server need an access control point in front of it?
Because it is a network-facing server that happens to supervise a physical process, and you rarely get to patch it on your own timeline. If any host on the segment can open a connection to it, a deserialization-to-code-execution flaw only needs network reach to matter. Controlling who can reach the SCADA and HMI service is what turns a serious CVE into an exposure you have already bounded.