CISA alerta de un fallo en AzeoTech DAQFactory que permite ejecutar código con archivos .ctl maliciosos

La buena noticia es que no se puede explotar remotamente. La mala es que eso no convierte el problema en menor, solo en más traicionero.

CISA publicó el 18 de junio de 2026 la alerta ICSA-26-169-02 sobre una vulnerabilidad en AzeoTech DAQFactory, producto utilizado en entornos industriales y de fabricación crítica. El fallo, identificado como CVE-2026-12390, afecta a las versiones 21.1 e inferiores y permite ejecución arbitraria de código mediante archivos .ctl especialmente manipulados. La debilidad está clasificada como CWE-843, Type Confusion, con una puntuación CVSS v3.1 de 7,8 y CVSS v4.0 de 8,4, ambas en severidad alta.

La alerta añade dos matices que importan mucho más de lo que parece. Primero, requiere interacción del usuario: alguien tiene que abrir o cargar el archivo preparado por el atacante. Segundo, no es explotable remotamente, al menos no de forma directa según CISA. Eso, sobre el papel, suena a vulnerabilidad seria pero contenida. En la práctica OT, donde los intercambios de archivos, las estaciones de ingeniería compartidas y la confianza implícita entre operadores siguen siendo moneda corriente, el riesgo no desaparece. Solo cambia de puerta de entrada.

Aquí está el quid: muchas organizaciones siguen midiendo el riesgo industrial con reflejos heredados del mundo IT. Si no hay RCE por red o exposición a internet, se relajan. Error clásico. Un archivo malicioso que un operador carga en una estación de trabajo con acceso a procesos industriales puede ser igual de útil para un atacante que una vulnerabilidad explotable por TCP/IP. A veces más, porque aprovecha la parte menos parcheada del sistema: la conducta humana y los flujos operativos cotidianos.

Qué ha dicho exactamente CISA y qué no ha dicho

La advisory de CISA es bastante sobria, incluso para sus estándares. Confirma que el problema reside en una confusión de tipos en DAQFactory y que puede explotarse mediante archivos.ctl especialmente diseñados para provocar code execution. También identifica el producto afectado, el sector crítico asociado —Critical Manufacturing— y precisa que no tiene constancia de explotación pública activa a fecha de publicación.

No hay, al menos en el texto público de la alerta, detalle técnico profundo sobre la ruta exacta de explotación, función afectada o condiciones internas de parsing que desencadenan la ejecución. Eso limita el análisis forense externo, pero no cambia la conclusión operativa: si tu planta usa DAQFactory 21.1 o anterior y acepta o intercambia archivos.ctl fuera de un circuito estrictamente controlado, tienes una superficie de ataque concreta que revisar ya.

Los créditos del hallazgo también dan pistas útiles. La vulnerabilidad fue reportada a CISA por Rocco Calvi (@TecR0c) de TecSecurity y por rgod de TrendAI Zero Day Initiative. Cuando aparece ZDI por medio, conviene no despachar el asunto como una rareza académica. ZDI no publica por deporte. Suele haber un análisis técnico serio detrás y, a menudo, interés real de investigación ofensiva o defensiva en la clase de fallo.

CISA recomienda cuatro mitigaciones específicas de producto:

• no usar documentos procedentes de fuentes desconocidas o no fiables;
• guardar los archivos.ctl en carpetas solo escribibles por usuarios con privilegios administrativos;
• operar en Safe Mode al cargar documentos que hayan salido del control de la organización;
• aplicar una contraseña de edición a los documentos.

Y luego añade la artillería habitual para ICS: minimizar exposición de red, segmentar, poner firewalls entre IT y OT, y usar acceso remoto seguro como VPN actualizadas. Todo correcto. Todo previsible. El valor real no está en esa lista genérica, sino en entender por qué un fallo local con interacción del usuario merece atención prioritaria en entornos industriales.

Por qué un fallo “no remoto” sigue siendo un problema serio en OT

El vector CVSS v3.1 publicado por CISA es AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Traducido: el ataque requiere acceso local, no necesita privilegios previos, exige interacción del usuario y puede comprometer confidencialidad, integridad y disponibilidad con impacto alto. No es un worm. Tampoco es inocuo.

En un entorno corporativo clásico, “acceso local” suele interpretarse como una barrera apreciable. En una planta industrial, esa lectura es demasiado optimista por al menos cuatro razones.

La primera es la circulación de archivos operativos. Los proyectos, configuraciones, recetas, pantallas HMI, lógicas de control o scripts auxiliares se transfieren entre proveedores, integradores, mantenimiento y operación con bastante más frecuencia de la que muchos CISOs imaginan. A veces por carpetas compartidas. A veces por USB. A veces por correo. A veces por ese portátil de ingeniería que lleva años siendo un pequeño Estado independiente.

