Urgent: Stored XSS in “Multi Post Carousel by Category” (<= 1.4) — What WordPress Site Owners Must Do Now

By a Hong Kong security specialist — published 2026-03-23

A recently disclosed vulnerability in the WordPress plugin “Multi Post Carousel by Category” (versions ≤ 1.4) permits an authenticated contributor-level user to store cross-site scripting (XSS) payloads via the plugin’s “slides” shortcode attribute. This is a stored XSS that requires an authenticated contributor account to inject payloads and certain viewing actions to trigger execution.

From the perspective of an operational security practitioner in Hong Kong, treat this as operationally urgent. Although exploitation requires contributor access, stored XSS can yield high-impact outcomes: session theft, admin takeover, content poisoning, SEO damage and persistent backdoors. The guidance below is practical, prioritised, and suitable for immediate application.

Contents

• What the vulnerability is (plain language)
• How an attacker could exploit it — realistic attack scenarios
• Immediate actions (0–24 hours)
• Temporary code mitigations you can apply now
• Database and detection steps to find injected content
• WAF/virtual patch rules and recommendations
• Recovery and post-incident hardening
• Appendix: quick commands, SQL & WP-CLI queries

What this vulnerability is (plain language)

This is a stored (persistent) Cross‑Site Scripting (XSS) vulnerability arising from insufficient sanitization of user-supplied data used in a shortcode attribute named “slides”. An attacker with Contributor role can craft content that contains the vulnerable shortcode and a malicious payload in the slides attribute. When that shortcode is rendered, the malicious JavaScript executes in the browser context of viewers — including administrators.

• Vulnerable software: Multi Post Carousel by Category plugin (≤ 1.4).
• Vulnerability type: Stored Cross‑Site Scripting (XSS).
• Privilege required: Contributor (or higher) authenticated user.
• Impact: session theft, unauthorized actions under an admin session, content injection, redirects, SEO spam, or persistent backdoors.
• Trigger: viewing a page or preview where the injected shortcode is rendered.

Stored XSS persists in DB content until removed — detection, removal and controls are all required.

How an attacker could realistically exploit this (threat scenarios)

Understanding likely attack chains helps prioritise response.

1. Contributor-to-admin escalation via post preview
   • Attacker obtains a contributor account (compromised credentials or malicious insider).
   • Attacker creates a post containing the vulnerable shortcode with embedded JavaScript in slides attribute.
   • An administrator/editor previews the post in wp-admin or views the front-end — the script runs in the admin’s browser.
   • The script exfiltrates tokens/cookies or performs actions (create admin user, change email, export config).
2. Persistent front-end infection
   • Malicious shortcode is placed on a publicly visible page; visitors execute the injected script.
   • Results include redirections to phishing/malware, ad injection, or further content compromise.
3. SEO & distribution abuse
   • Injected scripts cause crawlers to index spam content, harming search rankings and long-term traffic.
4. Lateral movement & persistence
   • After admin session compromise, attacker installs backdoors, modifies files, or creates scheduled tasks.

Note: Contributor access is commonly available on many sites (guest authors, reused credentials). Treat contributor privileges as untrusted where plugins process HTML-capable attributes.

Immediate actions (first 0–24 hours)

Perform these steps in order until full remediation is in place.

1. Identify affected sites. Inventory installs and plugin versions across your estate.
2. Apply vendor patch if available — update immediately. Backup DB and wp-content first.
3. If no patch yet — deactivate the plugin. This stops shortcode rendering and immediate exploitation.
4. Restrict or audit contributor activity. Disable new contributor registrations, review existing contributor accounts, and suspend suspicious users. Force password resets if warranted.
5. Apply a short-term content sanitisation filter. Add a temporary filter to strip scripts from rendered content (examples below).
6. Scan for suspicious shortcodes/content. Use the SQL/WP-CLI scans in the detection section to locate candidate posts.
7. Monitor logs and alert. Watch webserver and application logs for posts/requests containing shortcode patterns.
8. If compromise is suspected: take the site offline or block unknown IPs, snapshot for forensics, and rotate high-privilege credentials.

Temporary code mitigations you can apply (safe, reversible)

Apply changes as an mu-plugin (recommended) or in theme functions.php. Backup before applying and test on staging where possible.

1) Remove / disable the vulnerable shortcode (preferred)

If you can identify the shortcode tag (e.g. mpc_carousel or multi_post_carousel), remove it so the plugin handler does not execute.

<?php
/*
Plugin Name: Temporary Shortcode Disable
Description: Temporarily removes vulnerable carousel shortcode to prevent stored XSS payload execution.
Author: HK Security Team
Version: 0.1
*/

