Por Jorge Martínez Hurtado (Hack the Music)

Abstract

Tradicionalmente, la investigación de ciberseguridad se ha centrado principalmente en ámbitos meramente cercanos a tecnologías de la información: herramientas, ecosistemas, soluciones comerciales, algoritmos, protocolos, etcétera. Esto es debido en gran parte a que el riesgo en estos ámbitos es evidente de observar y considerado prioritario de proteger, en especial al ser conocedores de la rentabilidad asociada al negocio del crimen relacionado con la ciberseguridad. Por ello, resulta evidente la búsqueda de vulnerabilidades en tecnología de la información desplegada globalmente, sin importar su ámbito o aplicación y en especial siendo conocedores de que actores maliciosos también llevan a cabo esfuerzos de investigación y explotación.

No obstante, es preciso efectuar una reflexión: la investigación en el ámbito de la tecnología se lleva a cabo debido a que la misma industria es consciente de los riesgos y la criticidad de los sistemas informáticos que se buscan proteger. Pero, ¿Qué ocurre en otras industrias que no necesariamente son conocedoras de estos riesgos? ¿Qué ocurre cuando la seguridad de la información se percibe como un aspecto complejo, de difícil implementación o, sencillamente, ajeno?

Existen numerosos ámbitos e industrias que, en materia de seguridad, todavía tienen un largo camino por recorrer, y la musical es una de ellas. A través de las labores de investigación efectuadas en el entorno de I+D de Hack the Music, se ha logrado identificar una serie de carencias de seguridad con carácter generalizado en la industria musical que afectan a fabricantes de software, hardware, servicios, y a actores de la industria como medios de comunicación, sellos discográficos, agencias de management y artistas, entre otros.

Mediante la presente publicación, se expondrá en detalle una vulnerabilidad en Max, un framework orientado al desarrollo de aplicaciones audiovisuales interactivas que se ofrece en modalidad standalone y como software embebido en Ableton Live, uno de los programas de producción y edición musical (DAW; Digital Audio Workstation) más utilizados a nivel mundial. Este fallo de seguridad, al que se le ha asignado el identificador CVE-2026-36439, permite la ejecución de código arbitraria y sin interacción por parte de usuario en el entorno de Max (standalone) y en Ableton Live.

Estado del arte

El trabajo previamente realizado acerca de la seguridad de la información en la industria musical es considerablemente limitado y fragmentado en relación a otros ámbitos. Sin duda, es correcto afirmar que existe una casi total ausencia de investigación académica revisada por pares acerca de la seguridad de productos como DAWs, formatos de sesión o protocolos, entre otros. 

La superficie de ataque cubierta por estas investigaciones es muy pequeña en comparación con otras ya cubiertas, como el ámbito IT anteriormente comentado, lo que denota una necesidad notable de esfuerzos de investigación específicos a este área. En el caso de la investigación llevada a cabo en Hack the Music, la misma ha resultado en el primer CVE que afecta a Ableton, empresa de referencia en desarrollo de tecnología musical que lleva en el mercado más de 25 años.

Se exponen, a continuación, una serie de hallazgos en diferentes ámbitos de la industria musical con la finalidad de contextualizar los esfuerzos llevados a cabo e identificar posibles áreas de investigación futura.

1.1. Ejecución de código y malware en plug-ins VST3

Existen precedentes de ejecución de código en formatos de plug-in VST3. Este formato de extensión para DAWs perteneciente a Steinberg, cuyas siglas significan “Virtual Studio Technology 3”, se encuentra ampliamente extendido y es considerado estándar. Consta de una DLL multihilo empaquetada en una estructura de directorios en Windows, mientras que en macOS se trata de un bundle Mach-O. En la imagen a continuación se puede observar “Serum 2”, desarrollado por Xfer Records: uno de los plug-ins VST más potentes y utilizados a día de hoy.

Se ha documentado la creación y ejecución de plug-ins maliciosos por investigadores como infosecnoodle, que logró construir un plug-in malicioso sobre una de las plantillas iniciales para el desarrollo de VST3 que Steinberg ofrece. Este plug-in lograba la ejecución de código arbitraria mediante la anteposición de una llamada system() antes de instanciar el plug-in. La ejecución en el caso de Ableton Live (en Windows) ocurre como un proceso hijo del DAW.