La segunda es la confianza cultural. En OT, abrir un archivo enviado por un integrador conocido o por un compañero de mantenimiento puede no percibirse como un acto de riesgo, sino como trabajo rutinario. La seguridad documental no siempre forma parte del músculo operativo. Y ahí es donde las vulnerabilidades que dependen de interacción del usuario prosperan con una facilidad bastante antipática.

La tercera es la persistencia del software legado. Los activos industriales no siguen los ciclos de renovación de IT. Un sistema de supervisión o de adquisición de datos puede mantenerse años, incluso décadas, si la planta no puede asumir ventanas de parada amplias. Cuando una advisory afecta a versiones “21.1 e inferiores”, el rango real de exposición puede ser extenso, no anecdótico.

La cuarta es la proximidad funcional al proceso físico. Si DAQFactory se usa para adquisición de datos, supervisión, automatización o interfaces con control, la ejecución de código en esa estación no se queda necesariamente en el PC. Puede traducirse en alteración de datos, comandos erróneos, pérdida de visibilidad, sabotaje operacional o pivoting lateral hacia otros activos OT. La secuencia exacta dependerá de la arquitectura, claro, pero el riesgo no es teórico.

Por eso conviene desconfiar del consuelo fácil de “no es remoto”. Stuxnet tampoco necesitó internet para causar estragos. No es la misma clase de amenaza, ni de lejos, pero la lección permanece: en OT, el archivo es a menudo un vector tan operativo como la red.

Qué es DAQFactory y dónde duele si falla

DAQFactory es una plataforma de automatización, adquisición de datos y control empleada en escenarios industriales. No estamos hablando de una app de oficina que se cuelga y ya. Hablamos de software que puede estar integrado con sensores, PLC, HMIs, historizadores, alarmas o scripts de operación. Eso significa que la estación donde corre el software puede tener visibilidad privilegiada sobre el proceso físico y, en algunos despliegues, capacidad de influir en él.

CISA encuadra el producto dentro del sector de Critical Manufacturing, una de las 16 infraestructuras críticas reconocidas en Estados Unidos. Ese detalle no está de adorno. Indica el tipo de impacto que preocupa al regulador: interrupciones de producción, degradación de seguridad operativa, errores de proceso o uso del sistema comprometido como punto de apoyo para moverse dentro de una red industrial.

Si el archivo.ctl forma parte del flujo normal de trabajo —y todo apunta a que sí, dado que la mitigación oficial gira alrededor de controlar su origen, ubicación y carga en Safe Mode— entonces el riesgo no se limita a un componente accesorio. Toca un elemento central de la interacción entre usuario y aplicación.

También hay una implicación incómoda para equipos de compliance y auditoría interna: muchos programas de gestión de vulnerabilidades en OT siguen priorizando exclusivamente activos expuestos por red o componentes con exploits remotos conocidos. Ese enfoque deja huecos. Un software industrial vulnerable a archivos maliciosos puede escapar del radar durante semanas porque no “salta” en un escáner de perímetro. Y sin embargo puede ser el camino más realista para comprometer una estación de ingeniería.

La diferencia entre CVSS 7,8 y el riesgo real de planta

La puntuación CVSS v3.1 de 7,8 y la CVSS v4.0 de 8,4 colocan el fallo en severidad alta. Bien. Útil para priorizar. Insuficiente para decidir.

CVSS mide características técnicas estandarizadas del fallo; no conoce tu proceso industrial, tus compensating controls ni el coste de una parada no planificada. Dos plantas con el mismo software vulnerable pueden tener riesgos operativos muy distintos. En una, abrir un archivo malicioso en DAQFactory puede suponer una pérdida de visibilidad temporal en una estación de supervisión aislada. En otra, puede afectar a recetas, alarmas, valores operativos o integraciones que sostienen producción continua.

Además, la métrica incluye UI:R, interacción del usuario requerida. En muchas organizaciones eso empuja la prioridad a la baja de forma automática. Mala costumbre. Si el flujo de negocio hace probable esa interacción, el riesgo efectivo sube. Un ejemplo simple: si operadores o ingenieros cargan con frecuencia archivos.ctl procedentes de terceros, mantenimiento o repositorios compartidos, la probabilidad de explotación práctica puede ser bastante mayor de lo que sugiere una lectura mecánica del vector.

En otras palabras, el CVSS es el mapa. La planta es el terreno. Y ya se sabe quién gana cuando se contradicen.