// Replace 'mpc_carousel' with the actual shortcode tag used by the plugin.
add_action('init', function() {
    if ( shortcode_exists('mpc_carousel') ) {
        remove_shortcode('mpc_carousel');
    }
});
?>

2) Global script removal filter (brute-force but effective)

Removes <script> blocks from content. This is blunt and may break legitimate scripts, but prevents stored script execution while you fix the root cause.

<?php
/*
Plugin Name: Remove Script Tags Temporary
Description: Removes <script> tags from post content to mitigate stored XSS while a fix is applied.
Version: 0.1
Author: HK Security Team
*/

add_filter('the_content', 'hk_strip_script_tags', 20);
add_filter('widget_text', 'hk_strip_script_tags', 20);
add_filter('comment_text', 'hk_strip_script_tags', 20);

function hk_strip_script_tags($content) {
    // Remove all <script>...</script> blocks.
    $content = preg_replace('#<script(.*?)&(gt;)?(.*?)</script>#is', '', $content);
    // Remove javascript: pseudo-protocol from href/src
    $content = preg_replace('#(href|src)\s*=\s*[\'"]\s*javascript:[^\'"]*[\'"]#i', '', $content);
    return $content;
}
?>

3) Sanitize only the offending shortcode attribute (surgical)

If you know how the plugin maps shortcode attributes, sanitize the slides attribute before output. The filter name depends on the shortcode tag.

add_filter('shortcode_atts_mpc_carousel', 'hk_sanitize_mpc_slides', 10, 3);

function hk_sanitize_mpc_slides($out, $pairs, $atts){
    if ( isset($out['slides']) ) {
        // Strip angle brackets and javascript: pseudo-protocol, then remove tags.
        $sanitized = preg_replace('/[<>]/', '', $out['slides']);
        $sanitized = preg_replace('/javascript:/i', '', $sanitized);
        $out['slides'] = wp_strip_all_tags($sanitized);
    }
    return $out;
}

If unsure of the exact shortcode tag, use the remove-shortcode or strip-script approach first.

Detection: find injected content in your database and checks

Stored XSS often lives in post_content, postmeta, widget options and revisions. Use these queries and CLI checks to locate suspicious entries. Adjust table prefixes if not wp_.

A. SQL: Search for likely shortcode usage patterns

