Critical certificate validation flaw reported in Icinga 2 monitoring
Take action: If you're running Icinga 2, immediately check if you're vulnerable by running icinga2 --version | grep OpenSSL - if it shows OpenSSL version older than 1.1.0, you need to start planning a patch. Update to the latest patched versions (2.14.6, 2.13.12, or 2.12.12). If that's not possible, restrict network access to your Icinga master nodes until you can patch.
Learn More
Icinga has addressed a critical security vulnerability in its monitoring platform that enables attackers to bypass certificate validation and obtain legitimate certificates for impersonating trusted network nodes.
The flaw is tracked as CVE-2025-48057 (CVSS score 9.3) and is caused by Icinga 2's VerifyCertificate() function, which can be manipulated to incorrectly validate malicious certificates as legitimate. This occurs when attackers send specially crafted certificate requests that the system treats as renewals of existing certificates, ultimately granting the attacker a valid certificate signed by the Icinga Certificate Authority. The security flaw stems from a legacy behavior in OpenSSL versions prior to 1.1.0, where a "valid" flag stored within certificate objects could persist between validation operations, causing certain verification steps to be skipped.
The vulnerability impacts Icinga 2 installations compiled with OpenSSL versions older than 1.1.0, which was released in 2016. Administrators can verify their exposure by executing icinga2 --version | grep OpenSSL to check the underlying OpenSSL version.
Icinga has released patched versions 2.14.6, 2.13.12, and 2.12.12 that resolve the certificate validation flaw. The updates also address an additional use-after-free vulnerability discovered in the same VerifyCertificate() function and include OpenSSL updates for Windows installations.
Organizations should prioritize upgrading master nodes running vulnerable OpenSSL versions immediately, as these represent the primary attack vector.
For environments where immediate patching is not feasible, temporary workarounds include restricting network access to master nodes or temporarily disabling certificate signing by renaming the /var/lib/icinga2/ca directory. The renaming approach prevents new node enrollment and certificate renewals, making it suitable only for short-term protection
