Today, we are releasing security updates for Icinga 2 and Icinga DB Web fixing multiple security issues.
Two of them allow authenticated API users to learn restricted information or crash Icinga 2. On Icinga 2, a third issue affecting the provided scripts allows a limited privilege escalation where the Icinga 2 daemon user can trick root into sending signals to arbitrary processes.
In a similar way to Icinga 2, Icinga DB Web also allowed restricted user accounts to guess internal variables using filters.
Icinga 2
In addition to the security fixes described below, version v2.15.1 also includes bug fixes regarding config deployments and improvements to allow for better debugging of problems related to JSON-RPC cluster communication. For these additional changes, see the release page on Github.
- CVE-2025-61907
- Authenticated, but unprivileged API users were able to access variables and objects inside filter expressions of any API endpoint, even if they don’t have the permissions to access these objects/variables. This allowed authenticated API users to learn information they aren’t allowed to access directly, for example custom variables on hosts or services.
This also extends to the TicketSalt variable, which when leaked could be used by the attacker to add additional Icinga 2 nodes to the cluster. On 2.13.13 additionally includes a back-port of the restriction to not allow access to this variable via the /v1/variables API endpoint, which was added in 2.14.
- CVE-2025-61908
- An authenticated API user could crash the Icinga 2 daemon by supplying a crafted filter expression that dereferences a null pointer. The fix is to check for the null pointer and return an error status code via the API response.
- CVE-2025-61909
- Allowed a limited privilege escalation from the Icinga 2 service user to root. The scope is limited to sending SIGHUP or SIGUSR1 to an arbitrary process.
All three versions include a fix to the logrotate configuration in
/etc/logrotate.d/icinga2. As this file is tracked as a configuration file by package managers, it may not be updated automatically if it was modified locally. After upgrading, make sure to check if there are any files with an extension like.dpkg-distor.rpmnewnext to it. If so, you need to incorporate the changes into your configuration manually.To verify that the fix was applied correctly, check the contents of
/etc/logrotate.d/icinga2: If the file uses the command"$DAEMON" internal signal --sig SIGHUP --pid "$pid"(instead ofkill -HUP "$pid"), it was upgraded correctly.
Patches
The issues were addressed in the following versions:
The source code for the new versions can be found in the Icinga 2 Git repository. Updated binary packages are available on packages.icinga.com and the Icinga for Windows repository. Updated container images are available on Docker Hub.
Users relying on restricted access for unprivileged API users are advised to update immediately.
Icinga DB Web
- CVE-2025-61789
- An authorized user with access to Icinga DB Web could use a custom variable in a filter that is either protected by
icingadb/protect/variablesor hidden byicingadb/denylist/variables, to guess values assigned to it.
Patches
The issue was addressed in the following versions:
The source code for the new versions can be found in the Icinga DB Web Git repository. Updated binary packages are available on packages.icinga.com.
Users relying on restricting access to the icingadb module with the permissions described above are advised to upgrade immediately.
Acknowledgements
We would like to thank and for finding and reporting two of these issues.
References
For more information
If you have any questions or comments about this advisory, please ask in our community forum or email us at info@icinga.com.
For reporting possible security issues, please see the information on our website.