En el caso de macOS, investigadores como Christopher Ross (SpecterOps) o Csaba Fitzl han logrado finalidades similares.

Se tiene constancia, a su vez, de malware en plug-ins ilegítimos dirigidos a productores, como el cryptominer apodado “LoudMiner” (ESET/Michal Malik). Es preciso destacar, a su vez, ThiefQuest / EvilQuest (Dinesh Devadoss; K7 Labs), un malware macOS que combinaba ransomware, spyware y stealer distribuido en instaladores .PKG ilegítimos de software como Ableton Live, Mixed In Key y Little Snitch.

1.2. Vulnerabilidades en DAWs y otros software musical

Si bien no se ha encontrado ningún CVE previamente asignado a Ableton Live (o a sus productos asociados: Max/Max for Live, Push, Link), otros DAW como FL Studio (desarrollado por Image-Line) sí que cuentan con vulnerabilidades reconocidas formalmente. La vulnerabilidad CVE-2005-3092 permitía que un atacante remoto pueda ejecutar código arbitrario usando un archivo de proyecto FL Studio (.flp), debido a un fallo en FLEngine.dll que ocasionaba un desbordamiento de heap. 

Precisamente en FL Studio surgió otra prueba de concepto de vulnerabilidad en 2012, por parte de Souhail Hammou (“Dark-Puzzle”). Este exploit documenta un desbordamiento del búfer basado en SEH (Structured Exception Handling) que logra lo mismo que el CVE anterior: ejecución de código arbitrario. 

Por otra parte, SEC Consult publicó en febrero de 2026 múltiples vulnerabilidades en Native Access para macOS, el gestor de suscripciones y software de Native Instruments. Entre estas vulnerabilidades se encuentra CVE-2026-24070: la aplicación estaba firmada de forma insegura y esto permitía inyección de DYLIB para elevar privilegios. SEC Consult también descubre CVE-2026-24071, que expone un fallo en la validación del cliente XPC por PID que lo hace vulnerable a reutilización de PID.

1.3. Vulnerabilidades en firmware de equipo profesional

Recientemente, AlphaTheta (previamente Pioneer DJ), fabricante de equipamiento y software profesional para DJs, anunció una vulnerabilidad en la funcionalidad “PRO DJ LINK” de rekordbox (software enfocado a gestión de bibliotecas de música y conversión para el formato del hardware AlphaTheta) y ciertos modelos de CDJ y XDJ (reproductores  y mezcladoras DJ todo-en-uno). Este fallo de seguridad descubierto por Triode (Chris L.) permite a un atacante obtener cualquier archivo tanto de hardware AlphaTheta afectado como del equipo ejecutando rekordbox, debido a que el servidor NFS que levantan ambos permite especificar cualquier path. Si bien el servidor cuenta con autenticación, la clave del mismo se encuentra hardcodeada. 

AlphaTheta / Pioneer DJ también ha sido objeto de presentación en RootedCON. En la edición de 2024, el investigador David Cuadrado expuso “NightClubMare”, un framework que permite spoofing de hardware legítimo para controlar remotamente equipamiento DJ, obtener pistas desde los reproductores, etc. A continuación se puede observar un reproductor CDJ-2000NXS2, precisamente el modelo que David Cuadrado investigó para su presentación en RootedCON:

Por otra parte, existen otros precedentes de RCE en equipamiento profesional. Anna Antonenko (“porta”) descubrió un shell de desarrollo en el Yamaha PSR-E433 tras volcar su firmware vía JTAG y examinarlo. Determinó que, enviando un archivo MIDI especialmente diseñado, se lograba la ejecución de código en el propio procesador del producto. El teclado en cuestión es el siguiente:

Acerca de la vulnerabilidad

En el presente apartado, se desarrollarán los detalles técnicos de la vulnerabilidad descubierta, otorgando el pertinente contexto y abordando, entre otros, el proceso de disclosure con los fabricantes implicados.

2.1. Fabricantes y productos afectados

Es preciso distinguir dos fabricantes implicados en esta vulnerabilidad: Cycling’74 (Max / Max for Live) y Ableton (Live).

2.1.1. Cycling’74 (Max, Max for Live)

