La versión corta
El 6 de agosto de 2026, CISA publicó ICSA-26-218-01 sobre ABB Ability Zenon, la plataforma SCADA, HMI e IIoT usada en energía, agua, fabricación y alimentación y bebidas. El aviso enumera 13 vulnerabilidades, con CVSS v3 de hasta 7.8, y describe el impacto como saltarse la seguridad, provocar caídas del sistema, ejecutar acciones no autorizadas o comprometer datos.
Lo que llama la atención es dónde viven esos fallos. Ninguno está en la lógica de control de Zenon. Los 13 residen en una base de datos MongoDB 4.2 que los servicios IIoT de ABB integran dentro de la plataforma. El más reciente, CVE-2025-14847, permite a un cliente sin autenticar leer memoria sin inicializar mediante una cabecera comprimida malformada. El resto son problemas de MongoDB Server de 2020 y 2021, desde saltos de autorización hasta denegación de servicio.
Esa distinción importa para cómo respondes. No puedes actualizar una base de datos que ABB entrega dentro de su producto. Avanza al ritmo de publicación de ABB, que en un sistema validado y crítico para el tiempo de actividad puede ser lento. Así que la respuesta útil no es esperar, es cambiar lo que puede alcanzar la cosa.
Qué dice el aviso
Directo del aviso y de los registros de CVE:
- Producto: ABB Ability Zenon. El componente afectado son los servicios IIoT de ABB con MongoDB 4.2, listado en todas las versiones de esa configuración.
- Los fallos: 13 CVE. Uno es nuevo, CVE-2025-14847, una lectura de heap sin autenticar. El resto son CVE de MongoDB Server de 2020 y 2021, incluidos CVE-2020-7921 (un fallo del subsistema de autorización que permite saltar una lista de IP permitidas), CVE-2020-7925 (un fallo del analizador que puede alcanzar un atacante sin autenticar), y una serie de errores de denegación de servicio y de acceso a memoria (CVE-2020-7928, 7929, 7923, 7924 y CVE-2021-20330, 32036, 32040, 20333, 20328, 20334).
- Severidad: CVSS v3 de hasta 7.8.
- Qué permite, según CISA: saltarse la seguridad, provocar caídas del sistema, ejecutar acciones no autorizadas o comprometer datos.
- Cómo se alcanza: los errores expuestos en red necesitan un atacante que pueda abrir una conexión a la base de datos. Algunos no necesitan ninguna cuenta.
- Remediación: ABB tiene orientación en el aviso. CISA añade su línea habitual para ICS: mantén el sistema fuera de la internet pública, aíslalo de la red corporativa, y enruta el acceso remoto por una vía controlada.
CISA no reportó a nadie explotando esto en la práctica. Léelo como una exposición que cerrar, no como un incendio que apagar.
Por qué esto sigue pasando
Mira más allá del nombre de ABB y esto es una historia sobre de qué está hecha cada plataforma de OT. Ninguno de estos productos es un solo binario. Los fabricantes integran bases de datos, historiadores, servidores web, brokers de mensajes y entornos de ejecución para entregar funciones más rápido, y cada uno de ellos arrastra sus propias vulnerabilidades hasta tu planta.
El problema es el calendario. No puedes sustituir el MongoDB integrado sin arriesgar el soporte y una revalidación de la plataforma que depende de él. El arreglo real llega cuando ABB reconstruye y vuelve a entregar, y en OT eso puede tardar frente a un sistema certificado que nadie quiere reiniciar. Mientras tanto, el componente sigue haciendo su trabajo, respondiendo en un puerto, en una red, exactamente como se diseñó.
Una base de datos de la era 4.2 que arrastra CVE de hace cinco años dentro de una plataforma de 2026 no es dejadez. Es la brecha normal entre cuándo una dependencia publica un arreglo y cuándo un fabricante puede incorporarlo con seguridad a un producto industrial. La exposición está incrustada en cómo se ensambla el software de OT, así que parchear por sí solo siempre irá un paso por detrás.
Qué es lo que de verdad se explota
Bajo la lista de CVE, el riesgo está claro. Un atacante alcanza una base de datos que nunca debería haber sido alcanzable, y le habla. Para los fallos sin autenticar, ese es todo el ataque. Sin malware, sin cadena de día cero, sin cuenta robada. Alcance en red y una petición manipulada.
Por eso el consejo de CISA en este aviso es el mismo que imprime en casi todos: no expongas el sistema, aíslalo, y pon el acceso remoto detrás de una vía controlada. Los errores son de ABB para arreglarlos. La accesibilidad es tuya.
La pregunta que vale la pena hacerse en tu propia red no es si MongoDB está parcheado. Es qué puede abrir ahora mismo una conexión a los servicios IIoT, y si lo verías si algo lo hiciera. En una red de planta plana la respuesta suele ser todo lo que hay en la subred, y no.
El control que de verdad lo acota
Cierras esto sin el parche haciendo que el componente solo sea alcanzable a través de un punto de control.
Un proxy industrial se sitúa en la vía de acceso a los servicios IIoT de ABB Ability Zenon y media en cada sesión que llega a ellos. En la práctica:
- La base de datos deja de responder a clientes arbitrarios de la subred. La única vía hacia ella es una sesión que el proxy ya ha autenticado, lo que significa que los fallos sin autenticar pierden lo que más necesitan, un llamante sin autenticar.
- Cada sesión queda ligada a una persona o servicio con nombre, acotada a lo que requiere el trabajo, con MFA gestionado en el proxy. Nada de la pila de ABB se modifica, así que nada tiene que parchearse, revalidarse ni reiniciarse para que esto se sostenga.
- Cada sesión que toca los servicios IIoT queda registrada, así que "¿nos daríamos cuenta?" por fin tiene respuesta.
- No instala nada en la plataforma. Es un conducto IEC 62443 entre la zona de control y todo lo que hay por encima, que es la idea de la DMZ industrial reducida a un único componente integrado.
Esto no sustituye al parcheo. Aplica la remediación de ABB cuando tu proceso de cambios lo permita. Lo que te da es tiempo que el parcheo no puede: la exposición queda cerrada ahora, sigue cerrada durante el próximo CVE de componente integrado del que aún no has leído, y nada de ello toca un sistema certificado que no puedes permitirte perturbar. La mecánica está en qué es un proxy industrial, y la parte de auditoría está en microsegmentación de OT con integración SIEM.
El aviso de Johnson Controls, en breve
CISA envió un segundo aviso el mismo día, ICSA-26-218-02, sobre el comunicador de alarmas en red Johnson Controls TL280 en fabricación crítica. El fallo son credenciales embebidas en el firmware (CVE-2026-27871, CVSS v3 4.1), y Johnson Controls lo corrige con una actualización de firmware.
Menos en juego, otra caja, la misma forma de siempre. No puedes des-embeber una credencial en el firmware de otro. Lo que sí puedes hacer es asegurarte de que el dispositivo solo responda en una vía que autentique y registre a quien se conecte, para que una credencial estática filtrada no equivalga a una puerta abierta. Dos avisos, un día, la misma jugada de fondo.
Por dónde empezar esta semana
- Localiza ABB Ability Zenon y sus servicios IIoT en tu entorno, y anota qué segmentos pueden abrir ahora mismo una conexión hacia ellos.
- Confirma que la base de datos no es alcanzable desde la red corporativa ni desde internet. Si lo es, cierra eso primero.
- Aplica la remediación de ABB con tu proceso de cambios habitual y haz seguimiento, pero no dejes que la fecha del parche sea lo único que separa a un cliente sin autenticar del componente.
- Mueve los servicios IIoT detrás de un punto de control para que el acceso quede ligado a la identidad, con mínimo privilegio y registrado.
- Haz la misma comprobación con las otras piezas integradas de tu pila SCADA y HMI. El próximo aviso nombrará una base de datos o un entorno de ejecución distinto, y la respuesta no cambiará.
ICSA-26-218-01 es un buen empujón para arreglar algo más amplio que un solo componente. En OT rara vez puedes parchear el fallo en tu calendario, así que pones tú las condiciones sobre lo que puede alcanzarlo.