CVE-2026-61552 in Icinga
Summary
by MITRE • 09/18/2026
Icinga 2 is an open source monitoring system. From 2.4 until 2.14.9, 2.15.4, and 2.16.2, the /v1/objects API writes attacker-controlled template names into generated configuration without escaping them. An authenticated ApiUser with an objects/create/* permission can inject Icinga 2 DSL configuration, escape the intended object, create additional objects, and exceed the user's assigned privileges. This issue is fixed in versions 2.14.9, 2.15.4, and 2.16.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within Icinga 2 affects monitoring systems running version ranges from 2.4 through specific patched releases including 2.14.9, 2.15.4, and 2.16.2. This security flaw resides in the /v1/objects API endpoint, which is responsible for handling object creation requests within the Icinga configuration framework. The core technical deficiency involves a failure to properly sanitize or escape user-supplied input when it is incorporated into generated configuration files. Specifically, template names provided by an authenticated ApiUser are written directly into the DSL (Domain Specific Language) configuration without adequate escaping mechanisms. This lack of sanitization allows for code injection attacks where malicious actors can manipulate the structure and content of the resulting configuration file.
From a technical perspective, this flaw constitutes a classic case of insecure direct object reference combined with command or script injection vulnerabilities within a configuration generation context. The vulnerability is categorized under CWE-94 as Improper Control of Generation of Code or Script, specifically code injection via unsanitized input in dynamic contexts. Furthermore, because the attack requires an authenticated ApiUser possessing objects/create permissions to execute, it aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, where an adversary uses legitimate system tools or interfaces to execute arbitrary commands. The absence of proper escaping means that special characters in the template name can break out of their intended string context, allowing the attacker to inject additional DSL statements into the configuration file.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and unauthorized object creation. An authenticated user with limited permissions designed only to create specific monitoring objects can exploit this flaw to escape the constraints imposed by their assigned role. By injecting carefully crafted template names, an attacker can generate arbitrary Icinga 2 configuration entries that were not intended or permitted under their access level. This capability enables the creation of additional objects such as hosts, services, or notifications outside of authorized boundaries. In practical terms, this could allow a low-privileged user to monitor unauthorized systems, alter alerting thresholds for critical infrastructure, or potentially leverage subsequent vulnerabilities in Icinga plugins or external command execution features to achieve remote code execution on the monitoring server itself.
Mitigation strategies primarily involve upgrading the Icinga 2 installation to one of the fixed versions: 2.14.9, 2.15.4, or 2.16.2 and later. These releases include patches that implement proper escaping for template names within the /v1/objects API response generation logic. For organizations unable to immediately patch their systems due to operational constraints, temporary mitigations should focus on strict access control policies applied to the ApiUser accounts. Administrators must ensure that only highly trusted personnel are granted objects/create permissions and that these credentials are protected with strong authentication mechanisms such as two-factor authentication or certificate-based mutual TLS. Additionally, implementing network-level restrictions to limit API endpoint accessibility to known management subnets can reduce the attack surface available to potential adversaries attempting to exploit this injection vector.