Icinga 2 CVE-2025-61909

Requires the attacker to already have control of the unprivileged 'icinga' daemon user (PR:H) on the host so it can write to the daemon-owned PID file (icinga2.pid in the init run directory). Exploitation is only triggered when a root context consumes that PID file - i.e. during 'systemctl reload icinga2'/the shipped safe-reload script or during a logrotate run of the Icinga 2 logs (AT:P: an attacker must plant the PID and then wait for this root-run event). Limiting factors: strictly local (AV:L), needs prior compromise of the service account, no code execution or data disclosure, and impact is confined to delivering a root-privileged signal to an attacker-chosen process. Affects Icinga 2 from 2.10.0 up to the fixed 2.15.1/2.14.7/2.13.13.

This is a genuinely low-priority, low-real-world-risk issue despite being a privilege/signal-handling flaw. The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:H/UI:N) confirms the attacker must already be local AND already hold high privileges - specifically control of the 'icinga' daemon user that owns the writable PID file - and must satisfy an attack requirement (AT:P), namely waiting for a root-triggered 'systemctl reload icinga2'/safe-reload or logrotate run. The only impact is SA:H (availability of subsequent/other-system processes via signal delivery); VC/VI/VA are all N, so there is no confidentiality or integrity impact and no code execution. The EPSS score (0.22%, 11th percentile) is correspondingly low and consistent with the high prerequisites. There is no CISA KEV listing and no public exploit identified - the only 'source code evidence' provided is the vendor patch commit, NOT a proof-of-concept exploit, so POC availability should be treated as unknown/none. No signals conflict: CVSS, EPSS, and the absence of KEV all agree this is a contained local escalation requiring an already-compromised service account, not a widespread remote threat.

An attacker who has already compromised the unprivileged 'icinga' daemon account (e.g. via a separate RCE in the monitoring stack) writes the PID of an arbitrary system process into the daemon-writable icinga2.pid file. When a root-run reload (safe-reload / systemctl reload icinga2) or logrotate cycle fires, root reads that attacker-controlled PID and sends a signal (SIGHUP/SIGUSR1) to the chosen process, letting the icinga user affect processes it could not otherwise signal. No public exploit code has been identified; only the vendor fix commit is available.