CVE-2025-48057: Critical Certificate Flaw in Icinga 2

CVE-2025-48057 is a critical certificate validation flaw (CVSS 9.8) in Icinga 2. The VerifyCertificate() function can be tricked into treating certificates as valid, so an attacker could impersonate trusted nodes. It only occurs when Icinga 2 is built with OpenSSL older than 1.1.0. Fixed in 2.12.12, 2.13.12 and 2.14.6.

What's affected

Per the CVE record and the Icinga advisory, the affected releases are Icinga 2 before 2.12.12, before 2.13.12 and before 2.14.6. The fixed versions are 2.12.12, 2.13.12 and 2.14.6, one for each release line.

There is a second condition that matters a great deal. The advisory says that if Icinga 2 is built with OpenSSL 1.1.0 (released in 2016) or later, it is not affected. The problem only arises with OpenSSL older than 1.1.0.

So the exposed group is small in practice: installations running an Icinga 2 build linked to a very old OpenSSL, usually on a long unpatched operating system. Even so, the score is the top of the scale because the attacker gets a valid certificate for the cluster.

The record files the issue under CWE-296 (Improper Following of a Certificate Chain of Trust). The base vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

How to check if you're exposed

The advisory gives the check directly. Run this on each Icinga 2 host:

icinga2 --version | grep OpenSSL

If the OpenSSL version shown is 1.1.0 or later, you are not affected by this issue. If it is older than 1.1.0, continue.

Then check the Icinga 2 version itself:

icinga2 --version

Compare it with the fixed versions 2.12.12, 2.13.12 and 2.14.6 for your release line. Remember to check satellites and agents as well as the master, because the certificate trust is cluster wide.

Finally, if you have an old OpenSSL, treat that as a finding on its own. A monitoring node linked to a library from before 2016 probably has other issues the operating system vendor stopped fixing long ago.

What to do now

1. Run the OpenSSL check from the section above on every master, satellite and agent to see which are linked to OpenSSL older than 1.1.0.
2. Upgrade affected hosts to 2.12.12, 2.13.12 or 2.14.6, whichever matches your release line.
3. Where possible, move to a package built against a current OpenSSL by upgrading the operating system as well.
4. Review the certificate requests and signed certificates in your Icinga PKI for entries you did not expect, and revoke any you cannot account for.
5. Limit which networks can reach the Icinga API and cluster ports to your own nodes.
6. Add monitoring hosts to your component inventory, so old libraries are noticed before an advisory arrives. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component.

Why it matters

Icinga 2 nodes trust each other through certificates. The function at the centre of this record is meant to decide whether a certificate is genuinely one that the cluster signed. In the affected builds, it can be fooled, and a malicious certificate request can be treated as a renewal of one that already exists. The result is a valid certificate that lets the attacker pose as a trusted node.

The weakness class is improper following of a certificate chain of trust. It is a reminder that a monitoring system is a high value target. It often holds credentials, runs commands on many hosts and sees the state of the whole network. Impersonating one of its nodes is worth effort.

It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the record does not report exploitation in the wild. The OpenSSL condition narrows the exposure a lot, which is why the first step is a one line check, not a panic upgrade across everything.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NVD record for CVE-2025-48057
• Icinga 2 GitHub security advisory GHSA-7vcf-f5v9-3wr6

Last reviewed: 18 October 2026.