CVE-2021-32743 in Icinga
Summary
by MITRE • 07/15/2021
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2025
The vulnerability described in CVE-2021-32743 represents a critical information disclosure flaw within the Icinga monitoring system that affects multiple versions of the software. This issue stems from improper handling of authentication credentials within the Icinga 2 API interface, where sensitive password information is inadvertently exposed to authenticated users with read permissions. The vulnerability specifically impacts Icinga 2 versions prior to 2.11.10 and from version 2.12.0 through 2.12.4, creating a significant security risk for organizations relying on this monitoring infrastructure. The flaw manifests through several distinct components including IdoMysqlConnection, IdoPgsqlConnection, IcingaDB, and ElasticsearchWriter, each of which stores database connection credentials in a manner that bypasses proper access controls.
The technical implementation of this vulnerability involves the exposure of database connection passwords through the Icinga 2 API endpoints that handle configuration objects for various backend services. According to CWE-200, this represents an information disclosure vulnerability where sensitive data is made available to unauthorized parties through improper access control mechanisms. The IdoMysqlConnection and IdoPgsqlConnection components, which have been present in every released version of Icinga 2, store the database user passwords in plaintext within the configuration objects that are accessible via the API. Similarly, the IcingaDB feature introduced in version 2.12.0 exposes Redis server passwords, while ElasticsearchWriter component from version 2.8.0 makes Elasticsearch server credentials available. These credentials are accessible to any authenticated API user who possesses read permissions for the corresponding object types, effectively creating a privilege escalation vector.
The operational impact of this vulnerability extends beyond simple credential exposure, as it enables attackers with minimal privileges to gain unauthorized access to critical backend systems. When attackers obtain these credentials, they can impersonate the Icinga monitoring system to external services, allowing them to add, modify, or delete information within those systems. This capability directly maps to ATT&CK technique T1078.004, which covers valid accounts used for lateral movement, as the exposed credentials can be leveraged for unauthorized access to database and caching systems. The severity of the impact increases significantly when these credentials are associated with accounts possessing elevated permissions, potentially allowing for complete compromise of the monitored infrastructure. Organizations may face data integrity issues, unauthorized modifications to monitoring configurations, and potential data exfiltration through the compromised backend services.
The vulnerability was addressed in Icinga 2 releases 2.11.10 and 2.12.5, where the password exposure mechanism was removed from the API responses. This fix aligns with security best practices for credential management and access control, ensuring that sensitive authentication information is no longer accessible through the monitoring system's API interface. Organizations can implement several mitigations to address this vulnerability in affected versions, including restricting API user permissions to prevent querying of the affected object types. This can be accomplished through explicit permission lists that only grant access to required object types or by implementing filter rules that limit access to sensitive configuration data. Additionally, administrators should conduct thorough audits of API user permissions and ensure that least privilege principles are applied to minimize the risk of credential exposure. The vulnerability demonstrates the importance of proper API design and access control implementation, particularly when dealing with sensitive configuration data that may contain authentication credentials for external systems.