CVE-2026-11980
Ibm Aspera Desktop App 1.0.5 – 1.0.19
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:HSummary
CVE-2026-11980 is a high-severity Use of Inherently Dangerous Function (CWE-242) vulnerability in Ibm Aspera Desktop App. Its CVSS base score is 7.3 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-51142
Vulnerability Data
IBM Aspera Desktop App 1.0.5 through 1.0.19 can allow arbitrary code execution by loading DLL files at start-up.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and code analysis can locate calls to known dangerous functions after they have been written.
Documented development standards and tools can explicitly prohibit or replace inherently dangerous functions.
An SDLC that incorporates security can embed rules against unsafe functions in coding and review phases.
Engineering principles can mandate avoidance of unsafe library functions during design and coding.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prohibit or replace inherently dangerous functions via coding standards, reviews, and tooling.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can surface calls to unsafe functions but does not prevent their introduction.
Secure SDLC processes include code review and static analysis that can detect dangerous function usage.
Secure coding standards explicitly ban or restrict inherently dangerous functions.
Controlled software installation reduces exposure to unsafe third-party code containing dangerous functions.