CVE-2025-61789

Executive Summary

CVE-2025-61789 is an information disclosure vulnerability in Icinga DB Web, a graphical interface for Icinga monitoring. An authenticated user with access to the web interface can exploit custom variable filters to guess values of protected or hidden variables. This is a low-severity issue (CVSS 5.3) that allows an attacker to enumerate sensitive configuration data, such as passwords or API keys, stored in custom variables. The vulnerability is patched in versions 1.1.4 and 1.2.3, which return an error when such a custom variable is used in a filter.

Supply Chain & Package Security

This vulnerability affects the Icinga DB Web package, which is distributed via GitHub and official Icinga repositories. No supply chain compromise has been reported. Users should verify package integrity via checksums provided by Icinga.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low (information disclosure)
• Integrity Impact: None
• Availability Impact: None

Threat Level: Low. The vulnerability requires authentication and only allows guessing of variable values, not direct reading.

Deep Dive & Mechanics

The vulnerability lies in the filter processing logic of Icinga DB Web. The application allows users to filter monitoring data using custom variables. Icinga DB Web has two mechanisms to protect sensitive variables:

• icingadb/protect/variables: Variables that are protected from being displayed.
• icingadb/denylist/variables: Variables that are hidden entirely.

However, before version 1.1.4 and 1.2.3, the filter engine did not properly validate whether a custom variable used in a filter was protected or hidden. An attacker could use a filter like vars.secret_key=* and observe the response. If the filter returns results, the attacker knows the variable exists and can guess its value by iterating through possible values (e.g., vars.secret_key=test123). The application would return different results based on whether the guessed value matches, enabling a blind enumeration attack.

The fix in versions 1.1.4 and 1.2.3 adds a check that returns an error if a custom variable used in a filter is in the protect or denylist.

Vulnerable vs. Patched Code

Vulnerable Code (before 1.1.4 / 1.2.3):

// In filter processing logic
$filter = new Filter($request->getQuery('filter'));
// No check for protected/denylist variables
$results = $this->query->filter($filter)->fetchAll();

Patched Code (1.1.4 / 1.2.3):

// In filter processing logic
$filter = new Filter($request->getQuery('filter'));
// Check for protected/denylist variables
foreach ($filter->getCustomVariables() as $var) {
    if (in_array($var, $this->protectedVariables) || in_array($var, $this->denylistVariables)) {
        throw new \InvalidArgumentException('Filtering by protected or denylist variable is not allowed.');
    }
}
$results = $this->query->filter($filter)->fetchAll();

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an Icinga DB Web instance (version < 1.1.4 or < 1.2.3)
• Valid user credentials with access to the web interface

Exploitation Steps:

1. Log in to Icinga DB Web.
2. Navigate to a view that supports custom variable filtering (e.g., host or service list).
3. Use the filter parameter to guess variable names and values. For example:
   • vars.secret_key=* to check if the variable exists.
   • vars.secret_key=test123 to guess a value.
4. Observe the response: if results are returned, the guess is correct; if no results, the guess is wrong.

Example HTTP Request:

GET /icingadb-web/hosts?filter=vars.secret_key=test123 HTTP/1.1
Host: target.example.com
Cookie: icingaweb2-session=...

Blue Team

Detection:

• Monitor for unusual filter parameters in Icinga DB Web requests, especially those containing vars. followed by sensitive-sounding names (e.g., password, secret, key).
• Look for repeated filter requests with different values (brute-force pattern).

Prevention:

• Upgrade to version 1.1.4 or 1.2.3 immediately.
• Restrict access to Icinga DB Web to trusted users only.
• Use network segmentation to limit exposure.

Indicators of Compromise (IOCs)

• Network: HTTP requests to Icinga DB Web with filter parameters containing vars. and repeated value guessing.
• Logs: Icinga DB Web access logs showing multiple filter requests with different values for the same variable.
• System: No file-based IOCs; this is a web application vulnerability.

Detection Engineering

YARA Rule

rule CVE_2025_61789_Icinga_DB_Web_Filter_Enumeration {
    meta:
        description = "Detects attempts to exploit CVE-2025-61789 by filtering on protected/denylist variables"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-61789"
    strings:
        $filter_param = /filter=vars\.\w+=/ nocase
        $error_response = "Filtering by protected or denylist variable is not allowed" nocase
    condition:
        $filter_param or $error_response
}

Sigma Rule

title: CVE-2025-61789 Icinga DB Web Variable Enumeration
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-61789 by filtering on protected/denylist variables
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-61789
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains: "filter=vars."
    condition: selection
falsepositives:
    - Legitimate use of custom variables that are not protected/denylisted
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-61789 Icinga DB Web Variable Enumeration Attempt"; flow:to_server; content:"filter=vars."; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade Icinga DB Web to version 1.1.4 or 1.2.3.
• If upgrade is not possible, restrict access to the web interface using firewall rules or VPN.

Long-term:

• Implement input validation for all filter parameters.
• Regularly review and update the list of protected/denylist variables.
• Conduct security audits of web application code.

Workaround:

• Remove sensitive data from custom variables and use alternative secure storage.

Valters IT
DevSecOps & Cyber Threat Intelligence