CVE-2026-61552: 
Icinga vulnerability analysis and mitigation

CVE-2026-61552 is a DSL code injection vulnerability in Icinga 2, an open-source monitoring system, caused by unescaped import template names written to generated configuration files via the /v1/objects API. An authenticated API user with objects/create/* permissions can inject arbitrary Icinga 2 DSL configuration, escape the intended object scope, and escalate privileges beyond their assigned role. The vulnerability affects Icinga 2 versions from 2.4 up to (but not including) 2.14.9, 2.15.4, and 2.16.2. It was disclosed on June 29, 2026, and assigned a CVSS v3.1 base score of 7.2 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-94 (Improper Control of Generation of Code / Code Injection). In the ConfigWriter::EmitScope function (lib/base/configwriter.cpp), template names supplied via the /v1/objects API were written directly into generated Icinga 2 DSL configuration files using string concatenation (fp << "import \"" << import << "\""), without any escaping. An attacker can embed a double-quote character (") in a template name to break out of the string literal context in the generated config file, then inject additional arbitrary DSL statements — such as creating new objects or modifying existing ones — that are subsequently parsed and executed by the Icinga 2 daemon. The fix, applied in PR #10910, replaces the raw string output with a call to EmitString(), which properly escapes user-supplied input (GitHub PR, Commit).

Successful exploitation allows an authenticated API user to escalate privileges beyond their assigned objects/create/* scope by injecting arbitrary Icinga 2 DSL configuration. This can result in the creation of unauthorized monitoring objects, modification of existing configuration, and potential full compromise of the Icinga 2 monitoring infrastructure — impacting confidentiality, integrity, and availability of the monitoring system and any data it processes. Because Icinga 2 typically has broad network visibility and may store credentials for monitored hosts, a compromised instance could facilitate lateral movement within the monitored environment (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of disclosure. The vulnerability requires authentication as an API user with objects/create/* permissions, which limits the attack surface to users who have already been granted API access. The EPSS score is approximately 0.62%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and NVD's SSVC assessment classifies exploitation as "none" (Feedly, GitHub Advisory).

1. Reconnaissance: Identify an Icinga 2 instance running a vulnerable version (2.4–2.14.8, 2.15.0–2.15.3, or 2.16.0–2.16.1) with the REST API exposed (default port 5665).
2. Obtain API credentials: Acquire credentials for an ApiUser account that has been granted any objects/create/* permission (e.g., objects/create/Host).
3. Craft malicious template name: Construct a template name containing a double-quote character to break out of the DSL string context, followed by injected DSL statements. For example, a template name like legit"; object NotificationCommand "injected" { command = [ "/bin/bash", "-c", "malicious_command" ] }; import " would inject an additional DSL object.
4. Send API request: Submit a PUT or POST request to the /v1/objects/<type>/<name> endpoint with the crafted template name in the templates array of the JSON body.
5. Trigger config reload: The injected DSL is written to the generated configuration file. Upon the next Icinga 2 configuration reload (which may occur automatically or be triggered via the API), the injected objects are parsed and activated, achieving privilege escalation or arbitrary configuration execution (GitHub Advisory, GitHub PR).

• Network: Unexpected or anomalous PUT/POST requests to /v1/objects/ endpoints on Icinga 2 API port (default 5665) containing template names with special characters (e.g., ", \n, ;) in the templates JSON field.
• File System: Icinga 2 generated configuration files (typically under /var/lib/icinga2/api/) containing unexpected DSL objects, import statements with unusual names, or configuration blocks not matching legitimate API requests.
• Logs: Icinga 2 API access logs showing requests to /v1/objects/ with unusual or malformed template name values; Icinga 2 daemon logs showing unexpected object creation or configuration parse errors following an API call.
• Process/Config: Presence of unexpected monitoring objects (e.g., NotificationCommand, EventCommand) in the running Icinga 2 configuration that were not created through normal administrative channels (GitHub Advisory).

Icinga has released patched versions 2.14.9, 2.15.4, and 2.16.2, all of which include the fix for this vulnerability. Upgrading to one of these versions is the recommended remediation. As a temporary workaround, administrators can remove objects/create/* permissions from all API users until the upgrade can be applied, as the vulnerability is only exploitable by users holding such permissions (GitHub Advisory, Icinga Blog).

The vulnerability was independently reported by security researchers @TristanInSec and @de3erve-hunter while the Icinga team was already preparing a fix, indicating parallel discovery. Coverage appeared in Linux security news outlets and aggregators such as Pro-Linux.de and AusCERT shortly after disclosure. A Mastodon post by @hugovalters noted the release. No major vendor statements beyond Icinga's own release announcement have been identified (GitHub Advisory).