Cycling '74, Inc. es una empresa norteamericana que desarrolla, entre otros, Max (también conocido como Max/MSP/Jitter), un framework de programación orientado a audio y vídeo basado en una serie de nodos (denominados “objetos”) que permiten crear, manipular y redirigir flujos de señales y datos. En 2017, fue adquirida por Ableton.

Los programas interactivos que se efectúan con Max se denominan “patches” y, como se ha descrito con anterioridad, constan de una serie de objetos que permiten manipular flujos de señales y datos relacionados con audio y vídeo. Cada objeto tiene una finalidad; específicamente, el objeto “node.script” permite la ejecución de scripts JavaScript en un entorno Node incluido en el propio software. También se permite la ejecución de JavaScript mediante los objetos “js”, “jsui” y “v8”.

2.1.2. Ableton (Live, Max for Live)

Ableton AG es una empresa alemana que desarrolla, entre otros, Live: un DAW de referencia en producción de música electrónica utilizado por artistas internacionalmente reconocidos como deadmau5, Skrillex, Daft Punk o David Guetta, entre otros. Este software trabaja en torno a una serie de pistas en las que se pueden añadir los denominados “dispositivos”: herramientas que permiten generar sonido (sintetizadores, samplers) y manipularlo (efectos de audio y MIDI).

Live ofrece la posibilidad de crear y ejecutar dispositivos creados con Max mediante Max for Live (desarrollado en conjunto entre Cycling’74 y Ableton), otorgando a músicos y desarrolladores una forma adicional de interactuar con el programa y extender sus funcionalidades. 

2.2. Detalle técnico

La vulnerabilidad descubierta consiste en un problema de aislamiento de permisos en el entorno Node que tanto Max como Max for Live (y, por extensión, Ableton Live) emplean para ejecutar código JavaScript usando el objeto “node.script”. Este entorno permite acceso al sistema de archivos, a funcionalidades de red y la creación de procesos, entre otros. 

Por otra parte, el código JavaScript se ejecuta automáticamente sin ningún tipo de confirmación o advertencia al usuario. Para poder lograr la ejecución de JavaScript mediante “node.script”, es necesario llamar al script JS desde el objeto ya mencionado:

En este caso, el argumento “@watch 1” indica al objeto node.script que debe recargarse en caso de cambios en el fichero que contiene el código fuente. Por otra parte, el argumento “@autostart 1” es el que facilita la ejecución automática (y sin avisos al usuario) del script cuando el patcher Max o el dispositivo Max for Live se abren.

Adicionalmente, es posible ocultar al usuario que el objeto node.script existe. Tanto en Max como en Max for Live, se cuenta con dos vistas: Presentation View (la interfaz que se muestra al usuario y que típicamente solo incluye elementos de interacción, como botones, cajas de texto o deslizadores) y Patching View (la interfaz de desarrollo, en la que se pueden observar todos los objetos y conexiones entre ellos). Cualquier objeto puede ser libremente ocultado en la vista de presentación (abierta por defecto si así se desea), por lo que incluir scripts maliciosos escondidos en este tipo de dispositivos resulta trivial. A continuación, se observa la comparación entre la vista de presentación (izquierda) y la vista de parcheo (derecha) de la prueba de concepto que se expondrá en profundidad más adelante:

Es de especial importancia señalar que los patchers / dispositivos Max / Max for Live son, por definición, código fuente modificable y redistribuible, lo que abre la posibilidad de modificación, troyanización y redistribución de patchers / dispositivos legítimos y ampliamente utilizados.

Por último, es preciso destacar que, de cara a distribuir patchers Max y/o dispositivos Max for Live, se cuenta con la funcionalidad “Freeze”, que recoge todas las dependencias y código fuente (como el script JavaScript que carga node.script) en un solo archivo traspasable entre usuarios e instalaciones de Max y/o Ableton Live. Este aspecto, unido a la ejecución automática del script sin notificar al usuario y los amplios permisos otorgados a node.script suponen una cadena de condiciones que posibilitan la ejecución de malware potencialmente dañino, de forma automática y oculta para el usuario.

2.3. Prueba de Concepto: hax4live

Para validar la vulnerabilidad expuesta con anterioridad, se ha creado una Prueba de Concepto denominada “hax4live” (“Hacks for Live”) consistente de:

