CVE-2026-61550
Executive Summary
CVE-2026-61550 is a critical missing authorization vulnerability in Icinga 2, an open source monitoring system. From version 2.8 until 2.14.9, 2.15.4, and 2.16.2, the certificate update JSON-RPC message handling fails to validate that the sender is a trusted endpoint. An unauthenticated network attacker who can reach TCP port 5665 can replace the node certificate and trusted CA certificate, impersonate a trusted node, and take control of the affected node.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability resides in Icinga 2's JSON-RPC message handling layer, specifically the code path responsible for processing certificate update messages. Icinga 2 nodes communicate over TCP port 5665 using a JSON-RPC protocol. In a properly configured Icinga 2 cluster, nodes exchange certificates to establish mutual trust and secure communications.
The core flaw is a missing authorization check (CWE-862). When an Icinga 2 node receives a certificate update JSON-RPC message, the handler does not verify that the sender is a trusted endpoint. This means any network-reachable party that can connect to TCP port 5665 and craft a valid JSON-RPC certificate update message can cause the target node to replace its own node certificate and trusted CA certificate.
Because Icinga 2 uses X.509 certificates for node identity and trust establishment, replacing the node certificate and CA certificate effectively allows the attacker to:
- Impersonate a trusted node within the Icinga 2 cluster.
- Insert a rogue CA into the trust store, enabling the attacker to issue arbitrary certificates that the node will trust.
- Take control of the node by assuming the identity of a trusted cluster member.
The attack surface is the Icinga 2 cluster communication port (TCP 5665), which is intended for internal node-to-node communication. These ports are frequently exposed to broader network segments in large enterprise monitoring deployments. Because the vulnerability is exploitable without authentication (PR:N), requires no user interaction (UI:N), and has a network attack vector (AV:N), the CVSS v3.1 base score is 9.8 (Critical).
No public proof-of-concept or exploit code is available for this CVE. The attack chain described below is inferred from the vulnerability class (missing authorization in JSON-RPC message handling) and the vendor description.
Exploitation Scenarios
No public PoC is available; the attack chain is inferred from the vulnerability class and the NVD description.
Reconnaissance / Target Identification: An attacker scans for hosts exposing TCP port 5665, the default Icinga 2 cluster communication port. Shodan dorks such as
port:5665can identify internet-exposed Icinga 2 nodes. The attacker identifies Icinga 2 nodes that are either directly reachable or reachable from a compromised network segment.Triggering the Flaw: The attacker establishes a TCP connection to port 5665 on the target Icinga 2 node. Because the certificate update JSON-RPC message handler does not validate that the sender is a trusted endpoint, the attacker does not need to present a valid client certificate or authenticate in any way. The attacker sends a crafted JSON-RPC message — the certificate update message type — to the target node.
Payload / Execution Method: The attacker supplies a malicious X.509 node certificate and a malicious trusted CA certificate within the certificate update JSON-RPC message. The target node processes the message and replaces its existing node certificate and trusted CA certificate with the attacker-supplied values. At the vulnerability-class level, this is an authorization bypass via unvalidated RPC input — the attacker does not need to exploit a memory corruption or injection flaw; the node simply performs the certificate replacement because the sender is not verified.
Post-Exploitation Impact: With the node certificate and trusted CA replaced, the attacker can:
- Impersonate a trusted node and participate in cluster communications as a legitimate member.
- Issue certificates signed by the attacker-controlled CA that the victim node will trust, enabling persistent man-in-the-middle or further node compromise.
- Take control of the node, which in a monitoring system can mean manipulating monitoring data, suppressing alerts, or using the monitoring infrastructure as a pivot into managed hosts.
- Since Icinga 2 is a monitoring system, compromise can lead to falsified availability/health data, alert suppression, and lateral movement via the monitoring server's management channels to monitored endpoints.
The attack requires only network reachability to TCP 5665; no credentials, no user interaction, and no prior foothold on the target node are required.
Impact Assessment
The CVSS v3.1 base score is 9.8 (Critical), with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This reflects:
- Confidentiality (High): Node control can expose monitoring data, configuration, and potentially credentials or management access to monitored systems.
- Integrity (High): Certificate replacement and node impersonation allow the attacker to alter trust relationships and node identity, and to falsify monitoring data or cluster state.
- Availability (High): An attacker controlling a monitoring node can disrupt monitoring, suppress alerts, or render the node unusable.
- Scope (Unchanged): The impact is confined to the vulnerable node's security authority, though in practice a compromised monitoring node can serve as a pivot to monitored infrastructure.
Blast radius: Any Icinga 2 node running an affected version that is reachable on TCP 5665 by an untrusted party is at risk. In enterprise deployments, Icinga 2 master and satellite nodes often communicate across network segments; a single compromised or reachable node can undermine cluster trust. Because the attacker can replace the trusted CA certificate, trust compromise may propagate to any node that trusts the affected node's CA. Organizations using Icinga 2 for critical monitoring (infrastructure health, security alerting) face operational and security-monitoring blind spots.
Detection Guidance
Sigma Rule
title: Icinga 2 Unauthorized Certificate Update JSON-RPC Message
id: 8f3c2a1e-4b7d-4e9a-9c1f-2d6e8b0a5f31
status: experimental
description: Detects Icinga 2 certificate update operations that may indicate exploitation of CVE-2026-61550, where an unauthenticated sender can replace node and CA certificates.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-61550
author: valtersit.com
date: 2026/01/01
tags:
- attack.initial_access
- attack.t1190
logsource:
product: icinga
service: icinga2
detection:
selection:
message|contains:
- 'certificate update'
- 'CertificateUpdate'
- 'trusted CA certificate'
- 'node certificate'
condition: selection
falsepositives:
- Legitimate cluster certificate rotation by trusted nodes
- Administrative certificate renewal operations
level: high
YARA Rule
rule CVE_2026_61550_Icinga2_CertUpdate_RPC
{
meta:
description = "Detects JSON-RPC certificate update messages associated with CVE-2026-61550 in Icinga 2"
author = "valtersit.com"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-61550"
date = "2026-01-01"
severity = "critical"
strings:
$rpc = "jsonrpc"
$method1 = "certificate" nocase
$method2 = "CertificateUpdate" nocase
$method3 = "ca.crt"
$method4 = "node.crt"
$icinga = "icinga" nocase
condition:
$rpc and $icinga and 1 of ($method*)
}
Suricata IDS Rule
alert tcp any any -> any 5665 (msg:"CVE-2026-61550 Icinga 2 Unauthenticated Certificate Update JSON-RPC Attempt"; flow:established,to_server; content:"jsonrpc"; nocase; content:"certificate"; nocase; distance:0; content:"update"; nocase; distance:0; classtype:attempted-admin; sid:2026615501; rev:1; reference:cve,2026-61550; metadata:affected_product Icinga_2, attack_target Server, created_at 2026_01_01, cve CVE_2026_61550, signature_severity Critical;)
Elastic Detection
sequence by host.id with maxspan=30s
[network where destination.port == 5665 and event.action == "connection_attempted"]
[process where process.name == "icinga2" and process.args : "*certificate*"]
Splunk SPL Query
index=icinga OR index=linux sourcetype=icinga2:main OR sourcetype=syslog
| search ("certificate update" OR "CertificateUpdate" OR "trusted CA certificate")
| stats count min(_time) as first_seen max(_time) as last_seen by host, src_ip, message
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
Wazuh OSSEC Rule
<group name="icinga2,cve-2026-61550,">
<rule id="100650" level="12">
<decoded_as>json</decoded_as>
<field name="program">icinga2</field>
<match>certificate update</match>
<description>CVE-2026-61550: Icinga 2 certificate update JSON-RPC message detected - possible unauthorized certificate replacement</description>
<mitre>
<id>T1190</id>
</mitre>
<group>attack,initial_access,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 3/4 (LIKELY — 2 independent sources confirm fix).
Immediate mitigations:
- Restrict network access to TCP port 5665 on all Icinga 2 nodes. Only trusted cluster peers (master, satellite, and agent nodes) should be able to reach this port. Apply firewall rules and network segmentation to enforce this.
- If the port must remain reachable internally, monitor for anomalous JSON-RPC certificate update messages and alert on any certificate replacement events not tied to a planned change.
- Audit existing node and CA certificates on all Icinga 2 nodes for unexpected changes or unknown CAs in the trust store.
Patch / upgrade steps:
- Upgrade Icinga 2 to version 2.14.9, 2.15.4, or 2.16.2 (or later) depending on the deployed major/minor branch. The fix validates that the sender of a certificate update JSON-RPC message is a trusted endpoint.
- After upgrading, restart the Icinga 2 service and verify cluster communication is functioning.
- Verify that node certificates and trusted CA certificates are the expected, legitimate values.
Long-term hardening:
- Implement mutual TLS with strict peer identity validation for all cluster communication.
- Enforce network segmentation so that monitoring cluster ports are not exposed to untrusted networks or the public internet.
- Maintain a patch management process that tracks Icinga 2 releases and applies security fixes promptly.
- Enable detailed audit logging for certificate lifecycle events and monitor for unexpected certificate changes.
- Conduct periodic reviews of PKI trust stores on monitoring nodes.
References
- NVD — CVE-2026-61550: https://nvd.nist.gov/vuln/detail/CVE-2026-61550
- Icinga 2 official release notes and security advisories: https://icinga.com/products/icinga-2/
- Debian Security Tracker — CVE-2026-61550: https://security-tracker.debian.org/tracker/CVE-2026-61550
- MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
- CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
No public proof-of-concept or exploit code is available. There is no evidence of active exploitation in the wild, and this CVE is not listed in CISA KEV as of the data provided.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.