WWordPress Vulnerability Database

Hong Kong Warning XSS in Master Addons(CVE20262486)

Cross Site Scripting (XSS) in WordPress Master Addons for Elementor Plugin
0
Shares
0
0
0
0






Urgent: XSS in Master Addons for Elementor (<= 2.1.1) — Advisory


Plugin Name Master Addons for Elementor
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2026-2486
Urgency Low
CVE Publish Date 2026-02-19
Source URL CVE-2026-2486

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.

Summary

  • Vulnerability: Authenticated Stored Cross-Site Scripting (XSS) via the ma_el_bh_table_btn_text field.
  • Affected versions: Master Addons for Elementor ≤ 2.1.1
  • Patched version: 2.1.2
  • CVE: CVE-2026-2486
  • Required privilege: Contributor
  • 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: , 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.
  • User interaction: 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. Update 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 '%
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 '%

Example delete (only after review and backup):

DELETE FROM wp_postmeta
WHERE meta_key = 'ma_el_bh_table_btn_text'
AND (meta_value LIKE '%

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)
  • Parameter: ma_el_bh_table_btn_text exists
  • Parameter value matches regex: (?i)(]*onerror=|onload=|javascript:|

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

Detect %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. Sanitize on save — use WordPress sanitizers appropriate to the content:
    • Plain text: sanitize_text_field() or wp_strip_all_tags()
    • Limited HTML: wp_kses( $input, $allowed_html ) with a conservative allowed list
  2. Escape on output — use esc_html(), esc_attr() or similar depending on context.
  3. Enforce capability checks and 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 );

Example safe rendering:

$btn_text = get_post_meta( $post_id, 'ma_el_bh_table_btn_text', true );
echo '';

Incident response — if you suspect compromise

  1. Isolate the site if you observe active exploitation (unexpected redirects, new admin activity, files modified).
  2. Preserve logs and backups for forensic analysis.
  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 parameter.
  • Search the DB for