CVE-2025-61909: 
Icinga vulnerability analysis and mitigation

CVE-2025-61909 is a privilege misuse vulnerability in Icinga 2, an open-source monitoring system, where the safe-reload script and logrotate configuration send signals as the root user based on a PID file writable by the unprivileged Icinga daemon user. This design flaw allows the Icinga service account to send arbitrary signals to processes it would not normally be permitted to signal. Affected versions span from 2.10.0 up to (but not including) 2.13.13, 2.14.0 up to (but not including) 2.14.7, and 2.15.0. The vulnerability was disclosed on October 16, 2025, and carries a CVSS v3.1 base score of 4.4 (Medium) and a CVSS v4.0 base score of 4.0 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-250 (Execution with Unnecessary Privileges): the safe-reload script (invoked via systemctl reload icinga2) and the logrotate postrotate script both read a PID from /run/icinga2/icinga2.pid, a file owned and writable by the icinga daemon user, and then execute kill as root against that PID. Because the Icinga user controls the PID file, it can substitute an arbitrary PID — or replace the file with a symlink or named pipe — causing the root-level kill to send SIGHUP or SIGUSR1 to any process on the system. The attack requires local access and high privileges (control of the Icinga daemon account), and is considered a defense-in-depth issue that becomes exploitable if the Icinga service account is compromised (GitHub Advisory, GitHub Issue #10527).

Successful exploitation allows an attacker controlling the Icinga daemon user to send arbitrary Unix signals (e.g., SIGHUP, SIGUSR1) to any process running on the host, including privileged system processes. This can result in denial of service by terminating or disrupting critical services, or integrity violations by causing processes to reload with attacker-influenced state. There is no direct confidentiality impact, but the ability to signal arbitrary processes could be leveraged as part of a broader privilege escalation or system disruption chain (GitHub Advisory, GitHub Issue #10527).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The vulnerability requires the attacker to already control the Icinga daemon user account (high privileges required, local access only), making opportunistic exploitation unlikely. The EPSS score is approximately 0.013% (0.000130), reflecting very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Red Hat CVE).

1. Gain control of the Icinga daemon account: Obtain code execution or shell access as the icinga service user, for example by exploiting a separate vulnerability in Icinga 2 or a misconfigured service.
2. Identify the PID file location: Locate the writable PID file, typically at /run/icinga2/icinga2.pid, which is owned by the icinga user.
3. Identify a target process: Determine the PID of a privileged or critical system process (e.g., a database, SSH daemon, or init process) that should be disrupted or caused to reload.
4. Manipulate the PID file: Overwrite /run/icinga2/icinga2.pid with the target process's PID, or replace the file with a symlink pointing to a file containing the desired PID.
5. Trigger the safe-reload or logrotate action: Wait for or trigger a systemctl reload icinga2 or a logrotate event, causing the root-executed script to send SIGHUP or SIGUSR1 to the attacker-specified PID.
6. Achieve denial of service or integrity violation: The targeted process receives an unexpected signal as root, potentially causing it to terminate, reload, or behave unexpectedly (GitHub Advisory, GitHub Issue #10527).

• File System: Unexpected modification timestamp or content change on /run/icinga2/icinga2.pid; presence of a symlink at /run/icinga2/icinga2.pid pointing to an unusual location; named pipe at the PID file path.
• Logs: System logs (e.g., /var/log/syslog, journalctl) showing unexpected SIGHUP or SIGUSR1 signals received by non-Icinga processes; systemctl reload icinga2 events correlated with unexpected process restarts or crashes.
• Process: Unexpected termination or reload of system services (e.g., SSH, database daemons) coinciding with Icinga reload events; audit logs (auditd) showing the kill syscall issued by root targeting non-Icinga PIDs during reload operations.

Upgrade Icinga 2 to one of the patched versions: 2.15.1, 2.14.7, or 2.13.13. The fix replaces the root-executed kill binary calls with icinga2 internal signal, which drops privileges before sending the signal, preventing the Icinga user from influencing which process is signaled. For the logrotate fix specifically, administrators should check for .dpkg-dist or .rpmnew files next to /etc/logrotate.d/icinga2 after upgrading, as this config file may not be automatically updated if locally modified — manual incorporation of the fix is required in that case. As a temporary workaround without upgrading, the kill calls in the safe-reload script and logrotate configuration can be disabled (at the cost of reload/logrotate functionality) (GitHub Advisory, Icinga Blog).

The vulnerability was reported by security researcher mgerstner and addressed by Icinga maintainer julianbrost in the official GitHub security advisory. Icinga published a release announcement blog post covering the patched versions. NetEye also published a security advisory referencing the issue for their Icinga-based product. No significant broader media coverage or social media discussion has been observed beyond standard vulnerability tracking feeds (GitHub Advisory, Icinga Blog).