Las mitigaciones de CISA son correctas, pero se quedan cortas si tu proceso documental es un coladero

Decir a los usuarios que no abran documentos no fiables es el equivalente OT de recomendar dieta y ejercicio. Nadie puede discutirlo; casi nadie puede vivir solo de eso.

Las recomendaciones publicadas por CISA tienen sentido inmediato, pero exigen traducirse a controles operativos concretos. Si no, se convierten en cartelería moral. Veamos dónde está la sustancia.

1. Bloquear escritura indiscriminada sobre repositorios de.ctl

CISA sugiere almacenar archivos.ctl en carpetas solo escribibles por administradores. Eso apunta a un control de integridad básico pero potente: reducir la posibilidad de que cualquier usuario, malware oportunista o cuenta comprometida de bajo privilegio pueda sustituir o insertar archivos en el repositorio operativo.

La implementación seria no consiste solo en cambiar ACLs. Requiere identificar dónde se almacenan los.ctl que realmente se usan en producción, quién los modifica, cómo se versionan y cómo se promueve un archivo a estado “autorizado”. Si esa pregunta genera silencio incómodo, ya sabes dónde está el problema.

2. Usar Safe Mode de verdad, no como opción decorativa

La advisory recomienda Safe Mode al cargar documentos que hayan estado fuera del control de la organización. Eso sugiere que la aplicación dispone de un modo de apertura con restricciones de ejecución o de manejo de contenido activo. Si existe, conviene convertirlo en procedimiento por defecto para cualquier archivo recibido de terceros o recuperado de soportes externos.

La dificultad práctica es la de siempre: si Safe Mode interfiere con la operativa o añade pasos, alguien querrá saltárselo. La única forma de que funcione es anclarlo en el proceso, no en la buena voluntad del usuario. Instrucción formal, formación específica y supervisión. Menos póster y más disciplina.

3. Contraseña de edición no equivale a seguridad completa

Aplicar contraseña de edición a documentos puede ayudar a evitar cambios casuales o no autorizados, pero no debe interpretarse como control de seguridad suficiente frente a archivos maliciosos. La medida puede proteger la integridad en ciertos flujos documentales; no elimina la vulnerabilidad subyacente del parser si el archivo llega ya manipulado.

Sirve como medida complementaria. No como bala de plata. Las balas de plata en ICS suelen acabar siendo de fogueo.

4. Prohibir “documentos no fiables” exige definir qué demonios es fiable

El consejo de no abrir archivos de origen desconocido solo sirve si la organización define una cadena de confianza documental. Eso incluye, como mínimo, cuatro elementos: origen autorizado, canal autorizado, validación previa y aprobación de carga. Si integradores, proveedores y mantenimiento externo siguen enviando archivos por correo sin firma, sin hash y sin repositorio intermedio, la política de confianza es papel mojado.

Una práctica razonable es exigir que cualquier.ctl externo pase por un repositorio de staging, con validación antimalware, comprobación de hash, revisión de cambios y promoción controlada a producción. No hace falta convertir la planta en una misión lunar. Hace falta dejar de actuar como si los archivos industriales fueran folletos PDF.

Lo que deberían hacer ahora los equipos OT, IT y compliance

La respuesta útil no es “parchear cuanto antes” y desaparecer con gesto solemne. Primero porque la advisory pública no detalla, al menos en el extracto disponible, una versión corregida concreta. Segundo porque en OT el parcheo depende de validaciones operativas, ventanas de cambio y pruebas de compatibilidad. Tercero porque, aunque haya fix, seguirás necesitando controles alrededor del archivo.

Si tu organización usa DAQFactory 21.1 o versiones anteriores, hay cinco preguntas que deberías responder esta semana.

Una: ¿dónde está desplegado exactamente? No en el inventario teórico, sino en estaciones reales, servidores de supervisión, laboratorios, entornos de prueba y máquinas de integradores conectadas a la red OT. Si no sabes cuántas instancias tienes, no tienes una exposición definida.

Dos: ¿quién carga archivos.ctl y desde qué fuentes? Identifica usuarios, equipos, carpetas compartidas, dispositivos USB, repositorios de proyectos y terceros que participan en ese flujo. El ataque necesita interacción del usuario. Averigua quién es ese usuario y qué hábitos tiene.

Tres: ¿existe separación entre repositorios de edición, validación y producción? Si todo vive en la misma carpeta accesible por medio equipo, el problema no es solo la CVE. Es el proceso.

Cuatro: ¿puedes activar o imponer Safe Mode en la apertura de archivos externos? Si la respuesta es sí, conviértelo en procedimiento controlado. Si la respuesta es no, documenta la limitación y refuerza controles compensatorios.

