Urgent: XSS in Master Addons for Elementor (≤ 2.1.1) — What WordPress Site Owners Need to Do Right Now

Author note — Hong Kong security expert: This advisory is direct and practical. It describes the vulnerability, risk, rapid detection and remediation steps you can apply immediately. Follow the prioritized actions in the order given. Treat this as an operational checklist for incident response.

Résumé

• Vulnérabilité : Authenticated Stored Cross-Site Scripting (XSS) via the ma_el_bh_table_btn_text champ.
• Versions affectées : Master Addons for Elementor ≤ 2.1.1
• Patched version: 2.1.2
• CVE : CVE-2026-2486
• Privilège requis : Contributeur
• Impact : Stored XSS can lead to cookie theft, account takeover (if privileged users view the crafted content), persistent content manipulation and other follow-on compromise.

Technical explanation — how this works

This is a stored XSS vulnerability in the plugin field ma_el_bh_table_btn_text. A user with Contributor privileges can submit input containing HTML/JavaScript which the plugin stores and later renders without proper sanitization/escaping. When a visitor or an administrator views the affected page, the stored script will execute in their browser context.

Typical exploitation chain:

1. Attacker obtains or controls a Contributor account.
2. They submit payloads into the plugin field (for example: <img src="x" onerror="...">, <script>...</script> or encoded variants).
3. The plugin stores this value in postmeta or options without adequate sanitization.
4. When the site renders that value, the browser executes the stored script as the site origin.
5. If an administrator or other privileged user views the page, the script could act with their session privileges.

Risk analysis — why this matters

• Access level: Contributor — many sites allow contributor accounts or user registrations.
• Interaction utilisateur : Required — script runs when content is viewed; impact depends on who views it.
• CVE/CVSS context: Reported CVSS: 6.5 (medium) — moderate privilege required but impact can escalate.
• Attacker objectives: session theft, persistent malicious content, SEO spam, admin action execution via the victim browser, redirects to phishing/malware.

Immediate actions (apply in this order)

1. Mettre à jour the plugin to version 2.1.2 immediately. If you cannot update right away, disable or remove the plugin until you can patch.
2. If you cannot update instantly, apply temporary server-side or WAF rules to block submissions to the vulnerable field or block payloads containing obvious script markers.
3. Temporarily restrict Contributor accounts: remove or disable contributor users, or reduce their capabilities so they cannot submit the vulnerable field.
4. Search the database for stored payloads in meta with key ma_el_bh_table_btn_text and remove or sanitize malicious entries.
5. If you suspect admins viewed malicious content, force password resets for administrator and editor accounts and audit sessions.
6. Audit user accounts and recent activity logs for suspicious actions.
7. Scan the site for other indicators of compromise (unexpected files, modified code, scheduled tasks, external requests).
8. Rotate API keys and secrets if they might have been exposed.

How to find and clean malicious stored payloads

Always work from a verified backup or perform read-only queries first. Backup the database before deleting anything.

Example SQL to find occurrences (escape characters shown):

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_key = 'ma_el_bh_table_btn_text'
AND meta_value LIKE '%<script%';

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE meta_key = 'ma_el_bh_table_btn_text'
AND (meta_value LIKE '%onerror=%' OR meta_value LIKE '%onload=%' OR meta_value LIKE '%<img%' OR meta_value LIKE '%<script%');

Example delete (only after review and backup):

DELETE FROM wp_postmeta
WHERE meta_key = 'ma_el_bh_table_btn_text'
AND (meta_value LIKE '%<script%' OR meta_value LIKE '%onerror=%');

WP-CLI examples for safer scripted remediation:

# List posts which have the meta key (returns IDs)
wp post meta list $(wp post list --format=ids) --meta_key=ma_el_bh_table_btn_text --format=csv

# Delete the meta key across posts (use with caution; backup first)
wp post meta delete $(wp post list --format=ids) ma_el_bh_table_btn_text

Note: Inspect meta values before deletion. Export values for forensic review if compromise is suspected.

Short-term mitigations you can apply now (technical)

• Update the plugin to 2.1.2 (vendor patch is the permanent fix).
• If update is not immediately possible, implement temporary server-side input filtering that blocks or sanitizes submissions to ma_el_bh_table_btn_text.
• Apply a Content Security Policy (CSP) to reduce the impact of inline script execution. Example header (defense-in-depth):
  Content-Security-Policy: default-src 'self'; script-src 'self' https:; object-src 'none'; base-uri 'self';
  — test first, as CSP can break functionality if too strict.
• Disable rendering of unsafe HTML for the plugin if a plugin setting exists to limit the field to plain text.
• Block or rate-limit suspicious IPs targeting injection attempts and monitor logs for patterns.
• Consider server-side stripping or rejection of HTML from low-trust roles (Contributors/Authors).

Example virtual patch / WAF rules (neutral examples you can adapt)

Use these as starting points. Test rules in monitor mode to avoid false positives.

Rule A — Block obvious XSS markers on the vulnerable parameter

Conditions :

• Request method: POST (also consider PUT/PATCH if applicable)
• Paramètre : ma_el_bh_table_btn_text exists
• Parameter value matches regex: (?i)(<script\b|<img\b[^>]*onerror=|onload=|javascript:|<svg\b|<iframe\b|<object\b|<embed\b)

