CVE-2024-49369: Icinga Auth Bypass Vulnerability

CVE-2024-49369 Overview

CVE-2024-49369 is a critical TLS certificate validation bypass vulnerability affecting Icinga 2, a widely deployed network monitoring system used for checking the availability of network resources, notifying users of outages, and generating performance data for reporting. The vulnerability exists in all Icinga 2 versions starting from 2.4.0 and allows 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).

Critical Impact

This vulnerability enables attackers to bypass TLS certificate validation entirely, allowing impersonation of trusted cluster nodes and authenticated API users in Icinga 2 monitoring infrastructure. Successful exploitation could lead to complete compromise of monitoring integrity and unauthorized access to sensitive infrastructure data.

Affected Products

• Icinga 2 versions 2.4.0 through 2.11.11
• Icinga 2 versions 2.12.0 through 2.12.10
• Icinga 2 versions 2.13.0 through 2.13.9
• Icinga 2 versions 2.14.0 through 2.14.2
• Debian Linux 11.0

Discovery Timeline

• November 12, 2024 - CVE-2024-49369 published to NVD
• November 12, 2024 - Icinga releases security patches (v2.14.3, v2.13.10, v2.12.11, v2.11.12)
• November 26, 2025 - Last updated in NVD database

Technical Details for CVE-2024-49369

Vulnerability Analysis

This vulnerability falls under CWE-295: Improper Certificate Validation. The flawed TLS certificate validation logic in Icinga 2's UnbufferedAsioTlsStream class allowed connections to be considered valid even when the peer certificate was never properly verified. The IsVerifyOK() method was returning a default true value stored in the m_VerifyOK member variable without actually querying the OpenSSL verification result.

The impact of this vulnerability is severe because Icinga 2 relies on mutual TLS authentication for both cluster communication between nodes and API authentication. An attacker with network access could present any certificate—or no certificate at all—and still be treated as authenticated. This breaks the entire trust model of Icinga 2's distributed monitoring architecture.

Root Cause

The root cause lies in the implementation of the IsVerifyOK() method in lib/base/tlsstream.cpp. The original code simply returned a member variable m_VerifyOK that was initialized to true in the constructor, rather than dynamically checking the actual SSL verification result using OpenSSL's SSL_get_verify_result() function. This meant the verification status was never actually queried from the underlying TLS implementation.

Attack Vector

The attack can be executed over the network without authentication. An attacker could:

1. Intercept network traffic between Icinga 2 cluster nodes or API clients
2. Present a self-signed or invalid TLS certificate during the handshake
3. Successfully authenticate due to the flawed validation logic
4. Impersonate a trusted cluster node to inject false monitoring data
5. Impersonate an API user with client_cn authentication to execute administrative API calls

// Original vulnerable code (tlsstream.cpp)
bool UnbufferedAsioTlsStream::IsVerifyOK() const
{
    return m_VerifyOK;  // Always returned true (initialized in constructor)
}

// Fixed code with proper validation
bool UnbufferedAsioTlsStream::IsVerifyOK()
{
    if (!SSL_is_init_finished(native_handle())) {
        // handshake was not completed
        return false;
    }

    if (GetPeerCertificate() == nullptr) {
        // no peer certificate was sent
        return false;
    }

    return SSL_get_verify_result(native_handle()) == X509_V_OK;
}

Source: Icinga2 Security Commit

Detection Methods for CVE-2024-49369

Indicators of Compromise

• Unexpected cluster node registrations or API connections from unrecognized IP addresses
• Log entries showing successful TLS connections from hosts that should not have valid certificates
• Anomalous API activity from client certificate-authenticated users
• Monitoring data inconsistencies that could indicate injected or modified check results

Detection Strategies

• Review Icinga 2 logs for TLS handshake events and correlate with known trusted certificate fingerprints
• Monitor network connections to Icinga 2 API ports (default 5665) for connections from unexpected sources
• Implement network intrusion detection rules to identify TLS connections with certificate anomalies
• Audit ApiUser configurations with client_cn attributes for unauthorized access attempts

Monitoring Recommendations

• Enable verbose TLS logging in Icinga 2 to capture certificate details during handshakes
• Deploy network monitoring to track all inbound connections to Icinga 2 cluster and API endpoints
• Implement certificate transparency monitoring for your Icinga 2 infrastructure
• Set up alerting for any new cluster node joins or API authentication events

How to Mitigate CVE-2024-49369

Immediate Actions Required

• Upgrade immediately to patched versions: v2.14.3, v2.13.10, v2.12.11, or v2.11.12
• Audit existing cluster nodes and API users to verify no unauthorized entities have gained access
• Review Icinga 2 logs for any suspicious connection attempts prior to patching
• Rotate TLS certificates if compromise is suspected
• Consider temporary network-level restrictions to Icinga 2 API ports until patching is complete

Patch Information

Icinga has released security patches across all supported version branches. The fixes are available in versions v2.14.3, v2.13.10, v2.12.11, and v2.11.12. The patch corrects the IsVerifyOK() method to properly verify TLS certificates by checking the OpenSSL verification result rather than relying on a default true value. Debian has also released patches for Debian Linux 11.0 users.

Detailed patch information is available in the GitHub Security Advisory and the Icinga Blog Post.

Workarounds

• If immediate patching is not possible, restrict network access to Icinga 2 API port (5665) using firewall rules to only allow connections from known trusted IP addresses
• Implement network segmentation to isolate Icinga 2 cluster communication from untrusted networks
• Consider deploying a VPN or additional authentication layer in front of Icinga 2 API endpoints
• Monitor and alert on any connection attempts to Icinga 2 services from outside the trusted network range

# Example firewall rules to restrict Icinga 2 API access (iptables)
# Replace TRUSTED_IP with your actual trusted cluster node IPs

# Allow Icinga 2 API from trusted nodes only
iptables -A INPUT -p tcp --dport 5665 -s TRUSTED_NODE_1_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 5665 -s TRUSTED_NODE_2_IP -j ACCEPT

# Drop all other connections to Icinga 2 API port
iptables -A INPUT -p tcp --dport 5665 -j DROP

# Verify current Icinga 2 version
icinga2 --version