• Un payload JavaScript, insertable en objetos node.script, que se conecta automáticamente usando una implementación propia de WebSockets a un servidor C2 y que permite:
  • Obtención de información del host (SO, hostname, arquitectura, build, etc)
  • Ejecución de comandos individuales
  • Creación de shells (vía child-process) e interacción con las mismas
  • Exfiltración de archivos al servidor C2
  • Envío y recepción de mensajes de texto (con finalidades de debugging)
• Un servidor C2 básico implementado en Python, utilizado para enviar y recibir información desde patchers / dispositivos Max / Max for Live troyanizados y controlarlos remotamente.

El payload JavaScript se ha probado, además, en dos patchers / dispositivos de Max / Max for Live diferentes:

• Un dispositivo de creación propia (“remote2.2-poc”)
• STING!64, desarrollado por SKINNERBOX: el dispositivo Max for Live más descargado de maxforlive.com, repositorio de dispositivos de referencia.

En el vídeo vinculado a continuación, se puede observar cómo el dispositivo de creación propia se utiliza en Ableton Live 12 Suite y, apenas se completa la carga, establece una conexión vía WebSockets con el servidor C2. Tras ello. se ejecutan los comandos “info” (muestra información genérica del sistema, como hostname y sistema operativo), request_file (dado un path completo, extrae tal archivo y lo envía al servidor) y shell_create (crea un nuevo proceso PowerShell y se comunica con él). El vídeo es el siguiente:

Tal y como es posible evidenciar, el usuario no ha sido notificado en ningún momento de que el código JavaScript malicioso se contenía en el dispositivo, ni de que se ejecutaba. Este aspecto es especialmente crítico dado que, en general, los usuarios de Ableton Live y/o Max / Max for Live no cuentan con un perfil técnico que les permita identificar los riesgos que estos dispositivos y los aspectos anteriormente abordados suponen.

Por último, es preciso resaltar un aspecto visto anteriormente: los dispositivos / patchers son código fuente por definición, lo que implica que cualquier persona (o proceso automatizado) puede consultar, modificar y redistribuir ya existentes. Para validar este factor de riesgo, se ha tomado STING!64 (desarrollado por SKINNERBOX), un dispositivo / patcher orientado a la generación de líneas de bajo de estilo acid, y se le ha añadido el payload JavaScript malicioso. El resultado es similar al de la evidencia anterior: se conecta automáticamente al servidor tras cargarse y se pueden ejecutar los mismos comandos, pero se retiene tanto la apariencia como la totalidad de las funcionalidades anteriores. De esta forma, queda evidenciado que la troyanización de dispositivos ya existentes es trivial, además de efectiva y totalmente ocultable al usuario. El vídeo es el siguiente:

La vista de patcheo del dispositivo mostrado en el vídeo es la siguiente. Destacado en el recuadro naranja, se puede observar el payload JavaScript con los argumentos que desencadenan su ejecución automática; el resto de los objetos y conexiones visibles pertenecen al dispositivo original:

2.4. Disclosure y presentaciones en RootedCON

Los detalles técnicos de esta vulnerabilidad, junto a un vídeo-demostración, fueron compartidos con los fabricantes (Ableton y Cycling’74) el día 3 de febrero de 2026 a las direcciones de soporte de Ableton (contact@ableton.com) y Cycling’74 (support@cycling74.com), debido a que ninguno de ellos cuenta con direcciones o formularios específicos para problemas de seguridad. En esta notificación, se indicó que se había encontrado una forma de ejecutar código de forma arbitraria usando node.script y que, adicionalmente, no se había encontrado ninguna forma de notificación a los usuarios (o petición de permiso) al ejecutar código JavaScript de cualquier tipo. Ambos fabricantes fueron también notificados de la intención de llevar a cabo una ponencia en RootedCON Madrid presentando este problema, y se les ofreció la oportunidad de asistir a la misma y discutir, tanto en persona como vía telemática, detalles técnicos y siguientes pasos.

