WWordPress Vulnerability Database

Hong Kong NGO Warns YayMail XSS(CVE20261943)

Cross Site Scripting (XSS) in WordPress YayMail – WooCommerce Email Customizer Plugin
0
Shares
0
0
0
0






Urgent: YayMail <= 4.3.2 — Authenticated Shop Manager Stored XSS (CVE-2026-1943)


Plugin Name YayMail – WooCommerce Email Customizer
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2026-1943
Urgency Low
CVE Publish Date 2026-02-17
Source URL CVE-2026-1943

Urgent: YayMail <= 4.3.2 — Authenticated Shop Manager Stored XSS (CVE-2026-1943) — What WordPress Site Owners Must Do Now

Author: Hong Kong Security Expert | Date: 2026-02-18 | Tags: WordPress, WooCommerce, Security, XSS, WAF, Vulnerability

TL;DR

A stored Cross-Site Scripting (XSS) vulnerability (CVE-2026-1943) was disclosed in the YayMail – WooCommerce Email Customizer plugin affecting versions ≤ 4.3.2. The flaw allows a user with Shop Manager privileges to inject malicious script into email template elements; the script executes when the template or UI is rendered. The plugin was patched in version 4.3.3.

If you run WooCommerce and use YayMail:

  • Update YayMail to version 4.3.3 or later immediately.
  • Audit your site for suspicious template content and remove any injected payloads.
  • Enable or tune your Web Application Firewall (WAF) or virtual patching rules to block stored XSS payloads aimed at plugin endpoints.
  • Consider temporary hardening: reduce Shop Manager privileges, restrict administrative access, and enable a Content Security Policy (CSP) where feasible.

Practical note (Hong Kong context): Many small retail operators in Hong Kong delegate store operations to contractors and part-time staff. Verify who holds Shop Manager privileges and act quickly — this vulnerability is proprietary to editable email templates and requires an authenticated user to plant a payload.

What happened? Quick technical summary

  • Vulnerability: Stored Cross‑Site Scripting (XSS).
  • Affected software: YayMail – WooCommerce Email Customizer plugin for WordPress.
  • Vulnerable versions: ≤ 4.3.2.
  • Fixed in: 4.3.3.
  • CVE: CVE-2026-1943.
  • Required privilege: Shop Manager (authenticated).
  • CVSS: 5.9 (PR:H, UI:R).
  • Attack vector: A Shop Manager can create/modify template elements that are stored in the database without proper output encoding or sanitization. When those elements are viewed or rendered (editor, preview), the stored payload executes in the browser of the viewer.

Why this matters: Shop Manager is a privileged role commonly granted to store operators and trusted staff. If an attacker gains or already controls a Shop Manager account (phishing, credential reuse, compromised contractor), they can insert malicious JavaScript into templates. When another privileged user or admin loads the template editor or previews an email, that JavaScript can execute and perform actions allowed by that user’s session (exfiltrate cookies, change settings, create new admin users via AJAX, upload backdoors, etc.).

Real-world exploitation scenarios

  1. Internal phishing / secondary account compromise
    An attacker compromises a Shop Manager account and injects JavaScript into a template element. When an admin previews the template, the payload executes and attempts escalation (create admin user, change site email, exfiltrate tokens).
  2. Malicious subcontractor or untrusted staff
    A contractor with Shop Manager access intentionally stores a malicious snippet. It executes when other staff access email templates, enabling persistence or data exfiltration.
  3. Chained attacks
    An XSS payload can load an external script that performs further actions (hidden REST API calls to create admin users, change plugin/theme files, or install backdoors). Combined with weak file permissions, this can lead to full site takeover.
  4. Client-side impact on visitors
    If template content is used in front-end displays or preview pages accessible by lower-privileged users, end-users could be exposed to malicious redirects or form interactions.

Immediate actions (first 24 hours)

1. Update the plugin

Update YayMail to version 4.3.3 or greater immediately on all environments (production, staging, test). If you cannot update immediately, apply the mitigations below and schedule the patch as the top priority.

2. Reduce exposure

  • Audit users with Shop Manager privileges and temporarily revoke accounts that are not in active use.
  • Force password resets for Shop Managers and other high-privilege accounts.
  • Enable two-factor authentication (2FA) on admin and Shop Manager accounts where available.
  • Avoid previewing or editing YayMail templates until you update.

3. WAF / virtual patching

Deploy WAF rules to detect and block stored XSS patterns posted to the plugin’s endpoints or common admin endpoints (admin-ajax.php, admin-post.php, /wp-json/*). Block requests containing suspicious patterns (script tags, event handlers, javascript: URIs, SVG/onload payloads) targeted at the plugin.

4. Scan & audit

Search your database for suspicious content inside emails/templates. Look for

Example SQL (run on a read-replica or after taking backups):

-- Search post content/meta
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%

If you find suspicious content, isolate and remove it, and investigate access logs to see who created/updated the content.

5. Monitor logs

Monitor WAF, server, PHP error logs, and admin activity logs for suspicious behavior (template saves, suspicious POSTs, admin logins from unusual IPs).

How to detect if you’ve been hit

  • Check for unexpected admin users (new accounts with Administrator or Editor roles).
  • Look for changed site settings (site email addresses, mailer settings).
  • Search templates and plugin meta for script tags or event attributes (server-side grep across backups or DB dumps for
  • Inspect WP activity logs for actions by Shop Manager accounts (template saves, edits) and file change logs for unusual modifications.
  • Inspect access logs for sequences where an admin viewed the template editor followed by unusual outgoing connections (external script loads).
  • Check WAF logs for blocked XSS attempts that match script-pattern regexes.

If you find evidence of exploitation: isolate the site, change all admin passwords, revoke sessions, restore from a clean backup if possible, and scan for backdoors.

WAF / Virtual patch guidance — practical rules you can apply now

Virtual patching is a fast way to reduce exposure until the plugin is patched. Below are concrete rule patterns and examples. Adapt and test carefully in your environment.

Design principles:

  • Target plugin-specific endpoints and admin AJAX/REST entry points.
  • Normalize and URL-decode request data before inspection.
  • Log first in learning mode; then block high-confidence matches.

Example ModSecurity-style rules (illustrative — test before enabling in production):

# Block direct