CVE-2023-22318
Tribe29 Checkmk Appliance Firmware ≤ 1.6.5
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2023-22318 is a high-severity Unrestricted Externally Accessible Lock (CWE-412) vulnerability in Tribe29 Checkmk Appliance Firmware. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 42th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-26481
Vulnerability Data
Denial of service in Webconf in Tribe29 Checkmk Appliance before 1.6.5.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
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.
Enforcing least-privilege authorization policies directly prevents external actors from acquiring or influencing locks.
Logical access controls and segmentation stop unintended external influence over synchronization primitives.
Secure SDLC practices directly include code reviews, static analysis, and concurrency standards that prevent improper locking.
Vulnerability identification processes can discover externally controllable locks before deployment.
Hardened configuration baselines can disable or restrict external lock exposure by default.
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 detect race conditions and locking errors before release.
Restricting privileged utilities can limit external lock manipulation but does not address the core weakness.
Privileged access rights limit who can create or manipulate locks, reducing external influence.
Network security measures can block external access paths to locks but do not address the design flaw itself.
Secure development lifecycle practices can prevent introducing externally controllable locks during design.
Application security requirements can mandate that locks remain within the intended control sphere.