WWordPress Vulnerability Database

Community Advisory Element Pack XSS WordPress Risk(CVE20264655)

Cross Site Scripting (XSS) in WordPress Element Pack Elementor Addons Plugin
0
Shares
0
0
0
0
Plugin Name Element Pack Elementor Addons
Type of Vulnerability Cross Site Scripting (XSS)
CVE Number CVE-2026-4655
Urgency Low
CVE Publish Date 2026-04-08
Source URL CVE-2026-4655

Authenticated Contributor Stored XSS in Element Pack Addons for Elementor (CVE-2026-4655): What WordPress Site Owners Need to Know — Mitigation & WAF Guidance

Date: 2026-04-09  |  Author: Hong Kong Security Expert

Tags: WordPress, security, WAF, vulnerability, XSS, Elementor, plugin

TL;DR

A stored Cross‑Site Scripting (XSS) vulnerability (CVE‑2026‑4655) affects Element Pack Addons for Elementor (versions ≤ 8.4.2). An authenticated user with Contributor privileges can upload a crafted SVG via the plugin’s SVG image widget, leading to stored XSS. The vendor patched the issue in version 8.5.0. Impact is rated medium (CVSS 6.5). Exploitation requires the vulnerable plugin and an authenticated Contributor account (or a site configuration that allows Contributors to upload media).

Immediate priorities:

  • Update Element Pack Addons for Elementor to 8.5.0 or later as soon as possible.
  • If you cannot update immediately: block the vector with a WAF, disable SVG uploads, restrict upload permissions, and audit/remove suspicious SVGs from the media library.
  • Use virtual patching / targeted WAF rules to stop exploit attempts while you patch.

Background — the vulnerability in plain language

Element Pack Addons for Elementor had an SVG sanitization/handling flaw in versions up to 8.4.2. Authenticated users with Contributor privileges (or higher) could upload SVG files containing scripting constructs (inline JavaScript, event handlers, dangerous entities). The plugin’s SVG image widget stored or rendered the unsafe SVG in a way that allowed that script to execute later — a stored XSS.

Stored XSS is particularly dangerous because the malicious payload is persisted (media library, postmeta, database) and can execute when another user or any visitor loads the affected page. The attacker needs either a higher‑privileged user to view/interact with the content or a regular visitor to load the page where the SVG is rendered. The vendor fixed the bug in 8.5.0; CVE‑2026‑4655 notes the requirement for an authenticated contributor (or similar) account to upload media.

Why this matters for WordPress sites

  • SVGs are XML and can contain scriptable content; unlike PNG/JPG, they can include JavaScript or event handlers that execute when rendered inline.
  • Elementor and addon ecosystems expand site functionality but also increase attack surface.
  • Contributor accounts are commonly available for content contributors; if those accounts can upload media, they can be used to weaponize SVG uploads.
  • Stored XSS consequences include admin session theft, privilege escalation, content injection, defacement, redirects, SEO spam and backdoors.

Even low‑traffic sites can be discovered and exploited by automated scanners or targeted attackers.

Attack flow (high level)

  1. Attacker registers or acquires a Contributor account (or compromises one).
  2. Attacker uploads a malicious SVG via the plugin’s SVG widget or media uploader.
  3. The plugin stores the SVG and later renders it inline without removing dangerous content.
  4. A privileged user or a visitor opens the page; the JavaScript in the SVG executes.
  5. The attacker’s script performs malicious actions (cookie theft, content injection, creating admin users, loading additional payloads).

Modern browser protections (SameSite, HttpOnly, CSP) may mitigate some payloads, but XSS remains a high‑risk class.

Immediate actions (first 6–24 hours)

  1. Update (best option)
    • Install Element Pack Addons for Elementor 8.5.0 or later immediately. This is the definitive fix.
  2. If you cannot update immediately, apply mitigation layers
    • Restrict uploads: Temporarily remove upload capability from Contributors and similar low‑privilege roles.
    • Disable SVG uploads: Block SVG files at the WordPress or server level (MIME/extension blocking).
    • WAF virtual patching: Deploy rules to detect and block SVG uploads that contain script‑like constructs or suspicious attributes.
    • Media library audit: Search for recently uploaded SVGs by low‑privilege accounts and remove unexpected files.
    • Limit editor roles: Ensure only trusted users can insert widgets that render uploaded SVG content.
  3. Monitor logs for signs of exploitation (suspicious uploads, POSTs to plugin endpoints, new admin users).

Update first; other mitigations are temporary but important if you cannot patch immediately.

Use WAF or server‑side checks to stop malicious SVGs before they reach the application. Adapt the patterns and testing thresholds to your environment to reduce false positives.

  • Block SVG uploads that contain script or event attributes:

    Match .svg filenames or Content-Type image/svg+xml and reject if the first part of the payload contains strings such as , onload=, onerror=, javascript:, , or suspicious xlink patterns.

  • Inspect responses: Alert on HTML responses that include inline tags containing or on* attributes.
  • Protect plugin endpoints: Add inspection/blocking for POST routes used by the plugin to save widget data or media metadata.
  • Rate limit uploads: Throttle uploads from low‑privilege accounts to reduce automated abuse.
  • Flag first‑time uploads: If a newly created account uploads an SVG immediately, block or flag it for review.

Conceptual ModSecurity-style rule (simplified — test before use):

SecRule REQUEST_HEADERS:Content-Type "image/svg+xml" "phase:2,chain,deny,id:10001,msg:'Block SVG upload with inline script'"
SecRule REQUEST_BODY "(?i)(

Always run new rules in detection mode first to avoid disrupting legitimate workflows, especially if your site uses inline SVGs.

Server / .htaccess / nginx recommendations

Prevent browsers from rendering uploaded SVGs inline by forcing them to download instead of serving as inline content from the uploads directory.

Apache (.htaccess in wp-content/uploads) example:


  Header set Content-Disposition "attachment"
  Header set Content-Type "application/octet-stream"

Nginx conceptual example:

location ~* \.svg$ {
    add_header Content-Disposition 'attachment';
    default_type application/octet-stream;
}

Note: forcing download prevents inline rendering and mitigates XSS from uploaded SVGs, but it also breaks legitimate inline SVG usage. If inline SVGs are needed, use a sanitizer that strips scripts and event attributes server‑side before saving.

WordPress‑level mitigations

  • Disable SVG upload support where feasible. Remove plugins that allow unsafe SVG uploads until you have sanitization in place.
  • Use an SVG sanitizer if SVGs are required. Ensure sanitization removes scripts, event handlers, external references and dangerous entities.
  • Review role capabilities — audit the upload_files capability and remove it from Contributors unless absolutely necessary.
  • Enforce unfiltered_html restrictions — only allow unfiltered HTML to trusted administrators.
  • Apply Content Security Policy (CSP) headers where practical to reduce impact from injected scripts (test carefully to avoid breaking site functionality).

Detection — what to look for

  • New or recent SVG files in the media library uploaded by low‑privilege or recently created accounts.
  • Unexpected changes in pages or widgets that include SVGs.
  • Browser console activity showing unexpected calls to third‑party domains after page load.
  • New admin users, injected content, or spam links/redirects.
  • Server logs showing POSTs to plugin endpoints with XML payloads matching SVG patterns.
  • WAF or IDS alerts for inside image upload requests.

Run a filesystem and database search for suspicious tags (e.g., with script attributes,