CVE-2023-44976
Raw vector
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:LCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-44976 is a low-severity Exposed IOCTL with Insufficient Access Control (CWE-782) vulnerability in Paloaltonetworks (inferred from references). Its CVSS base score is 3.2 (Low).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); 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 AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-49299
Vulnerability Data
Hangzhou Shunwang Rentdrv2 before 2024-12-24 allows local users to terminate EDR processes and possibly have unspecified other impact via DeviceIoControl with control code 0x22E010, as exploited in the wild in October 2023.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V8.2.1
Mitigating Controls (NIST 800-53 r5) AI
AC-3 directly requires enforcement of access authorizations on system resources, which structurally stops an IOCTL from being exposed without proper controls.
AC-6 requires least-privilege assignments that limit which users or processes can reach privileged IOCTL functionality.
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.
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.
Privileged access rights directly restrict who may invoke sensitive IOCTLs.
Secure development lifecycle includes design-time access-control requirements for device interfaces.
A.8.26 only requires that security requirements (including access controls) be identified and specified during development; it does not itself enforce, implement or prevent exploitation of an exposed IOCTL
A.8.27 mandates security-by-design, least privilege, default-deny, and explicit access-control analysis in architecture and hardening, which reaches the authorization logic around an IOCTL; it does not guarantee that every driver or third-party component will correctly implement those principles, leaving a bounded remainder.
Secure coding practices prevent omission of access-control checks on IOCTL handlers.
Security testing can detect missing IOCTL authorization during development.