CVE-2025-1994
Ibm Cognos Command Center 10.2.4.1 … 10.2.5
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2025-1994 is a high-severity Use of Inherently Dangerous Function (CWE-242) vulnerability in Ibm Cognos Command Center. Its CVSS base score is 7.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 5th 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-2025-25811
Vulnerability Data
IBM Cognos Command Center 10.2.4.1 and 10.2.5 could allow a local user to execute arbitrary code on the system due to the use of unsafe use of the BinaryFormatter function.
- 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.