Cycling’74 indicó el día 6 de febrero que la vulnerabilidad descrita “es un aspecto del que son conocedores” y que “redirigieron el mensaje internamente para darle más atención”. Por otra parte, Ableton dió respuesta el 25 de febrero, agradeciendo la notificación pero indicando que “el comportamiento descrito refleja una característica arquitectónica de Max for Live: los dispositivos pueden ejecutar código con los mismos privilegios que el propio Ableton Live”. Adicionalmente, indicaron que “no tenían evidencias de que la seguridad de los usuarios hubiese sido comprometida”. Se procedió a responder a este mensaje, recalcando que lo que se había notificado era un problema de seguridad y que, como mínimo, los usuarios deberían ser notificados cuando un dispositivo contenga código JavaScript externo que se pueda ejecutar. No se obtuvo respuesta por parte de Ableton a esta segunda notificación.

El día 26 de febrero de 2026, se contactó con MITRE usando su formulario de petición de CVE, compartiendo los detalles que se requerían en el mismo. El día 9 de junio, el equipo de asignación de CVE notificó que se había asignado el identificador CVE-2026-36439 a la vulnerabilidad descrita. Se aportaron más detalles acerca de la vulnerabilidad el día 16 de junio, pero en la fecha de redacción del presente artículo todavía no se ha obtenido respuesta. El CVE se encuentra reservado, pero su detalle todavía no es público.

En RootedCON, esta vulnerabilidad se ha presentado en tres ocasiones diferentes, con la finalidad de concienciar a los usuarios de Ableton Live y Max, así como a diferentes actores de la industria musical:

• RootedCON Madrid 2026:
  • Ponencia breve (30 minutos) en el track Rooted enfocada al público técnico.
  • Ponencia extendida (60 minutos) en el track Hack the Music enfocada al público de la industria musical
• RootedCON Valencia 2026.

Conclusiones

Tal y como se ha podido observar, la explotación de la vulnerabilidad descrita es trivial, automatizable y escalable. Con la finalidad de cerrar este artículo, es preciso efectuar una reflexión acerca del estado actual de la seguridad de la información en la industria musical, tanto desde el punto de vista de los fabricantes como de los artistas.

Por una parte, resulta esencial que los fabricantes de software sean entendedores de las implicaciones que este tipo de permisos demasiado abiertos suponen. Por supuesto, se pueden llevar a cabo actividades realmente creativas teniendo tal entorno JavaScript disponible (por ejemplo, automatizar la búsqueda de samples en librerías, descargar automáticamente recursos musicales de repositorios online…), pero esto no implica que se deba dejar de lado la seguridad. Afirmar que una serie de permisos peligrosos es una “característica arquitectónica” del software no es el enfoque adecuado y únicamente daña a los usuarios. Tal y como se describió en la notificación a los fabricantes, lo mínimo que se debe hacer es, al menos, notificar a los usuarios de los riesgos que este entorno implica y solicitarles autorización (tras su revisión) antes de lanzar automáticamente código JavaScript.

Por otra parte, es muy necesario llevar a cabo acciones de concienciación de ciberseguridad en la industria musical. En Hack the Music se cuenta con contactos en diferentes partes de esta industria, y en base a lo observado, hay mucho trabajo por delante. Los diferentes actores que componen esta industria (músicos, mánagers, sellos, agencias, distribuidores, etcétera) son generalmente desconocedores de medidas de seguridad tan básicas como la no reutilización de contraseñas, el uso de doble factor de autenticación o la realización y comprobación periódica de copias de seguridad para evitar perder datos operativos esenciales, como contratos, riders o acuerdos de no divulgación. En la amplia mayoría de los casos, esto ocurre debido a una barrera de conocimiento técnico que estos actores no pueden superar.

En muchas ocasiones, un incidente de seguridad en la industria musical no solo afecta a sellos y artistas, sino que también puede impactar en los fans y clientes. Casuísticas como el compromiso de la tienda oficial de un sello o artista, de ticketeras o de plataformas de streaming (que ya se ha observado con anterioridad) suelen implicar la filtración de datos personales de clientes, con las consecuencias legales y de seguridad que ello conlleva.

Sería óptimo y de gran beneficio que, de forma progresiva, y en especial con la ayuda de herramientas tan potentes como las que se tienen a día de hoy, se empezasen a llevar a cabo investigaciones de seguridad en industria musical y que, por supuesto, tanto fabricantes, actores e investigadores tomasen actitudes de colaboración. Juntos, se pueden mejorar muchos aspectos que, una vez más, benefician a todos.