Cinco: ¿qué impacto tendría la ejecución de código en esa estación? No basta con decir “alto”. Hay que mapear privilegios, conectividad, acceso a PLC, credenciales almacenadas, capacidad de pivoting y dependencia del proceso. Eso determina la prioridad real.

Desde el punto de vista organizativo, este tipo de vulnerabilidad obliga a coordinar tres mundos que a menudo se soportan con paciencia diplomática más que con verdadero gobierno común: operación, seguridad y compliance. OT conoce el flujo real de archivos. IT puede endurecer estaciones, permisos y segmentación. Compliance y riesgo deben garantizar que la excepción operativa no se convierta en agujero permanente sin trazabilidad.

Qué controles compensatorios tienen más sentido mientras llega el parche o la validación de cambio

No todas las plantas podrán actualizar de inmediato, y algunas ni siquiera sabrán aún si el proveedor ha publicado corrección o mitigación adicional fuera de la advisory. Mientras tanto, hay una serie de controles compensatorios razonables que sí reducen exposición sin forzar una parada precipitada.

Primero, aislar las estaciones con DAQFactory de canales innecesarios de intercambio. Si una máquina no necesita correo, navegación web o acceso abierto a shares corporativos, córtalo. Parece obvio. También lo parecía hace diez años y aquí seguimos.

Segundo, aplicar whitelisting o allowlisting de aplicaciones en estaciones críticas si el entorno lo soporta. La ejecución arbitraria de código hace bastante menos gracia al atacante si el sistema solo permite binarios y scripts aprobados.

Tercero, restringir USB y medios extraíbles con controles técnicos y procedimiento. Muchas intrusiones OT siguen entrando por vías mucho menos glamourosas que un exploit remoto.

Cuarto, monitorizar creación, modificación y apertura de archivos.ctl en rutas sensibles. No resolverá el fallo, pero puede aportar visibilidad sobre comportamientos anómalos, especialmente si se combina con alertas de cambios fuera de ventanas autorizadas.

Quinto, revisar privilegios locales de usuarios que operan DAQFactory. El vector CVSS indica PR:N, sin privilegios previos, pero eso no significa que todos los contextos de ejecución sean iguales. Si el usuario o el proceso opera con privilegios excesivos, el impacto práctico sube.

Sexto, validar copias de seguridad y capacidad de restauración de configuraciones y proyectos. En OT esto no es burocracia. Si un archivo malicioso corrompe el entorno o fuerza recuperación, la diferencia entre restaurar en horas o improvisar durante una parada puede costar mucho dinero.

Séptimo, introducir revisión dual para archivos.ctl procedentes de terceros antes de su uso en producción. Dos pares de ojos no arreglan una Type Confusion, pero sí reducen la probabilidad de que un archivo entre en el sistema por rutina o prisa.

El ángulo regulatorio: no es DORA, pero sí es gobernanza de terceros, gestión de vulnerabilidades y trazabilidad

La noticia no tiene una derivada financiera directa, y no conviene forzarla. Aun así, el caso encaja de lleno en varias obligaciones regulatorias y de control que trascienden el sector industrial puro.

En la Unión Europea, NIS2 exige a las entidades esenciales e importantes adoptar medidas técnicas, operativas y organizativas adecuadas para gestionar riesgos de seguridad de redes y sistemas de información. El punto clave aquí está en artículo 21, que incluye, entre otras, políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y prácticas de higiene cibernética. Un flujo documental OT que permite cargar archivos de terceros sin control serio es justo el tipo de debilidad de cadena operativa que NIS2 pretende cerrar, aunque la directiva no cite DAQFactory, claro.

Para organizaciones sujetas a marcos de control internos o a auditorías sectoriales, esta CVE también toca una cuestión incómoda: ¿está inventariado y gobernado el software industrial auxiliar? Muchas veces los programas de adquisición de datos, ingeniería o scripting quedan en tierra de nadie. No son ERP, no son endpoint de usuario clásico, no son PLC. Y así acaban con menos foco del que merecen. Mala idea.

Si la explotación de un archivo.ctl deriva en compromiso de sistemas con datos personales, podrían entrar además obligaciones de notificación bajo GDPR art. 33 si se produce una violación de seguridad de datos personales con riesgo para derechos y libertades. No es el supuesto central de la advisory, pero en plantas con datos de empleados, accesos, mantenimiento identificado o registros integrados no es imposible.

Desde la óptica de gobernanza de terceros, el asunto también conecta con la necesidad de controlar entregables de integradores y proveedores. Si un contratista externo entrega proyectos o configuraciones que acaban cargándose en sistemas industriales, el contrato y el procedimiento deberían exigir canales autorizados, integridad verificable y validación previa. De lo contrario, la cadena de suministro OT funciona por fe. Y la fe es una estrategia regulatoria bastante mala.

