CVE-2024-49369: Icinga icinga2 · Improper Certificate Validation
Affects Icinga icinga2Source CVE Database V5
Not known to be exploited · CVSS 9.8 Critical · fixed in 2.14.3 : patch Icinga icinga2 as a priority.
Data as of 26 Oct 2026, 10:12 UTC
- EPSS
- 2.9% chance of exploitation in 30 days – higher than 86% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.14.3, 2.13.10, 2.12.11 +1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 12 Nov 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade icinga/icinga2 to 2.14.3, 2.13.10, 2.12.11 or 2.11.12.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubicinga/icinga2pkg:github/icinga/icinga2Other threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
To mitigate CVE-2024-49369, European organizations should immediately upgrade all Icinga 2 installations to the fixed versions: 2.11.12, 2.12.11, 2.13.10, or 2.14.3, depending on their current version branch. Beyond patching, organizations should audit and harden TLS configurations by enforcing strict certificate validation policies and ensuring that all cluster nodes and API users use properly issued and managed certificates. Network segmentation should be applied to isolate monitoring clusters from untrusted networks, reducing exposure to remote attacks. Implementing mutual TLS authentication with certificate pinning can further reduce impersonation risks. Monitoring logs and alerts for unusual cluster node or API user activity can help detect attempted exploitation. Additionally, organizations should review and tighten API user permissions and client_cn attribute usage to minimize the attack surface. Regular vulnerability scanning and penetration testing focused on TLS and cluster communications are recommended to identify residual weaknesses. Finally, maintaining an incident response plan that includes monitoring system compromise scenarios will improve resilience against exploitation.
Description
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. The TLS certificate validation in all Icinga 2 versions starting from 2.4.0 was flawed, allowing an attacker to impersonate both trusted cluster nodes as well as any API users that use TLS client certificates for authentication (ApiUser objects with the client_cn attribute set). This vulnerability has been fixed in v2.14.3, v2.13.10, v2.12.11, and v2.11.12.
References
- github.com/Icinga/icinga2/security/advisories/GHSA-j7wq-r9mg-9wpv (opens in a new tab)
- github.com/Icinga/icinga2/commit/0419a2c36de408e9a703aec0962061ec9a285d3c (opens in a new tab)
- github.com/Icinga/icinga2/commit/2febc5e18ae0c93d989e64ebc2a9fd90e7205ad8 (opens in a new tab)
- github.com/Icinga/icinga2/commit/3504fc7ed688c10d86988e2029a65efc311393fe (opens in a new tab)
- github.com/Icinga/icinga2/commit/869a7d6f0fe38c748e67bacc1fbdd42c933030f6 (opens in a new tab)
- github.com/Icinga/icinga2/commit/8fed6608912c752b337d977f730547875a820831 (opens in a new tab)
- icinga.com/blog/2024/11/12/critical-icinga-2-security-releases-2-14-3 (opens in a new tab)
- lists.debian.org/debian-lts-announce/2024/11/msg00010.html (opens in a new tab)