Latest version: 2.14.0

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. A vulnerability in versions prior to 2.11.5 and 2.12.13 vulnerability allows an attacker to craft a URL that, once visited by an authenticated user (or one that is able to authenticate), allows to manipulate the backend to redirect the user to any location. This issue has been resolved in versions 2.11.5 and 2.12.3 of Icinga Web 2. No known workarounds are available.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. A vulnerability in versions prior to 2.11.5 and 2.12.13 allows an attacker to craft a request that, once transmitted to a victim's Icinga Web, allows to embed arbitrary Javascript into it and to act on behalf of that user. This issue has been resolved in versions 2.11.5 and 2.12.3 of Icinga Web 2. As a workaround, those who have Icinga Web 2.12.2 may enable a content security policy in the application settings. Any modern browser with a working CORS implementation also sufficiently guards against the vulnerability.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. A vulnerability in versions prior to 2.11.5 and 2.12.13 allows an attacker to craft a URL that, once visited by any user, allows to embed arbitrary Javascript into Icinga Web and to act on behalf of that user. This issue has been resolved in versions 2.11.5 and 2.12.3 of Icinga Web 2. As a workaround, those who have Icinga Web 2.12.2 may enable a content security policy in the application settings.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. A vulnerability in versions prior to 2.11.5 and 2.12.13 allows an attacker to craft a URL that, once visited by any user, allows to embed arbitrary Javascript into Icinga Web and to act on behalf of that user. This issue has been resolved in versions 2.11.5 and 2.12.3 of Icinga Web 2. As a workaround, those who have Icinga Web 2.12.2 may enable a content security policy in the application settings.

Icinga Reporting is the central component for reporting related functionality in the monitoring web frontend and framework Icinga Web 2. A vulnerability present in versions 0.10.0 through 1.0.2 allows to set up a template that allows to embed arbitrary Javascript. This enables the attacker to act on behalf of the user, if the template is being previewed; and act on behalf of the headless browser, if a report using the template is printed to PDF. This issue has been resolved in version 1.0.3 of Icinga Reporting. As a workaround, review all templates and remove suspicious settings.

Icinga Director is a tool designed to make Icinga 2 configuration handling easy. Not any of Icinga Director's configuration forms used to manipulate the monitoring environment are protected against cross site request forgery (CSRF). It enables attackers to perform changes in the monitoring environment managed by Icinga Director without the awareness of the victim. Users of the map module in version 1.x, should immediately upgrade to v2.0. The mentioned XSS vulnerabilities in Icinga Web are already fixed as well and upgrades to the most recent release of the 2.9, 2.10 or 2.11 branch must be performed if not done yet. Any later major release is also suitable. Icinga Director will receive minor updates to the 1.8, 1.9, 1.10 and 1.11 branches to remedy this issue. Upgrade immediately to a patched release. If that is not feasible, disable the director module for the time being.

