☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2025-61909

CVE-2025-61909 Privilege Escalation in Icinga
📅 PUBLISHED: 2025-10-16 17:20 UTC 🔄 UPDATED: 2026-09-23 20:36 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.21%
👁️
0.21% probability
5.3× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
4.0
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-61909 is a privilege escalation vulnerability in Icinga 2, an open-source monitoring system. The flaw resides in the safe-reload script (used during systemctl reload icinga2) and the logrotate configuration. Both components read the PID of the main Icinga 2 process from a PID file that is writable by the daemon user (icinga). However, the signal (SIGHUP) is sent as the root user. This allows the Icinga user to manipulate the PID file and cause the root user to send arbitrary signals to any process, effectively enabling a local privilege escalation or denial of service.

The vulnerability affects versions from 2.10.0 up to, but not including, 2.13.13, 2.14.7, and 2.15.1. The CVSS score is 0.0 in the NVD data, but based on the technical details, a more accurate score would be 6.1 (Medium) with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

Icinga 2 is distributed via official package repositories (e.g., Debian, Ubuntu, EPEL) and as source code on GitHub. The vulnerability is introduced in the source code and affects all downstream packages. Organizations using Icinga 2 should verify their package versions and apply the patch from the official Icinga repository. The fix is included in versions 2.15.1, 2.14.7, and 2.13.13.

CVSS Breakdown & Threat Level

  • Attack Vector (AV): Local (L) – The attacker must have local access to the system as the icinga user.
  • Attack Complexity (AC): Low (L) – No special conditions are required; the attacker can simply write to the PID file.
  • Privileges Required (PR): Low (L) – The attacker needs the privileges of the icinga daemon user.
  • User Interaction (UI): None (N) – No user interaction is required.
  • Scope (S): Unchanged (U) – The vulnerability does not cross a trust boundary.
  • Confidentiality (C): None (N) – No data confidentiality impact.
  • Integrity (I): Low (L) – The attacker can cause a reload of a different process, but not arbitrary code execution.
  • Availability (A): High (H) – The attacker can send SIGKILL or other signals to critical system processes, causing a denial of service.

CVSS Score: 6.1 (Medium)

Threat Level: Medium. The vulnerability requires local access and low privileges, but can lead to denial of service or limited privilege escalation.

Deep Dive & Mechanics

The vulnerability is rooted in the design of the safe-reload script and the logrotate configuration. Both components perform the following sequence:

  1. Read the PID of the main Icinga 2 process from a file (typically /var/run/icinga2/icinga2.pid).
  2. Send a SIGHUP signal to that PID using kill as the root user.

The PID file is created by the Icinga 2 daemon, which runs as the icinga user. The file is owned by icinga:icinga and is writable by the daemon user. An attacker who has compromised the Icinga 2 daemon (or can otherwise write to the PID file) can modify the PID file to contain the PID of any other process on the system (e.g., PID 1, a critical service, or a process running as root). When the safe-reload script or logrotate runs (typically as root via cron or systemd), it reads the malicious PID and sends a SIGHUP to that process.

Attack Scenario:

  • The attacker gains access to the icinga user (e.g., via a web shell, compromised plugin, or other vulnerability).
  • The attacker writes a target PID (e.g., the PID of sshd or systemd) into the PID file.
  • The attacker triggers a reload (e.g., systemctl reload icinga2 or waits for logrotate to run).
  • The root user sends SIGHUP to the target process, causing a reload or termination.

Impact:

  • Denial of Service: Sending SIGHUP to critical system processes can cause them to reload configuration or terminate, leading to service disruption.
  • Privilege Escalation (Limited): While SIGHUP is not typically dangerous, the attacker could potentially send other signals (e.g., SIGTERM, SIGKILL) if the script is modified or if the attacker can influence the signal type. The primary risk is denial of service.

Vulnerable vs. Patched Code

Vulnerable Code (safe-reload script):

#!/bin/bash
# Vulnerable: reads PID from file writable by icinga user
PID=$(cat /var/run/icinga2/icinga2.pid)
kill -HUP $PID

Patched Code (safe-reload script):

#!/bin/bash
# Patched: uses systemd's kill command or checks PID ownership
# Option 1: Use systemctl kill
systemctl kill -s HUP icinga2
# Option 2: Verify PID ownership before sending signal
PID=$(cat /var/run/icinga2/icinga2.pid)
if [ -f /proc/$PID/status ] && grep -q "Name: icinga2" /proc/$PID/status; then
    kill -HUP $PID
else
    echo "Error: PID file does not point to a valid icinga2 process"
    exit 1
fi

Vulnerable Code (logrotate configuration):

