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 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 Web 2 before 2.6.2 allows injection of PHP ini-file directives via vectors involving environment variables as the channel to send information to the attacker, such as a name=${PATH}${APACHERUNDIR}${APACHERUNUSER} parameter to /icingaweb2/navigation/add or /icingaweb2/dashboard/new-dashlet.

Icinga 2 v2.8.0 through v2.11.7 and v2.12.2 has an issue where revoked certificates due for renewal will automatically be renewed, ignoring the CRL. This issue is fixed in Icinga 2 v2.11.8 and v2.12.3.

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. 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.

Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions prior to 2.11.10 and from version 2.12.0 through version 2.12.4, some of the Icinga 2 features that require credentials for external services expose those credentials through the API to authenticated API users with read permissions for the corresponding object types. IdoMysqlConnection and IdoPgsqlConnection (every released version) exposes the password of the user used to connect to the database. IcingaDB (added in 2.12.0) exposes the password used to connect to the Redis server. ElasticsearchWriter (added in 2.8.0)exposes the password used to connect to the Elasticsearch server. An attacker who obtains these credentials can impersonate Icinga to these services and add, modify and delete information there. If credentials with more permissions are in use, this increases the impact accordingly. Starting with the 2.11.10 and 2.12.5 releases, these passwords are no longer exposed via the API. As a workaround, API user permissions can be restricted to not allow querying of any affected objects, either by explicitly listing only the required object types for object query permissions, or by applying a filter rule.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. Authenticated users, with access to the configuration, can create SSH resource files in unintended directories, leading to the execution of arbitrary code. This issue has been resolved in versions 2.8.6, 2.9.6 and 2.10 of Icinga Web 2. Users unable to upgrade should limit access to the Icinga Web 2 configuration.

icingaweb2-module-jira provides integration with Atlassian Jira. Starting in version 1.3.0 and prior to version 1.3.2, template and field configuration forms perform the deletion action before user input is validated, including the cross site request forgery token. This issue is fixed in version 1.3.2. There are no known workarounds.

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.

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 Icinga2 before v2.12.0-rc1. The prepare-dirs script (run as part of the icinga2 systemd service) executes chmod 2750 /run/icinga2/cmd. /run/icinga2 is under control of an unprivileged user by default. If /run/icinga2/cmd is a symlink, then it will by followed and arbitrary files can be changed to mode 2750 by the unprivileged icinga2 user.

Icinga Core through 1.14.0 initially executes bin/icinga as root but supports configuration options in which this file is owned by a non-root account (and similarly can have etc/icinga.cfg owned by a non-root account), which allows local users to gain privileges by leveraging access to this non-root account, a related issue to CVE-2017-14312. This also affects bin/icingastats, bin/ido2db, and bin/log2ido.

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).

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.

The database creation script (module/idoutils/db/scripts/createmysqldb.sh) in Icinga 1.7.1 grants access to all databases to the icinga user, which allows icinga users to access other databases via unspecified vectors.

It was reported [1] that Nagios Core's history.cgi is vulnerable to a buffer overflow because it used sprintf on user-supplied data that was not restricted in size.

Due to various protections of the operating system (history.cgi is compiled with SSP, FORTIFYSOURCE is enabled, etc.) this is not believed to be exploitable and would result in a denial of service to the user sending the input to history.cgi.

This has been fixed in svn (r2547)[2].

[1] http://archives.neohapsis.com/archives/fulldisclosure/2012-12/0108.html [2] http://nagios.svn.sourceforge.net/viewvc/nagios?view=revision&revision=2547

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.

Icinga Icinga Web2 2.0.0 through 2.6.4, 2.7.4 and 2.8.2 has a Directory Traversal vulnerability which allows an attacker to access arbitrary files that are readable by the process running Icinga Web 2. This issue is fixed in Icinga Web 2 in v2.6.4, v2.7.4 and v2.8.2.

Icinga Web 2 before 2.6.2 allows parameters that break navigation dashlets, as demonstrated by a single '$' character as the Name of a Navigation item.

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.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. Unauthenticated users can leak the contents of files of the local system accessible to the web-server user, including icingaweb2 configuration files with database credentials. This issue has been resolved in versions 2.9.6 and 2.10 of Icinga Web 2. Database credentials should be rotated.

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.

etc/initsystem/prepare-dirs in Icinga 2.x through 2.8.1 has a chown call for a filename in a user-writable directory, which allows local users to gain privileges by leveraging access to the $ICINGA2USER account for creation of a link.

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.

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.

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.