El 19 de octubre de 2026, Siemens confirmó que alguien está explotando de verdad un fallo de su Software Center. El detalle que nos hizo parar no es el fallo. Es que el ejecutable que se lanzó en las máquinas de las víctimas era una copia auténtica del programa de Siemens, con su firma digital correcta e intacta. El atacante no falsificó nada ni entró en los sistemas de Siemens: dejó un fichero llamado archive.dll en la misma carpeta. Y el programa, al arrancar, lo cargó.
Los hechos, con fechas
El fallo es CVE-2026-110936, publicado el 15 de octubre de 2026 con una puntuación CVSS v4 de 8,4 y clasificado como CWE-427, «elemento de ruta de búsqueda no controlado». En román paladino: el programa no restringe bien en qué carpetas busca los DLL que necesita. El 17 de octubre Siemens actualizó su aviso para indicar que la versión V4.0.9.8 lo corrige, y que todas las anteriores están afectadas. El 19 de octubre confirmó explotación real. El 20 de octubre, CISA lo metió en su catálogo de vulnerabilidades explotadas conocidas, con fecha límite para la administración federal estadounidense el 3 de noviembre.
Siemens fue explícita: «Que sepamos, no se ha vulnerado ningún sistema, producto ni canal de actualización de Siemens». Los atacantes consiguieron una copia legítima y firmada del programa y la distribuyeron, junto con sus ficheros maliciosos, fuera de los canales oficiales. Esto no es una cadena de suministro comprometida. Es algo más incómodo: un binario perfectamente legítimo convertido en vehículo sin tocarlo.
Qué contesta una firma digital
Una firma de código responde a dos preguntas, y las responde bien: quién construyó este fichero y si ha cambiado desde entonces. En este caso las dos respuestas fueron correctas. El ejecutable era de Siemens y estaba íntegro. Quien lo comprobó, acertó.
La firma guarda silencio sobre una tercera pregunta, que resulta ser la que importaba: qué va a cargar ese programa cuando se ejecute. Windows resuelve las bibliotecas que un programa pide recorriendo una lista de carpetas, y la propia carpeta del programa está en esa lista. Si alguien coloca ahí un fichero con el nombre que el programa espera, el ejecutable firmado lo carga dentro de su propio proceso. A partir de ese instante, el código del atacante corre dentro de un proceso cuyo editor es Siemens, con sus mismos permisos. La firma cubría el continente. El contenido llegó después.
Esto no es un juicio a Siemens. CWE-427 es una de las clases de fallo más repetidas del software de escritorio, y aparece cada año en productos de todos los tamaños; Forescout, que publicó el 15 de octubre su investigación sobre la plataforma de distribución empleada en esta campaña, documentó también un instalador manipulado que se apoyaba en una aplicación legítima de Stardock para la misma maniobra. Lo que nos interesa no es quién tiene la culpa del fallo, sino qué le hace ese fallo a los controles que tú tienes puestos.
Tu lista blanca por editor acaba de aprobar esto
Si la política de control de aplicaciones de tu parque dice «se permite lo que esté firmado por un editor conocido» —que es la configuración pragmática más habitual, porque es la que mejor sobrevive al contacto con usuarios reales—, esta campaña pasa el filtro. No porque el control fallase: porque hizo exactamente lo que le pediste. El ejecutable estaba firmado por un editor conocido.
Lo mismo vale para la columna «¿está firmado?» de tu inventario de software y para la comprobación mental de quien revisa un fichero antes de abrirlo. Los dos daban luz verde con razón. Ninguno de los dos estaba diseñado para responder la pregunta de la que dependía la máquina.
Las políticas que sí resisten esta maniobra son las que autorizan por huella criptográfica o por ruta, no por quién firma. El precio de esas políticas está en el mantenimiento: obligan a mantener una lista que cambia con cada actualización de cada programa, y, por lo que hemos visto montándolas, la mayoría de las pymes que las encienden acaban apagándolas, porque el día que un usuario legítimo no puede trabajar gana la discusión el usuario. Ya hablamos de lo que cuesta mantener una lista de huellas cuando contamos la lista de drivers bloqueados de Windows son 1.702 hashes: una lista explícita envejece, y envejece sola.
El vector dice «local» y tu cola de parches lo lee mal
El vector publicado por Siemens es CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Dos piezas de esa cadena explican por qué la nota se queda en 8,4 y no sube más: AV:L significa que el ataque requiere acceso local, y PR:H, que el atacante ya necesita privilegios altos. Sobre el papel, una combinación mala para quien ataca.
Esa misma lectura es la que hace tu cola de parches un martes por la mañana: local, requiere privilegios, software que sólo tienen tres personas de ingeniería. Al final de la lista. Lo que el vector no puede expresar —no está hecho para eso— es que la campaña regala el acceso local. Alguien convence a un empleado de descargarse un paquete y ejecutarlo en su propia máquina, y con ese gesto queda cubierto el requisito de acceso local. El de privilegios altos lo pone la propia instalación: un paquete que se instala es un paquete que pide elevar. La precondición que hacía difícil el ataque la aporta el usuario, gratis, en la parte de la cadena que CVSS no mira.
Es la misma regla que aplicamos en su día cuando Acronis pedía acceso local y se lo vendías tú: el vector ordena la vulnerabilidad; el catálogo de explotación ordena el día. Mientras un fallo es teórico, el vector manda y un 8,4 local puede esperar al ciclo mensual. El día que entra en el catálogo de CISA, alguien ya ha demostrado que las precondiciones se cumplen en el mundo real, y el argumento «requiere acceso local» deja de ser un motivo para esperar. Esta entró el 20 de octubre.
Sobre cómo se convence al empleado para que ejecute el paquete no hace falta que nos extendamos: lo contamos hace poco mirando la versión para Mac de la misma técnica, en el malware que pegas tú mismo en la terminal. Cambia el sistema operativo y cambia la ventana; la idea de que la víctima ejecute el primer paso con sus propias manos es la misma.
Lo que sí deja rastro
Si la identidad del fichero no sirve para distinguir, lo que queda es el comportamiento. Y ahí la maniobra sí es rara, porque el software legítimo instalado por el departamento de IT casi nunca se comporta así. Estas son las señales que miramos, en orden de utilidad:
- Un ejecutable firmado que corre desde una carpeta donde el usuario puede escribir. Descargas, el perfil del usuario, una carpeta temporal. La mayor parte del software que instala IT vive en
Program Files, donde el usuario no escribe; la maniobra necesita justamente lo contrario, porque el atacante tiene que poder dejar su fichero al lado. - Ese ejecutable cargando un módulo sin firmar desde su propia carpeta. Es la señal más específica de las tres y la que convierte la sospecha en certeza. Un producto comercial carga sus propias bibliotecas, y esas suelen venir firmadas por el mismo editor.
- La cadena de quién lanzó a quién. Un navegador o un intérprete de órdenes que acaba arrancando un instalador es una secuencia que se explica sola cuando es legítima, y que cuesta explicar cuando no lo es.
Aquí viene la parte que no nos conviene comercialmente y que decimos igual: la primera señal genera ruido. Hay software legítimo que se ejecuta desde carpetas de usuario —actualizadores, herramientas portátiles, el instalador que alguien se bajó con permiso— y si enciendes esa regla a secas te llegan avisos todas las semanas. Un panel con avisos que nadie clasifica no es detección: es una pantalla encendida. Lo que separa una cosa de la otra es que alguien los lea y sepa descartar.
Tres preguntas para esta tarde
Ninguna de las tres es un proyecto. Las tres se contestan hoy, y lo que duele no es contestarlas: es descubrir que no puedes.
Lo que nos toca a nosotros
Cuando montamos EDR/MDR gestionado no prometemos bloquearlo todo, porque el día que bloqueas de más el cliente te pide que lo apagues. Lo que sostenemos es la parte aburrida: reglas que miran lo que hace el proceso, no la etiqueta del fichero, el ajuste de esas reglas contra el software real de cada cliente para que el ruido baje a algo clasificable, y alguien que lee los avisos a una hora en la que no hay nadie más leyendo.
Sobre el límite, que lo preguntan en todas las reuniones: nadie puede garantizarte que un agente hubiera frenado archive.dll el primer día. Lo que sí cambia de verdad es el día siguiente. Con telemetría de procesos y módulos guardada, «¿esto se ha ejecutado aquí?» se contesta en minutos sobre todo el parque; sin ella, se contesta en semanas y con un «creemos que no» delante. Esa diferencia —entre saberlo y suponerlo— es la que acaba decidiendo si un incidente es una tarde mala o un trimestre malo.
Si quieres revisar con nosotros qué autoriza hoy tu política de aplicaciones y qué telemetría estás guardando, es una conversación corta: escríbenos. Y si sólo haces una cosa después de leer esto, que sea la segunda pregunta de la tabla. Es la que más duele y la que antes se arregla.
Lo que la firma nunca contestó
La lección de esta campaña cabe en una frase, y vale para mucho más que para un producto de Siemens: la firma contesta quién hizo el fichero, y nada sobre qué hace ese fichero una vez abierto. Llevamos años construyendo controles sobre la primera pregunta porque es barata de comprobar y da una respuesta limpia. La segunda cuesta más, ensucia el panel y obliga a que alguien mire. El 19 de octubre quedó claro cuál de las dos estaba sosteniendo la máquina.
Fuentes. Los datos de CVE-2026-110936 —publicación el 15 de octubre de 2026, puntuación CVSS v4 de 8,4, vector CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, clasificación CWE-427 («uncontrolled search path element»), corrección en la versión V4.0.9.8 con todas las anteriores afectadas, actualización del aviso el 17 de octubre, confirmación de explotación real por parte de Siemens el 19 de octubre, inclusión en el catálogo KEV de CISA el 20 de octubre y fecha límite federal del 3 de noviembre de 2026, y el nombre del fichero malicioso archive.dll— proceden del aviso de Siemens y de su recopilación en Rescana y SecurityWeek. La cita de Siemens «No Siemens system, product or update channel was breached to our knowledge», que los atacantes obtuvieron una copia legítima y firmada y la distribuyeron con ficheros maliciosos fuera de los canales oficiales, el mecanismo (el programa no restringe correctamente dónde busca los DLL, de modo que un DLL colocado en una de esas carpetas se ejecuta con los mismos privilegios que el programa) y la investigación de Forescout publicada el 15 de octubre de 2026 sobre la plataforma de distribución empleada —incluido el instalador manipulado que se apoyaba en una aplicación legítima de Stardock para la misma maniobra— proceden de las mismas fuentes. El funcionamiento del orden de búsqueda de bibliotecas de Windows, que incluye la carpeta del propio ejecutable, es comportamiento documentado del sistema operativo. La lectura de AV:L y PR:H como las dos piezas que limitan la puntuación, el argumento de que la cadena de entrega aporta gratis la precondición de acceso local, la regla «el vector ordena la vulnerabilidad y el catálogo de explotación ordena el día» —ya aplicada en entradas anteriores de este blog—, las tres señales de comportamiento, la advertencia sobre el ruido que genera la primera de ellas y las tres preguntas de la tabla son criterio y método nuestros, no afirmaciones de Siemens, de CISA ni de ninguna de las fuentes anteriores. everyWAN presta servicios gestionados de EDR/MDR: el conflicto de interés queda declarado. Foto de portada: «My view 090909,09 09», de Håkan Dahlström, Wikimedia Commons, CC BY 2.0.
Microsoft 365
ES 
CAT 
EN