/var/log/icinga2/*.log {
    daily
    rotate 7
    postrotate
        # Vulnerable: reads PID from file writable by icinga user
        PID=$(cat /var/run/icinga2/icinga2.pid)
        kill -HUP $PID
    endscript
}

Patched Code (logrotate configuration):

/var/log/icinga2/*.log {
    daily
    rotate 7
    postrotate
        # Patched: use systemctl kill
        /usr/bin/systemctl kill -s HUP icinga2
    endscript
}

Exploitation & Lab Setup

Red Team

Prerequisites:

  • Local access to a system running Icinga 2 (vulnerable version).
  • Ability to write to the PID file (e.g., as the icinga user).

Exploitation Steps:

  1. Identify the PID file location:

    cat /etc/icinga2/icinga2.conf | grep "PidFile"
    # Default: /var/run/icinga2/icinga2.pid
    
  2. Write a target PID to the file:

    # Example: target PID 1 (systemd)
    echo "1" > /var/run/icinga2/icinga2.pid
    
  3. Trigger the reload:

    # As root or via sudo (if the attacker has sudo privileges)
    systemctl reload icinga2
    # Or wait for logrotate to run
    
  4. Observe the effect: The root user sends SIGHUP to PID 1, causing systemd to reload its configuration (or potentially crash if the signal is mishandled).

Advanced Exploitation:

  • The attacker can target any process, including those running as root (e.g., sshd, cron, nginx).
  • By sending SIGHUP to a process that handles it poorly, the attacker can cause a denial of service.
  • If the attacker can also modify the signal type (e.g., by editing the script), they can send SIGKILL to terminate critical processes.

Blue Team

Detection Steps:

  1. Monitor PID file modifications:

    • Use auditd to watch for writes to the PID file:
      auditctl -w /var/run/icinga2/icinga2.pid -p wa -k icinga_pid
      
  2. Check for unexpected signals:

    • Monitor system logs for unusual SIGHUP signals:
      journalctl -u icinga2 | grep -i "HUP\|reload"
      
  3. Verify PID file integrity:

    • Regularly check that the PID in the file matches the actual Icinga 2 process:
      PID=$(cat /var/run/icinga2/icinga2.pid)
      if [ -f /proc/$PID/status ]; then
          grep -q "Name: icinga2" /proc/$PID/status || echo "ALERT: PID mismatch"
      fi
      
  4. Harden the system:

    • Apply the patch immediately.
    • If patching is not possible, change the PID file permissions to be read-only for the icinga user:
      chmod 444 /var/run/icinga2/icinga2.pid
      
    • Use systemd's built-in kill mechanism instead of the script.

Indicators of Compromise (IOCs)

  • File Modification: Unauthorized changes to /var/run/icinga2/icinga2.pid (e.g., PID pointing to a non-icinga2 process).
  • System Logs: Entries in /var/log/messages or journalctl showing SIGHUP sent to unexpected PIDs.
  • Process Anomalies: Unexpected reloads or terminations of critical system services (e.g., sshd, systemd).
  • Audit Logs: auditd alerts for writes to the PID file by the icinga user.

Detection Engineering

YARA Rule

rule CVE_2025_61909_Icinga_PID_Manipulation {
    meta:
        description = "Detects manipulation of Icinga 2 PID file for privilege escalation"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-61909"
        severity = "medium"
    strings:
        $pid_file = "/var/run/icinga2/icinga2.pid" nocase
        $kill_hup = "kill -HUP" nocase
        $kill_signal = "kill -" nocase
    condition:
        $pid_file and ($kill_hup or $kill_signal)
}

Sigma Rule

title: CVE-2025-61909 Icinga 2 PID File Manipulation
id: 8a9b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects attempts to manipulate the Icinga 2 PID file to send signals to arbitrary processes as root.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-61909
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/kill'
        CommandLine|contains: '-HUP'
        CommandLine|contains: '/var/run/icinga2/icinga2.pid'
    condition: selection
falsepositives:
    - Legitimate Icinga 2 reload operations (before patch)
level: medium

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-61909 Icinga 2 PID File Manipulation"; content:"/var/run/icinga2/icinga2.pid"; content:"kill -HUP"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Patch Icinga 2: Upgrade to version 2.15.1, 2.14.7, or 2.13.13 (or later).
  2. Workaround: If patching is not possible, modify the safe-reload script and logrotate configuration to use systemctl kill -s HUP icinga2 instead of reading the PID file.
  3. Restrict PID file permissions: Change the PID file to be read-only for the icinga user:
    chmod 444 /var/run/icinga2/icinga2.pid
    chown root:icinga /var/run/icinga2/icinga2.pid
    

Long-Term Mitigations:

  • Implement the principle of least privilege: Ensure the icinga user has no unnecessary capabilities.
  • Use systemd's built-in kill mechanism for all service management.
  • Regularly audit system configurations for similar PID file vulnerabilities.
  • Monitor for unusual signal sending patterns using the detection rules above.

Valters IT
Securing your infrastructure, one CVE at a time.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-61909/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.