icingaweb2-module-incubator is a working project of bleeding edge Icinga Web 2 libraries. In affected versions the class gipfl\Web\Form is the base for various concrete form implementations [1] and provides protection against cross site request forgery (CSRF) by default. This is done by automatically adding an element with a CSRF token to any form, unless explicitly disabled, but even if enabled, the CSRF token (sent during a client's submission of a form relying on it) is not validated. This enables attackers to perform changes on behalf of a user which, unknowingly, interacts with a prepared link or website. The version 0.22.0 is available to remedy this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions 2.5.0 through 2.13.0, ElasticsearchWriter, GelfWriter, InfluxdbWriter and Influxdb2Writer do not verify the server's certificate despite a certificate authority being specified. Icinga 2 instances which connect to any of the mentioned time series databases (TSDBs) using TLS over a spoofable infrastructure should immediately upgrade to version 2.13.1, 2.12.6, or 2.11.11 to patch the issue. Such instances should also change the credentials (if any) used by the TSDB writer feature to authenticate against the TSDB. There are no workarounds aside from upgrading.

An issue was discovered in Icinga 2.x through 2.8.1. The lack of a constant-time password comparison function can disclose the password to an attacker.

An issue was discovered in Icinga 2.x through 2.8.1. The daemon creates an icinga2.pid file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for icinga2.pid modification before a root script executes a "kill cat /pathname/icinga2.pid" command, as demonstrated by icinga2.init.d.cmake.

An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted messages, an attacker can cause a NULL pointer dereference, which can cause the product to crash.

An issue was discovered in Icinga 2.x through 2.8.1. By editing the init.conf file, Icinga 2 can be run as root. Following this the program can be used to run arbitrary code as root. This was fixed by no longer using init.conf to determine account information for any root-executed code (a larger issue than CVE-2017-16933).

An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted (authenticated and unauthenticated) requests, an attacker can exhaust a lot of memory on the server side, triggering the OOM killer.

Multiple off-by-one errors in Icinga, possibly 1.10.2 and earlier, allow remote attackers to cause a denial of service (crash) via unspecified vectors to the (1) displaynavtable, (2) printexportlink, (3) pagenumselector, or (4) pagelimitselector function in cgi/cgiutils.c or (5) statuspagenumselector function in cgi/status.c, which triggers a stack-based buffer overflow.

A potential buffer overflow vulnerability was reported in Icinga [1],[2] which could possibly be exploited by remote attackers to cause a denial of service. This vulnerability is caused due to a boundary error in the cmdsubmitf() function. This code in Icinga originated in Nagios, and a visual inspection of the code indicates Nagios is likewise affected.

CVE-2014-1878 was assigned to Icinga, however given that the code is identical and has the same origin (Nagios is the originator) the same CVE should also apply to Nagios.

This is fixed in Icinga git [3].

[1] https://www.icinga.org/2014/02/11/bugfix-releases-1-10-3-1-9-5-1-8-6/ [2] https://dev.icinga.org/issues/5434 [3] https://dev.icinga.org/projects/icinga-core/repository/revisions/eedf4f7d88cdc50843572224eb38a2f5c78a2dc5

Multiple off-by-one errors in Nagios Core 3.5.1, 4.0.2, and earlier, and Icinga before 1.8.5, 1.9 before 1.9.4, and 1.10 before 1.10.2 allow remote authenticated users to obtain sensitive information from process memory or cause a denial of service (crash) via a long string in the last key value in the variable list to the processcgivars function in (1) avail.c, (2) cmd.c, (3) config.c, (4) extinfo.c, (5) histogram.c, (6) notifications.c, (7) outages.c, (8) status.c, (9) statusmap.c, (10) summary.c, and (11) trends.c in cgi/, which triggers a heap-based buffer over-read.

Cross-site request forgery (CSRF) vulnerability in cmd.cgi in Icinga 1.8.5, 1.9.4, 1.10.2, and earlier allows remote attackers to hijack the authentication of users for unspecified commands via unspecified vectors, as demonstrated by bypassing authentication requirements for CVE-2013-7106.

Multiple stack-based buffer overflows in Icinga before 1.8.5, 1.9 before 1.9.4, and 1.10 before 1.10.2 allow remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a long string to the (1) displaynavtable, (2) pagelimitselector, (3) printexportlink, or (4) pagenumselector function in cgi/cgiutils.c; (5) statuspagenumselector function in cgi/status.c; or (6) displaycommandexpansion function in cgi/config.c. NOTE: this can be exploited without authentication by leveraging CVE-2013-7107.

End of support: 7/3/2026, Latest version: 2.13.1

The Icinga PowerShell Framework provides configuration and check possibilities to ensure integration and monitoring of Windows environments. In versions prior to 1.13.4, 1.12.4, and 1.11.2, permissions of the Icinga for Windows certificate directory grant every user read access, which results in the exposure of private key of the Icinga certificate for the given host. All installations are affected. Versions 1.13.4, 1.12.4, and 1.11.2 contains a patch. Please note that upgrading to a fixed version of Icinga for Windows will also automatically fix a similar issue present in Icinga 2, CVE-2026-24413. As a workaround, the permissions can be restricted manually by updating the ACL for the given folder C:\Program Files\WindowsPowerShell\modules\icinga-powershell-framework\certificate (and C:\ProgramData\icinga2\var to fix the issue for the Icinga 2 agent as well) including every sub-folder and item to restrict access for general users, only allowing the Icinga service user and administrators access.

Icinga 2 is an open source monitoring system. Starting in version 2.3.0 and prior to versions 2.13.14, 2.14.8, and 2.15.2, the Icinga 2 MSI did not set appropriate permissions for the %ProgramData%\icinga2\var folder on Windows. This resulted in the its contents - including the private key of the user and synced configuration - being readable by all local users. All installations on Windows are affected. Versions 2.13.14, 2.14.8, and 2.15.2 contains a fix. There are two possibilities to work around the issue without upgrading Icinga 2. Upgrade Icinga for Windows to at least version v1.13.4, v1.12.4, or v1.11.2. These version will automatically fix the ACLs for the Icinga 2 agent as well. Alternatively, manually update the ACL for the given folder C:\ProgramData\icinga2\var (and C:\Program Files\WindowsPowerShell\modules\icinga-powershell-framework\certificate to fix the issue for the Icinga for Windows as well) including every sub-folder and item to restrict access for general users, only allowing the Icinga service user and administrators access.

Icinga Director is an Icinga config deployment tool. A Security vulnerability has been found starting in version 1.0.0 and prior to 1.10.4 and 1.11.4 on several director endpoints of REST API. To reproduce this vulnerability an authenticated user with permission to access the Director is required (plus api access with regard to the api endpoints). And even though some of these Icinga Director users are restricted from accessing certain objects, are able to retrieve information related to them if their name is known. This makes it possible to change the configuration of these objects by those Icinga Director users restricted from accessing them. This results in further exploitation, data breaches and sensitive information disclosure. Affected endpoints include icingaweb2/director/service, if the host name is left out of the query; icingaweb2/directore/notification; icingaweb2/director/serviceset; and icingaweb2/director/scheduled-downtime. In addition, the endpoint icingaweb2/director/services?host=filteredHostName returns a status code 200 even though the services for the host is filtered. This in turn lets the restricted user know that the host filteredHostName exists even though the user is restricted from accessing it. This could again result in further exploitation of this information and data breaches. Icinga Director has patches in versions 1.10.4 and 1.11.4. If upgrading is not feasible, disable the director module for the users other than admin role for the time being.

Icinga DB Web provides a graphical interface for Icinga monitoring. Starting in version 1.2.0 and prior to version 1.2.2, users with access to Icinga Dependency Views, are allowed to see hosts and services that they weren't meant to on the dependency map. However, the name of an object will not be revealed nor does this grant access to a host's or service's detail view. Please note that this only affects the restrictions filter/hosts and filter/services. filter/objects is not affected by this and restricts objects as it is supposed to. Version 1.2.2 applies these restrictions properly. As a workaround, one may downgrade to version 1.1.3.

Icinga DB Web provides a graphical interface for Icinga monitoring. Before 1.1.4 and 1.2.3, an authorized user with access to Icinga DB Web, can use a custom variable in a filter that is either protected by icingadb/protect/variables or hidden by icingadb/denylist/variables, to guess values assigned to it. Versions 1.1.4 and 1.2.3 respond with an error if such a custom variable is used.

Icinga 2 is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Prior to versions 2.12.12, 2.13.12, and 2.14.6, the VerifyCertificate() function can be tricked into incorrectly treating certificates as valid. This allows an attacker to send a malicious certificate request that is then treated as a renewal of an already existing certificate, resulting in the attacker obtaining a valid certificate that can be used to impersonate trusted nodes. This only occurs when Icinga 2 is built with OpenSSL older than version 1.1.0. This issue has been patched in versions 2.12.12, 2.13.12, and 2.14.6.

Icinga 2 is an open source monitoring system. In Icinga 2 versions 2.4 through 2.15.0, filter expressions provided to the various /v1/objects endpoints could access variables or objects that would otherwise be inaccessible for the user. This allows authenticated API users to learn information that should be hidden from them, including global variables not permitted by the variables permission and objects not permitted by the corresponding objects/query permissions. The vulnerability is fixed in versions 2.15.1, 2.14.7, and 2.13.13.

Icinga 2 is an open source monitoring system. From 2.10.0 to before 2.15.1, 2.14.7, and 2.13.13, when creating an invalid reference, such as a reference to null, dereferencing results in a segmentation fault. This can be used by any API user with access to an API endpoint that allows specifying a filter expression to crash the Icinga 2 daemon. A fix is included in the following Icinga 2 versions: 2.15.1, 2.14.7, and 2.13.13.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. The TLS certificate validation in all Icinga 2 versions starting from 2.4.0 was flawed, allowing an attacker to impersonate both trusted cluster nodes as well as any API users that use TLS client certificates for authentication (ApiUser objects with the clientcn attribute set). This vulnerability has been fixed in v2.14.3, v2.13.10, v2.12.11, and v2.11.12.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. From version 2.4.0 through version 2.12.4, a vulnerability exists that may allow privilege escalation for authenticated API users. With a read-ony user's credentials, an attacker can view most attributes of all config objects including ticketsalt of ApiListener. This salt is enough to compute a ticket for every possible common name (CN). A ticket, the master node's certificate, and a self-signed certificate are enough to successfully request the desired certificate from Icinga. That certificate may in turn be used to steal an endpoint or API user's identity. Versions 2.12.5 and 2.11.10 both contain a fix the vulnerability. As a workaround, one may either specify queryable types explicitly or filter out ApiListener objects.