La paradoja OT de siempre: el archivo parece pequeño hasta que toca el proceso

Hay una razón por la que este tipo de alertas merecen más atención de la que a veces reciben. No porque el CVE sea “crítico” en sentido espectacular, sino porque expone un patrón estructural.

En seguridad industrial, muchas defensas están pensadas para perímetro, red y acceso remoto. Tiene lógica: segmentación, firewalls, jump servers, VPN, IDS de red. Todo eso importa. Pero el vector archivo sigue entrando por la puerta lateral, casi con modales. Un ingeniero recibe una actualización de proyecto. Un proveedor envía una plantilla. Un técnico reutiliza una configuración desde un repositorio antiguo. Un USB cambia de manos. Nadie está “atacando por internet”. Y sin embargo el riesgo materializa igual.

La advisory de CISA, publicada el 18 de junio de 2026, lo deja bastante claro entre líneas: el problema no es solo la vulnerabilidad técnica, sino la facilidad con la que se puede encadenar con flujos de trabajo normales. De ahí que las mitigaciones se centren tanto en origen de documentos, permisos de carpetas y modo seguro de carga. Cuando un regulador técnico te habla del documento y no de la red, conviene escuchar.

Hay otra paradoja interesante. CISA remarca que no conoce explotación pública específica de esta vulnerabilidad. Eso puede llevar a algunas organizaciones a posponer la respuesta. Error comprensible, pero error. En OT, esperar a la explotación pública para actuar sobre una RCE de severidad alta es una estrategia de aprendizaje por sufrimiento. Funciona, pero sale cara.

Qué deberían pedir los responsables de planta al proveedor y a sus integradores

No basta con reenviar la advisory y pedir “revisar impacto”. Eso solo produce cadenas de correo y pocas certezas. Si eres responsable de una planta, de ingeniería industrial o de ciberseguridad OT, hay preguntas concretas que merece la pena elevar a AzeoTech y a cualquier integrador que mantenga DAQFactory.

La primera: ¿existe versión corregida, hotfix o workaround validado por el fabricante? La advisory citada no detalla en el extracto público la versión remediada. Necesitas una respuesta formal del proveedor, con condiciones de despliegue y dependencias.

La segunda: ¿qué hace exactamente Safe Mode y qué limitaciones funcionales introduce? Sin esa información, será difícil convertir la recomendación en procedimiento aceptado por operación.

La tercera: ¿hay indicadores de compromiso, logs o artefactos útiles para detectar intentos de explotación? Aunque no se conozca explotación activa, disponer de patrones o telemetría potencial ayuda a investigación interna.

La cuarta: ¿qué flujos documentales utilizan los integradores para entregar.ctl y cómo garantizan integridad y autenticidad? Si la respuesta es “correo y ZIP”, ya tienes trabajo.

La quinta: ¿puede limitarse técnicamente la apertura de.ctl a rutas aprobadas o imponer Safe Mode para fuentes externas? Si el producto no lo soporta, habrá que compensar con controles del sistema operativo o del proceso.

Estas preguntas no son capricho burocrático. Son la diferencia entre una reacción madura y el deporte corporativo de fingir control mientras nadie quiere tocar producción.

La lección de fondo: si tu seguridad OT no gobierna archivos, gobierna solo media planta

La alerta sobre AzeoTech DAQFactory no va a ocupar portadas generalistas. No hay ransomware con nombre pegadizo ni apagón masivo. Pero sí hay algo más útil: un recordatorio bastante incómodo de dónde siguen estando los puntos ciegos en OT.

Un archivo .ctl especialmente manipulado puede desencadenar ejecución arbitraria de código en DAQFactory 21.1 y anteriores. Lo ha publicado CISA bajo la referencia ICSA-26-169-02 el 18 de junio de 2026. No se explota remotamente. Requiere interacción del usuario. No hay explotación pública conocida reportada a CISA. Todo eso es cierto. Y aun así, sigue siendo una vulnerabilidad que puede encajar de forma muy natural en los hábitos operativos de una planta real.

La pregunta útil no es si el CVSS te parece alarmante. La pregunta útil es esta: tu organización controla de verdad qué archivos entran en sus sistemas industriales, quién los carga, desde dónde y con qué validación previa?

Si la respuesta es dudosa, el problema no se llama solo CVE-2026-12390. Se llama gobernanza OT insuficiente. Y esa, por desgracia, sí que es una vulnerabilidad de largo recorrido.