Action: Block (403) and log origin IP and request details.

Rule B — Sanitize by stripping tags

Condition: Parameter ma_el_bh_table_btn_text exists. Action: Normalize value by removing tags/dangerous attributes and allow.

Rule C — Rate-limit contributor content submissions

Apply a throttle or CAPTCHA challenge for new contributor submissions or when a contributor posts frequently in a short time window.

Rule D — Block encoded/obfuscated payloads

Détecter %3Cscript, \x3cscript, eval(, base64, or other obfuscated JS patterns and flag or block for manual review.

Developer fixes and long-term remediation

If you maintain code that saves or renders the plugin output, apply these secure coding practices:

1. Désinfecter lors de l'enregistrement — use WordPress sanitizers appropriate to the content:
   • Texte brut : sanitize_text_field() ou wp_strip_all_tags()
   • HTML limité : wp_kses( $input, $allowed_html ) with a conservative allowed list
2. Échappez à la sortie — utiliser esc_html(), esc_attr() or similar depending on context.
3. Appliquez des vérifications de capacité et des nonces for all form submissions.
4. Avoid storing untrusted rich HTML when plain text suffices. If rich HTML is required, sanitize strictly at save time and escape at render time.

Example sanitization when saving (illustrative):

// When saving meta
$value = isset($_POST['ma_el_bh_table_btn_text']) ? wp_kses_post( $_POST['ma_el_bh_table_btn_text'] ) : '';
update_post_meta( $post_id, 'ma_el_bh_table_btn_text', $value );

8. Exemple de rendu sécurisé :

$btn_text = get_post_meta( $post_id, 'ma_el_bh_table_btn_text', true );
echo '<button class="ma-button" title="' . esc_attr( $btn_text ) . '">' . esc_html( $btn_text ) . '</button>';

Réponse aux incidents — si vous soupçonnez un compromis

1. Isolate the site if you observe active exploitation (unexpected redirects, new admin activity, files modified).
2. Conservez les journaux et les sauvegardes pour une analyse judiciaire.
3. Scan filesystem for webshells and changed files; manual review is often necessary.
4. Rotate admin credentials and any API keys/secrets.
5. Restore from a clean backup if recovery is not possible quickly.
6. Notify affected users if their accounts or data may have been exposed.
7. Perform a post-incident audit to tighten controls and close gaps.

Hardening and long-term posture

• Principle of least privilege — re-evaluate roles and capabilities.
• Harden user onboarding for contributors (email verification, admin approval, MFA for privileged accounts).
• Run periodic content and file integrity scans; monitor for suspicious postmeta values containing HTML/JS.
• Test plugin updates in staging before production; test any temporary WAF rules in staging first.
• Maintain off-site versioned backups.

Testing checklist — verify protections

• Update plugin to 2.1.2, then attempt to submit a benign script payload as a contributor and verify it is sanitized or blocked.
• Verify any temporary WAF rules block POSTs containing script markers in the ma_el_bh_table_btn_text paramètre.
• Search the DB for <script and suspicious attributes in postmeta values; ensure stored payloads have been removed.
• Confirm security headers (CSP, X-Content-Type-Options, X-Frame-Options) are present and tested.
• Ensure logging and alerts for blocked attempts are functioning.

Useful commands and snippets

Backup DB (always before changes):

wp db export before-xss-remediation.sql

Quick DB search for affected meta:

wp db query "SELECT post_id, meta_value FROM wp_postmeta WHERE meta_key='ma_el_bh_table_btn_text' AND meta_value LIKE '%<script%';"

Example PHP sanitization (author-side):

if ( isset( $_POST['ma_el_bh_table_btn_text'] ) && check_admin_referer('my_nonce_action') ) {
    $raw = wp_unslash( $_POST['ma_el_bh_table_btn_text'] );
    $sanitized = wp_kses( $raw, array( 'strong' => array(), 'em' => array(), 'br' => array() ) );
    update_option( 'ma_el_bh_table_btn_text', $sanitized );
}

Example detection regex (adapt for your WAF):

(?i)(<script\b|on\w+\s*=|javascript:|<img\b[^>]*onerror=|%3Cscript|eval\(|\balert\s*\()

Disclosure timeline & credits

• Discovery/Report date: 19 Feb, 2026
• Reporter: Thanakorn Bunsin (KMITL)
• Affected plugin: Master Addons for Elementor (≤ 2.1.1)
• Fixed in: 2.1.2
• CVE: CVE-2026-2486 (Enregistrement CVE)

Final priority checklist

1. Update Master Addons for Elementor to 2.1.2 immediately.
2. If you cannot update, apply targeted blocking or sanitization on ma_el_bh_table_btn_text.
3. Backup the site and search for malicious stored payloads; remove or sanitize them.
4. Temporarily restrict Contributor privileges and review content before publishing.
5. Rotate credentials if admin accounts could have been exposed.
6. Scan for file changes and signs of further compromise.
7. Harden input/output sanitization and implement appropriate security headers.

If you are not confident applying these steps, consult a trusted security professional experienced with WordPress incident response. Prioritize the vendor patch (2.1.2) as the permanent fix.