CVE-2026-24413: Icinga 2 Information Disclosure Flaw

CVE-2026-24413 Overview

CVE-2026-24413 is an Insecure Permissions vulnerability in Icinga 2, an open source monitoring system. The vulnerability exists in the MSI installer for Windows, which fails to set appropriate permissions for the %ProgramData%\icinga2\var folder. This misconfiguration allows all local users to read sensitive contents including private keys and synced configuration files, potentially compromising the security of the entire monitoring infrastructure.

Critical Impact

Local users can access private keys and configuration data, enabling potential credential theft, lateral movement, and compromise of monitored systems.

Affected Products

• Icinga 2 versions 2.3.0 through 2.13.13
• Icinga 2 versions 2.14.0 through 2.14.7
• Icinga 2 versions 2.15.0 through 2.15.1

Discovery Timeline

• 2026-01-29 - CVE CVE-2026-24413 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-24413

Vulnerability Analysis

This vulnerability (CWE-276: Incorrect Default Permissions) stems from improper Access Control List (ACL) configuration during Icinga 2 installation on Windows systems. When the Icinga 2 MSI installer creates the data directory at C:\ProgramData\icinga2\var, it does not restrict access permissions appropriately, leaving the folder and its contents readable by any authenticated local user.

The exposed data includes the Icinga agent's private cryptographic keys and synchronized configuration files. An attacker with local access to the system could leverage these credentials to impersonate the monitoring agent, intercept communications between monitored hosts and the Icinga master, or potentially gain access to other systems in the monitoring infrastructure.

Root Cause

The root cause is an oversight in the Icinga 2 MSI installer package that fails to apply restrictive ACLs to the %ProgramData%\icinga2\var directory structure. By default, Windows grants read access to this location for all authenticated users. The installer should have explicitly configured the folder to allow access only to the Icinga service account and local administrators.

Attack Vector

The attack requires local access to the Windows system where Icinga 2 is installed. An attacker with a standard user account can navigate to the C:\ProgramData\icinga2\var directory and read sensitive files including:

• Private cryptographic keys used for agent authentication
• Synced configuration containing monitoring rules and potentially sensitive endpoint information
• Certificate files stored in C:\Program Files\WindowsPowerShell\modules\icinga-powershell-framework\certificate (when using Icinga for Windows)

This information disclosure could enable further attacks such as man-in-the-middle attacks against the monitoring infrastructure or unauthorized access to monitored systems.

Detection Methods for CVE-2026-24413

Indicators of Compromise

• Unexpected access to C:\ProgramData\icinga2\var directory by non-administrative users
• File access events showing reads of private key files (.key, .crt) by unauthorized accounts
• Unusual certificate or key copying operations from the Icinga directories
• Authentication attempts using compromised Icinga agent credentials from unauthorized sources

Detection Strategies

• Enable Windows Security Auditing for file access on C:\ProgramData\icinga2\var and subfolders
• Monitor for Event ID 4663 (file access attempts) on sensitive Icinga directories
• Implement file integrity monitoring on Icinga certificate and key directories
• Review ACL configurations on Icinga data directories using PowerShell: Get-Acl 'C:\ProgramData\icinga2\var' | Format-List

Monitoring Recommendations

• Configure SIEM alerts for abnormal file access patterns to Icinga directories
• Establish baseline user access patterns and alert on deviations
• Monitor for certificate enrollment or key generation activities outside normal maintenance windows
• Track process execution that accesses Icinga private key files

How to Mitigate CVE-2026-24413

Immediate Actions Required

• Audit current ACL permissions on C:\ProgramData\icinga2\var to determine exposure
• Identify and rotate any potentially compromised private keys and certificates
• Review access logs for any unauthorized access to sensitive Icinga files
• Apply the appropriate patched version or workaround immediately

Patch Information

Icinga has released patched versions that address this vulnerability. Update to one of the following versions:

• Icinga 2 version 2.13.14 or later (for 2.13.x branch)
• Icinga 2 version 2.14.8 or later (for 2.14.x branch)
• Icinga 2 version 2.15.2 or later (for 2.15.x branch)

For Icinga for Windows users, the following versions automatically fix the ACLs:

• Icinga for Windows version 1.11.2 or later
• Icinga for Windows version 1.12.4 or later
• Icinga for Windows version 1.13.4 or later

See the Icinga Blog Release Notes and GitHub Security Advisory for complete details.

Workarounds

• Upgrade Icinga for Windows to version 1.13.4, 1.12.4, or 1.11.2 which automatically fixes the ACLs
• Manually update ACLs to restrict access to Icinga service user and administrators only
• Remove inherited permissions from the Icinga data directories
• Regularly audit and verify ACL configurations as part of security hardening

# Manual ACL remediation for Icinga 2 directories
# Remove inherited permissions and restrict to Icinga service account and administrators

$icingaPath = "C:\ProgramData\icinga2\var"
$acl = Get-Acl $icingaPath

# Disable inheritance and remove inherited rules
$acl.SetAccessRuleProtection($true, $false)

# Clear existing access rules
$acl.Access | ForEach-Object { $acl.RemoveAccessRule($_) }

# Add Administrator access
$adminRule = New-Object System.Security.AccessControl.FileSystemAccessRule("BUILTIN\Administrators","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($adminRule)

# Add SYSTEM access
$systemRule = New-Object System.Security.AccessControl.FileSystemAccessRule("NT AUTHORITY\SYSTEM","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($systemRule)

# Apply the modified ACL
Set-Acl -Path $icingaPath -AclObject $acl