Master Addons for Elementor (<= 2.0.9.0) — Authenticated Contributor Stored XSS via fancyBox (CVE-2025-8874): what site owners need to know and how to protect their WordPress sites

Summary

A stored cross-site scripting (XSS) vulnerability affecting Master Addons for Elementor (fixed in 2.0.9.1) allows an authenticated user with Contributor-level privileges to store malicious HTML/JavaScript via the plugin’s use of the fancyBox lightbox/caption fields. The stored payload executes when visitors view affected front-end pages. Although the CVSS score is moderate (6.5), the practical impact can be significant — arbitrary script execution in your domain context, which can lead to site defacement, redirects, cookie theft, or chained attacks against higher-privileged users.

This post, written with a pragmatic Hong Kong security expert tone, explains what happened, how it can be exploited, immediate mitigations you can apply before patching, detection and cleanup steps, and developer guidance to reduce recurrence.

This post covers

• What happened and which versions are affected
• Technical root cause and likely exploit path
• Immediate mitigations you can apply right now (server/site-level)
• Detection and cleanup guidance (including WP-CLI and SQL examples)
• Developer notes for plugin authors and site integrators

Vulnerability at a glance

• Affected plugin: Master Addons for Elementor — versions <= 2.0.9.0
• Fixed in: 2.0.9.1
• Vulnerability: Stored Cross-Site Scripting (XSS) via fancyBox usage
• CVE: CVE-2025-8874
• Required privilege: Contributor (authenticated user)
• Impact: Stored XSS executed in the context of the site when a visitor opens a fancyBox item or when the plugin renders unsanitized fields
• Patch priority: Low/Moderate (exploitability depends on contributor access and theme/plugin usage)

Why this matters: stored XSS is persistent

Stored XSS means an attacker stores a malicious payload on the site (in the database or persistent storage) and that payload is later delivered to other users’ browsers without proper encoding or sanitization. Unlike reflected XSS, an attacker doesn’t need to trick a victim into clicking a crafted URL; they only need the ability to save content that will be viewed by others.

Contributor accounts on many sites can upload images, edit captions, or create gallery items. If those fields are rendered into HTML attributes or caption markup by the plugin without escaping, an attacker can inject JavaScript that runs for visitors and administrators.

Technical explanation — how the exploit works (high level)

1. The plugin uses fancyBox to render images/lightboxes on the front end. fancyBox supports attributes like data-caption, title, and other parameters that can contain HTML.
2. The plugin stores user-supplied strings (captions, titles, alt text, meta fields) in post meta or widget settings and outputs them into front-end markup. In some plugin versions the output is not properly sanitized/escaped.
3. A contributor user creates or edits content (image caption, widget settings) and injects HTML/JavaScript payloads — e.g. inline

   If the plugin writes this caption into the page without escaping:

   the script runs in the user’s browser when they view the page.

   Another common vector is payloads in image attributes:

   If the fancyBox output inserts attributes into the DOM unsafely, the onerror will execute when the lightbox attempts to load the invalid src.

   Immediate actions for site owners (fast, before patching)

   If you manage sites with the affected plugin and cannot update immediately, perform the following actions in order to reduce exposure and buy time for full remediation.

   1. Update the plugin to 2.0.9.1 (recommended)

      The vendor released a fix in 2.0.9.1. This is the safest and most permanent action — update immediately where possible.

   2. Temporarily restrict contributor activity

      Change Contributor users to a lower-risk role (e.g., Subscriber) or temporarily disable new contributor registrations. If contributors are required for workflow, move to an editor-managed approval process until patched.

   3. Disable vulnerable widgets/features

      If you control theme or page templates, temporarily remove or disable gallery/lightbox widgets supplied by the plugin. Remove shortcodes, widgets, or Elementor elements that render fancyBox or gallery output until the site is patched.

   4. Apply an emergency server rule or virtual patch

      Block incoming requests that include suspicious payloads targeting known fancyBox fields or admin endpoints where contributors post data. Examples to inspect and block:

      • POST requests to admin-ajax.php, wp-admin/post.php, post-new.php that contain ', '', 'i') WHERE post_content REGEXP ']*>.*?';"
      • For programmatic sanitization, load WordPress and apply wp_kses() or strip tags with care to preserve legitimate HTML.
   5. Sanitize postmeta similarly:

      wp db query "UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, '

   6. Check attachments and uploads for suspicious files (e.g., PHP in upload dirs, unexpected HTML files). Remove or quarantine.
   7. Rotate credentials — especially for admin users who may have viewed infected content during the exposure window.
   8. Scan for webshells/backdoors across themes, plugins and uploads. If you find signs of deeper compromise, consider professional incident response and restore from a clean backup.

   Hardening and longer-term mitigations

   • Keep plugins, WordPress core, and themes updated. Patching is the first line of defence.
   • Enforce least privilege. Contributors should not be able to publish or upload without approval unless necessary.
   • Implement a content approval workflow: editors or admins should review content before publication.
   • Server-side input validation and context-aware escaping on every output point: treat all user-supplied strings as untrusted.
   • Add CSP and SRI (Subresource Integrity) where practical to reduce impact of injected scripts.
   • Validate fields displayed in attributes (data-*, title, alt, caption). Sanitize for attributes or encode as plain text.
   • Limit allowed markup in captions; if captions are intended as plain text, strip HTML tags on save.

   How a Web Application Firewall (WAF) can help immediately

   A WAF can provide virtual patching — blocking exploitation patterns before the server-side fix is applied. Ways a WAF can mitigate this issue:

   • Block POST bodies containing suspicious tokens (e.g., ', '', 'i') WHERE post_content REGEXP ']*>.*?'; "

     Search postmeta for data-fancybox entries:

     wp db query "SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%data-fancybox%' OR meta_value LIKE '%fancybox%';"

     Conceptual ModSecurity rule (test and tune):

     SecRule REQUEST_URI|ARGS|REQUEST_BODY "@rx (

     Content Security Policy header example (test carefully):

     Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'"

     Final note

     Security is both technical and operational. Patching is critical, but processes matter too: validate contributor workflows, vet third-party contributors, and ensure monitoring and virtual protections are in place to reduce the window of exposure. If you need help implementing any of the technical steps above, seek a qualified security professional to assist with scanning, rule tuning and remediation.