CVE-2025-61907: 
Icinga vulnerability analysis and mitigation

CVE-2025-61907 is an information disclosure vulnerability in Icinga 2, an open-source monitoring system, where filter expressions supplied to /v1/objects API endpoints could access variables or objects that should be inaccessible to the requesting user. It affects Icinga 2 versions 2.4 through 2.15.0 and was disclosed on October 16, 2025. Fixed versions are 2.15.1, 2.14.7, and 2.13.13. The vulnerability carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is improper access control enforcement during filter expression evaluation in the Icinga 2 scripting engine (CWE-200, CWE-204, CWE-749). When authenticated API users submitted filter expressions to /v1/objects (and related endpoints such as /v1/actions), the expression evaluator did not enforce the variables permission for global variable access or the objects/query permission for object access. Additionally, functions such as get_objects(), get_template(), get_templates(), and getenv() were registered as "safe" functions usable in sandboxed filter contexts, allowing them to bypass permission checks. The fix introduces a ScriptPermissionChecker class that gates access to global variables and config objects within sandboxed script frames, and reclassifies the dangerous functions as non-safe so they cannot be invoked in API filter expressions (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated API user to read global variables (including sensitive values such as TicketSalt) and configuration objects that their assigned permissions explicitly prohibit. This is a confidentiality-only impact — integrity and availability are not affected. Exposure of sensitive global variables like TicketSalt could facilitate further attacks such as agent certificate forgery or privilege escalation within the Icinga ecosystem (GitHub Advisory).

Exploitation requires valid API credentials (low-privilege authenticated access) and network access to the Icinga 2 API, typically exposed on TCP port 5665. No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.034% (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The vulnerability was credited to researcher Al2Klimov (GitHub Advisory).

1. Reconnaissance: Identify Icinga 2 instances with the API enabled (default port 5665) using network scanning tools such as Nmap or Shodan, targeting versions 2.4 through 2.15.0.
2. Obtain API credentials: Acquire any valid Icinga 2 API user credentials — even a low-privilege account with limited objects/query or variables permissions is sufficient.
3. Craft a malicious filter expression: Construct an API request to a /v1/objects or /v1/actions endpoint that includes a filter expression referencing restricted global variables (e.g., TicketSalt) or calling functions like get_objects(), get_template(), get_templates(), or getenv() to enumerate objects outside the user's permitted scope.
4. Submit the request: Send the crafted HTTP request (e.g., via curl with client certificate or basic auth) to the Icinga 2 API.
5. Extract sensitive data: Parse the API response to retrieve the values of restricted global variables or details of configuration objects that the user's permissions should have hidden (GitHub Advisory, Patch Commit).

• Network: Unusual or repeated API requests to /v1/objects, /v1/actions, or /v1/variables endpoints from API users with limited permissions; requests containing filter parameters referencing TicketSalt, getenv, get_objects, get_template, or get_templates.
• Logs: Icinga 2 API access logs showing filter expressions with calls to get_objects(), get_template(), get_templates(), or getenv() from low-privilege API accounts; queries for object types or variables inconsistent with the user's assigned permissions.
• Behavioral: API users querying object types or global variables they have no legitimate operational need to access; unexpected enumeration of host, service, or configuration objects via the API.

Upgrade Icinga 2 to one of the patched versions: 2.15.1, 2.14.7, or 2.13.13. As a workaround, restrict API access to trusted users only, since the vulnerability can only be exploited by authenticated API users. Note that there is no practical configuration-level workaround that prevents exploitation without removing API access entirely, as any user with access to endpoints accepting filter expressions (including /v1/actions and /v1/objects) is potentially affected (GitHub Advisory).

Red Hat tracked the vulnerability and published a CVE entry, indicating relevance to downstream Linux distributions that package Icinga 2 (Red Hat CVE). Tenable added detection support via Nessus plugin 270720 (Tenable). A NetEye blog post addressed the security advisory in the context of their Icinga-based product (NetEye Blog). No significant social media controversy or broad community debate has been observed.