IBM Aspera Desktop CVE-2026-11980

Exploitation requires local access to the host with at least low-level privileges (PR:L) and the ability to write a malicious DLL into a directory that the Aspera Desktop App searches at start-up (application directory or a writable PATH entry). It further requires user interaction (UI:R): the victim must launch the vulnerable Aspera Desktop App so the planted DLL is loaded - the code does not run on its own. Limiting factors: the attacker cannot trigger this remotely, must already have a foothold and write access to a searched path, and success depends on the victim starting the app; a properly permissioned install directory (non-writable by standard users) and a clean PATH substantially prevent exploitation.

The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H yields 7.3 (High) but the metrics tell the real story: the attack vector is Local (AV:L), requires existing low privileges (PR:L) on the host, and requires user interaction (UI:R) - namely the victim starting the vulnerable app. This is not a remotely reachable, wormable issue; it is a local code-execution / privilege-abuse primitive that presumes an attacker already has a foothold and can write a DLL to a searched directory. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit is identified, so there is no evidence of active or automatable exploitation. Net: a legitimate High-severity local flaw worth patching, but lower operational urgency than the raw 7.3 might suggest given the local + user-interaction prerequisites. Note the CWE-242 mapping is somewhat generic for a DLL-loading issue - the concrete mechanism is untrusted search path, so defenders should reason about it as DLL hijacking rather than a specific dangerous API call.

An attacker who already has an unprivileged account on a Windows host (or who tricks a user into extracting an archive into the app's working directory) plants a malicious DLL with a name the Aspera Desktop App loads at start-up. When the victim next launches the application, the app resolves the attacker's DLL from the search path and executes its code with the user's privileges. No public exploit is identified at time of analysis, but the technique is well understood and straightforward to reproduce.