-- Search posts for the carousel shortcode
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%[mpc_carousel%'
   OR post_content LIKE '%[multi_post_carousel%'
   OR post_content LIKE '%slides=%';

B. SQL: Find posts where ‘slides’ attribute contains angle brackets or “javascript:”

SELECT ID, post_title, post_content
FROM wp_posts
WHERE post_content LIKE '%slides=%<%'
   OR post_content LIKE '%slides=%>%'
   OR post_content LIKE '%slides=%javascript:%';

C. WP-CLI: Search and show matching posts

# Find posts containing the shortcode tag (example)
wp post list --post_type=post,page --format=ids --path=/path/to/wp | \
xargs -r -n1 -I % sh -c 'wp post get % --field=post_content | grep -i "mpc_carousel" && echo "Matched: %"'

Note: adapt the WP-CLI commands to your environment to avoid high load on production.

D. Scan postmeta and widgets

Search wp_postmeta, wp_options (widget_option values), and wp_comments for shortcode-like data.

SELECT option_name FROM wp_options
WHERE option_value LIKE '%mpc_carousel%'
   OR option_value LIKE '%slides=%';

E. Check revisions

SELECT p.ID, r.post_parent, r.post_modified, r.post_content
FROM wp_posts r
JOIN wp_posts p ON r.post_parent = p.ID
WHERE r.post_type = 'revision'
  AND r.post_content LIKE '%slides=%';

F. Indicators of compromise

• Unexpected admin users, role changes, or new high-privilege accounts.
• Unexpected scheduled tasks (cron entries).
• Modified plugin/theme files without authorised updates.
• Outgoing connections to unknown domains in server logs.

WAF / Virtual patching: rules to block exploit attempts

Virtual patches provide immediate protection while you wait for plugin fixes. Below are general rule patterns to implement in your WAF, reverse proxy, or webserver filtering. These are vendor-agnostic examples intended for rule authors or operators.

Primary objective: block requests that attempt to inject scripts into the slides attribute or include suspicious JS vectors.

• Block/flag POST requests that contain a shortcode tag combined with script tags:
  • Pattern: \[mpc_carousel[^\]]*slides=.*<script (case-insensitive)
• Block attribute values containing javascript: or inline event handlers:
  • Pattern: slides=[^>]*javascript: or onerror=|onload=|onclick=|onmouseover=
• Block POST/PUT requests that include angle brackets in shortcode attributes:
  • Pattern: slides=[^>]*<[^>]+>
• Role-based blocking: consider rejecting saves from Contributor accounts that contain <script> or other risky tokens.

Example pseudo-rule (ModSecurity-style semantics):

SecRule REQUEST_METHOD "POST" "chain,deny,log,status:403,msg:'Blocked possible stored XSS via slides attribute'"
  SecRule ARGS_POST "@rx (\[mpc_carousel[^\]]*slides=.*<script)|(\bslides=.*javascript:)|(\bslides=.*on\w+=)" "t:none,ctl:requestBodyProcessor=URLENCODED"

Caveats: tune rules to avoid false positives (some legitimate integrations may store JSON-like slides data). Deploy in logging-only mode first, then move to block mode when comfortable.

Recovery and incident response playbook (if you are compromised)

If you detect payload execution and possible admin compromise, follow this playbook:

1. Isolate and snapshot. Take DB and filesystem snapshots for forensic analysis; preserve logs.
2. Reset credentials and rotate keys. Reset all admin and high-privilege passwords, rotate API keys and tokens.
3. Remove malicious content. Use SQL/WP-CLI scans to find and remove malicious shortcodes and scripts. Restore known-good revisions or backups.
4. Clean or reinstall modified files. Compare files to trusted repository copies and replace modified files rather than editing in place.
5. Hunt for backdoors & persistence. Search wp-content/uploads, mu-plugins, and theme/plugin directories for suspicious PHP files; check for unexpected cron jobs and new admin users.
6. Post-recovery hardening. Enforce least privilege, apply WAF virtual patches, and implement a Content Security Policy (CSP) to reduce future XSS risk.
7. Post-mortem and notification. Record timeline and remediation steps; notify stakeholders and comply with applicable breach disclosure obligations if data was exposed.

Long-term hardening and best practices

• Least privilege & role separation. Ensure contributors cannot insert raw HTML/scripts. Consider workflow approvals for posts containing shortcodes or HTML.
• Close plugin input/output gaps. Plugins accepting complex input must validate on input and escape on output. Attributes that are lists or IDs should accept only vetted formats (e.g., integers, comma-separated IDs).
• Sanitise & escape output. Developers should use esc_attr(), wp_kses_post(), esc_html() and whitelist accepted characters for attributes.
• Maintain WAF/virtual patches. Keep rules that detect shortcode injection patterns and script tokens; these are critical while vendors repair vulnerabilities.
• Implement CSP where possible. CSP reduces exploitability by restricting script sources; apply to admin pages and front-end as appropriate.
• Automated scanning & integrity checks. Regular scans for injected content, unexpected file changes, and suspicious shortcodes help detect issues early.
• Developer checklist for shortcodes. Validate attribute format, strip tags for plain-text attributes, escape before output, and restrict complex attributes to trusted roles.

Appendix — Quick SQL and WP-CLI references

A. Search posts for shortcodes containing “slides=”

SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_content LIKE '%slides=%'
  AND post_status IN ('publish', 'draft', 'pending', 'future');

B. Remove script tags from post_content (dangerous — backup first)

Note: REGEXP_REPLACE may depend on MySQL/MariaDB version. Test on a copy first.

UPDATE wp_posts
SET post_content = REGEXP_REPLACE(post_content, '<script[^>]*>.*?</script>', '', 'gi')
WHERE post_content REGEXP '<script[^>]*>.*?</script>';

C. WP-CLI: List posts with ‘slides=’ in content

wp post list --post_type=post,page --format=csv --field=ID,post_title | \
  while IFS=, read -r id title; do
    content=$(wp post get "$id" --field=post_content)
    echo "$content" | grep -qi "slides=" && echo "Matched: ID=$id Title=$title"
  done

D. Find revisions with risky content

SELECT p.ID, r.post_parent, r.post_modified, r.post_content
FROM wp_posts r
JOIN wp_posts p ON r.post_parent = p.ID
WHERE r.post_type = 'revision'
  AND r.post_content LIKE '%slides=%';

Final prioritised checklist

1. Identify impacted sites and plugin versions immediately.
2. If a vendor patch exists, update now (backup first).
3. If no patch, deactivate plugin or apply remove-shortcode / strip-script filters.
4. Implement WAF rules to block shortcode-based script payloads and javascript: occurrences.
5. Scan DB for injected shortcodes and clean malicious entries; check revisions and options.
6. Rotate credentials and review recent admin/editor actions.
7. Harden contributor/user roles and enforce least privilege.
8. Maintain backups and ongoing scanning/monitoring.

If you require external help, engage a qualified security consultant or an incident response provider experienced with WordPress environments. Prioritise containment, evidence preservation, and credential rotation before restoration.

Key takeaway: treat untrusted shortcode attributes and plugin-provided HTML-capable fields as dangerous input. Sanitize early, escape late, and apply layered controls to reduce risk.