CVE-2026-61550: Icinga 2 Authentication Bypass Vulnerability

CVE-2026-61550 Overview

CVE-2026-61550 is a missing authorization vulnerability [CWE-862] in Icinga 2, an open source monitoring system. The flaw resides in the JSON-RPC handler for update certificate messages, which fails to validate that the sender is a trusted endpoint. An unauthenticated network attacker able to reach TCP port 5665 can replace the node certificate and the trusted CA certificate, impersonate a trusted node, and take over the node. Affected releases span from version 2.8 up to (but not including) 2.14.9, 2.15.4, and 2.16.2. The issue is tracked under GitHub Security Advisory GHSA-vj39-ww8j-vvx5 and resolved in Icinga 2 versions 2.14.9, 2.15.4, and 2.16.2.

Critical Impact
An unauthenticated attacker with network access to port 5665 can seize control of an Icinga 2 node by overwriting its PKI trust material.

Affected Products

Icinga 2 versions 2.8 through 2.14.8
Icinga 2 versions 2.15.0 through 2.15.3
Icinga 2 versions 2.16.0 and 2.16.1

Discovery Timeline

2026-09-18 - CVE-2026-61550 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-61550

Vulnerability Analysis

Icinga 2 clusters communicate over a mutual-TLS JSON-RPC channel on TCP port 5665. The UpdateCertificateHandler function in lib/remote/jsonrpcconnection-pki.cpp processes incoming update certificate messages that push new node and CA certificates. Before the patch, the handler only checked the origin zone relationship and did not verify that the message came from a valid endpoint. As a result, any peer able to open a TLS connection could send crafted PKI update messages that the handler would accept and act upon.

A successful attacker overwrites the node's certificate and the trusted CA store, effectively re-parenting the node under an attacker-controlled trust chain. Because Icinga 2 uses these certificates to authenticate cluster peers and execute distributed check commands, node compromise cascades into command execution and monitoring data tampering across the environment.

Root Cause

The root cause is a missing authorization check [CWE-862] in UpdateCertificateHandler. The original guard only validated the sender's zone when origin->FromZone was set; connections with no associated endpoint bypassed the check entirely. Sensitive PKI state mutations were reachable without proof that the caller was an authenticated cluster endpoint.

Attack Vector

Exploitation requires only network reachability to TCP port 5665 on an Icinga 2 master, satellite, or agent. The attacker completes a TLS handshake, sends an update certificate JSON-RPC message with attacker-supplied certificate material, and observes the target install the new trust anchors. No credentials, prior authentication, or user interaction are needed.

cpp

// Patch: lib/remote/jsonrpcconnection-pki.cpp
Value UpdateCertificateHandler(const MessageOrigin::Ptr& origin, const Dictionary::Ptr& params)
{
-	if (origin->FromZone && !Zone::GetLocalZone()->IsChildOf(origin->FromZone)) {
+	if (!origin->FromClient->GetEndpoint() || (origin->FromZone && !Zone::GetLocalZone()->IsChildOf(origin->FromZone))) {
 		Log(LogWarning, "ClusterEvents")
 			<< "Discarding 'update certificate' message from '"
 			<< origin->FromClient->GetIdentity() << "': Invalid endpoint origin (client not allowed).";

Source: Icinga2 Commit 4b7fb34. The fix adds a !origin->FromClient->GetEndpoint() guard that rejects PKI updates from any peer not registered as a cluster endpoint.

Detection Methods for CVE-2026-61550

Indicators of Compromise

Log entries in icinga2.log referencing the ClusterEvents category with update certificate messages from unknown identities.
Unexpected modifications to files under /var/lib/icinga2/certs/, particularly the node certificate and ca.crt.
New or unrecognized certificate fingerprints presented by Icinga 2 endpoints during TLS handshakes on port 5665.
Inbound TCP connections to port 5665 originating from hosts outside the documented cluster topology.

Detection Strategies

Alert on any update certificate JSON-RPC log message whose source identity is not present in the Icinga 2 endpoint inventory.
Baseline SHA-256 hashes of ca.crt and node certificates, then alert on out-of-band changes.
Correlate certificate file modification events with process activity of icinga2 and preceding network flows to port 5665.

Monitoring Recommendations

Ingest Icinga 2 logs into your SIEM and build a rule targeting the string Discarding 'update certificate' message and its success-path counterpart.
Monitor network telemetry for connections to port 5665 from source addresses outside the cluster allow-list.
Track version banners and installed package versions across all Icinga 2 hosts to identify unpatched nodes.

How to Mitigate CVE-2026-61550

Immediate Actions Required

Upgrade all Icinga 2 masters, satellites, and agents to 2.14.9, 2.15.4, or 2.16.2 depending on the deployed branch.
Restrict inbound access to TCP port 5665 to known cluster peers using host or network firewalls until patching is complete.
Audit certificate stores on every Icinga 2 node and reissue any certificates suspected of tampering.
Review icinga2.log for prior update certificate events from unexpected identities.

Patch Information

The Icinga project addressed CVE-2026-61550 in the v2.14.9, v2.15.4, and v2.16.2 releases. The code change is delivered in commits 4b7fb34, 6c2e0db, a6f7cc7, and d37b0cf, consolidated in pull request #10907. See the Icinga 2 security release blog and GHSA-vj39-ww8j-vvx5 for full advisory details.

Workarounds

Where immediate patching is not possible, restrict TCP port 5665 at the network perimeter and host firewall so only known Icinga 2 endpoints can connect.
Terminate Icinga 2 traffic behind a jump host or VPN that enforces peer authentication before reaching the JSON-RPC listener.
Increase logging verbosity on Icinga 2 nodes and actively review cluster event logs for unauthorized certificate update attempts.

bash

# Example iptables restriction: allow only cluster peers to reach port 5665
iptables -A INPUT -p tcp --dport 5665 -s 10.0.0.10 -j ACCEPT   # master
iptables -A INPUT -p tcp --dport 5665 -s 10.0.0.11 -j ACCEPT   # satellite
iptables -A INPUT -p tcp --dport 5665 -j DROP