Plugin Name	WordPress Prime Slider – Addons For Elementor Plugin
Type of Vulnerability	Cross-Site Scripting (XSS)
CVE Number	CVE-2026-4341
Urgency	Medium
CVE Publish Date	2026-04-07
Source URL	CVE-2026-4341

WordPress Prime Slider <= 4.1.10 — Authenticated Stored XSS via follow_us_text (CVE-2026-4341): What Site Owners Must Do Now

Author: WP‑Firewall Security Team

Date: 2026-04-08

Tags: WordPress, Security, XSS, WAF, Prime Slider, Vulnerability

Summary: A stored Cross-Site Scripting (XSS) vulnerability affecting the Prime Slider – Addons For Elementor plugin (versions <= 4.1.10) allows authenticated users with author-level (or higher) privileges to inject scripts via the follow_us_text parameter. The issue is tracked as CVE-2026-4341 and was fixed in version 4.1.11. This advisory explains the risk, exploitation scenarios, detection techniques, database search queries, incident response steps, hardening guidance, and practical WAF rules you can apply immediately — including using WP‑Firewall to protect your site while you update.

Table of contents

• Background and impact
• Who is at risk
• How the vulnerability works (high level)
• Exploitation scenarios and attacker goals
• Safe detection and indicators of compromise
• How to search your site and database for compromises
• Immediate remediation steps (short path)
• Recommended hardening and long-term mitigation
• WAF / virtual patch rules and examples
• If your site is already compromised: recovery plan
• Operational recommendations for multisite and agencies
• Try WP‑Firewall free plan (Protect your site instantly)
• Final checklist

---

Background and impact

On April 7, 2026 a stored XSS vulnerability was disclosed affecting Prime Slider – Addons For Elementor plugin versions up to and including 4.1.10. The plugin stored an attacker-controlled value from the follow_us_text parameter without proper sanitization or output escaping. An authenticated user with author-level (or similar) privileges could inject HTML/JavaScript that would be stored and later executed in the browser context of other users visiting pages where the value is rendered.

The vulnerability is classed as Cross-Site Scripting (stored) and is assigned CVE-2026-4341. The vendor fixed the issue in version 4.1.11; site owners should update immediately. While the reported severity is moderate (CVSS 5.9), stored XSS can be very disruptive: attackers can steal session tokens, perform actions on behalf of administrators, inject redirect scripts, or create persistent defacements and advertising monetization.

Who is at risk

• Any WordPress site running Prime Slider – Addons For Elementor plugin at version 4.1.10 or earlier.
• Sites that allow non-administrator authenticated users to create or edit slider content (Author/Contributor or similar).
• Sites where the vulnerable plugin outputs follow_us_text into pages that are viewed by administrators, editors, or other authenticated users, or even unauthenticated visitors in some configurations.
• Multisite networks where the plugin is network-active.

Note: Even if a site has low traffic, automated mass-exploitation or a targeted attack against a specific admin/editor can be highly damaging.

How the vulnerability works (high level)

1. The plugin includes a parameter or setting commonly referred to as follow_us_text. This value is editable via the plugin UI and saved to the database, likely in options, post meta, or plugin settings.
2. The code path that accepts and stores follow_us_text does not fully sanitize or encode dangerous input (such as <script> tags or event-handler attributes).
3. When the plugin later outputs follow_us_text in a page, the stored HTML/JS executes in the visitor’s browser. Because it’s stored, the payload persists across visits.
4. An attacker with author-level privileges can inject a payload that executes when higher-privileged users (e.g., administrators) view the slider or the page containing it.
5. Depending on the target and payload, the attacker can perform cookie theft, session hijacking, privilege escalation via CSRF-style actions, or implant additional backdoors.

Exploitation scenarios and attacker goals

• Privilege escalation pivot: An attacker with Author-level access injects a script that captures admin credentials or session cookies when an administrator previews or edits a page containing the slider.
• Persistent malware drop: The attacker injects a script that loads malicious content or uses the visitor’s browser as a distribution point for spam or ads.
• Social engineering/redirects: The injected script creates a fake admin notification prompting action (phishing), or redirects visitors to a phishing site or pay-per-click farm.
• SEO poisoning or spam: Attackers inject SEO spam, hidden links, or content that harms search ranking or leads to blacklisting.
• Second-stage payload delivery: The XSS payload is used to exploit trusted admin-only features (e.g., uploading a malicious plugin or changing site options) via authenticated actions.

Safe detection and indicators of compromise

Because this is a stored XSS, detection focuses on both stored content and behavioral indicators:

• Unexpected inline <script> tags, javascript: URIs, or on* attributes (onclick, onmouseover) in plugin settings, theme options, or slider content.
• Changes to the site’s header/footer content or additional unexpected inline JS on pages containing the plugin’s slider.
• Admins seeing strange popups, password prompts, or redirects only when they are logged in.
• New admin-level users or content created that you did not authorize.
• Outbound connections to unfamiliar domains initiated by the site’s pages.
• Alerts from security scanners showing the plugin version and known XSS vulnerabilities.

How to search your site and database for compromises (safe queries)

Before performing edits, take a full backup of files and database. When searching for indicators, use read-only queries where possible.

Common SQL examples (adjust table prefix if not wp_):

• Search options table:
  SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%javascript:%' LIMIT 50;
• Search posts (content):
  SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onmouseover=%' OR post_content LIKE '%javascript:%' LIMIT 100;
• Search postmeta (plugin might store fields here):
  SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_key LIKE '%follow_us%' OR meta_value LIKE '%<script%' LIMIT 100;
• Search all meta values for suspicious patterns:
  SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 200;

WP-CLI examples (safe, read-only searches):

• wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"
• wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_key LIKE '%follow_us%';"

File system scans (grep):

• Find any files or templates with the literal follow_us string:
  grep -R "follow_us" wp-content/ -n
• Grep for scripts in uploads or cache folders:
  grep -R "<script" wp-content/uploads/ -n

Important: Searching for “<script” will flag legitimate uses (themes, plugins). Investigate matched results by reviewing context. Look for obfuscated JS, eval, unescape or base64 payloads.

Immediate remediation steps (short path)

If you have the vulnerable plugin installed and cannot immediately update, take these immediate actions:

1. Update the plugin
   Primary fix: Upgrade Prime Slider to version 4.1.11 or later. This resolves the root cause.
2. If you cannot update right away, tighten privileges
   – Restrict who can edit sliders: Remove author/contributor rights to save slider content until patching is complete.
   – Temporarily downgrade edit privileges for non-trusted users.
3. Apply virtual patching via WP‑Firewall (recommended)
   – Turn on rule sets that detect and block script tags or suspicious content in requests when saving slider content or plugin settings.
   – Enable our managed firewall and WAF rules for immediate protection while you update.
4. Block request patterns
   – Disable or block requests that include the follow_us_text parameter with suspicious payloads (see WAF rule examples in the next section).
5. Scan for existing injection
   – Run a full site malware scan with WP‑Firewall or your scanner, and search database for stored script tags as shown above.
6. Reset sessions and critical credentials (if compromise suspected)
   – Force logout of all users and rotate admin passwords. Consider rotating salts in wp-config.php (AUTH_KEY, SECURE_AUTH_KEY, etc.).

Recommended hardening and long-term mitigation

1. Principle of least privilege
   – Only trusted users should have the ability to edit or add plugin/theme content that supports unfiltered HTML. Restrict capabilities to administrators where possible.
2. Remove unfiltered_html capability from lower roles
   – Use a small code snippet or role-management plugin to ensure only administrators retain unfiltered_html.

   PHP snippet to remove unfiltered_html from authors/contributors (add to a MU plugin):

   add_action('init', function() {
       $roles = array('author','contributor','editor'); // remove from non-admin
       foreach ($roles as $role_name) {
           $r = get_role($role_name);
           if ($r && $r->has_cap('unfiltered_html')) {
               $r->remove_cap('unfiltered_html');
           }
       }
   });

   Note: Test in staging first. Editors may legitimately need unfiltered_html on some workflows; make decisions based on risk.

3. Output escaping and content sanitization
   – Plugin developers must sanitize and escape user-supplied values on both input and output. Site owners should prefer plugins that follow WP core conventions (sanitize_text_field, wp_kses_post, esc_html, esc_attr).
4. Content-Security-Policy (CSP)
   – Deploy a restrictive CSP to limit where scripts may load from and help mitigate the impact of injected inline scripts. Example header:
   Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; object-src 'none';
5. Disable plugin UI for untrusted roles
   – Where feasible, prevent slider editing by non-admins by filtering capabilities or removing menu items using remove_menu_page/remove_submenu_page and capability checks.
6. Periodic scans and monitoring
   – Schedule daily/weekly scans for malicious JS or unexpected changes and enable file integrity monitoring.
7. Backups and tested restore procedures
   – Maintain recent backups and test restore process. Offline backups are best to avoid infected backups.

WAF / virtual patch rules and examples

A Web Application Firewall (WAF) can provide immediate virtual patching to block exploit attempts before code is updated. Below are example rules (conceptual) you can implement. If you use WP‑Firewall, you can add equivalent managed rules quickly.

Important: These examples are meant to guide configuration. Test rules in monitoring mode before blocking to avoid false positives.

Example ModSecurity rule (block script tags in follow_us_text parameter):

SecRule ARGS:follow_us_text "@rx (?i)(<\s*script|javascript:|on\w+\s*=)" \
  "id:1001001,phase:2,deny,log,status:403,msg:'Block XSS attempt in follow_us_text',severity:2,tag:'WP-Firewall:PrimeSlider',t:none,t:urlDecodeUni"

General ARGS rule to catch inline scripts:

SecRule ARGS_NAMES|ARGS|REQUEST_COOKIES "@rx (?i)(<\s*script|on\w+\s*=|javascript:|eval\(|unescape\(|fromCharCode\()" \
  "id:1001002,phase:2,deny,log,status:403,msg:'Possible XSS payload blocked',t:none,t:urlDecodeUni"

Block POSTs to the plugin’s settings endpoint containing suspicious JS (adjust path):

SecRule REQUEST_METHOD "POST" "chain,phase:2,id:1001003,deny,status:403,msg:'Prime Slider settings POST with suspicious payload'"
  SecRule REQUEST_URI "@contains prime-slider" "t:none"
  SecRule ARGS_NAMES|ARGS "@rx (?i)(<\s*script|on\w+\s*=|javascript:)" "t:none,t:urlDecodeUni"

WP‑Firewall specific guidance (recommended configuration)

• Enable “virtual patching” mode: blocking rules for the follow_us_text parameter and similar fields in the plugin.
• Activate OWASP top 10 protections (already included in Basic Free plan).
• Turn on advanced request body scanning for POSTs to plugin endpoints.
• Enable alerting for rule hits with admin email or Slack integration.
• Run scanner to detect stored scripts in plugin data and notify site owner.

If your WAF supports positive allow lists, whitelist only expected HTML patterns for follow_us_text (e.g., plain text, minimal formatting), and block everything else.

If your site is already compromised: recovery plan

If you find evidence of stored XSS or other malicious changes, treat the site as compromised and follow these steps:

1. Contain
   – Put the site in maintenance mode to limit further damage.
   – Disable write access (via file permissions) where possible and isolate the server.
2. Snapshot/backup
   – Take a forensic copy of files and database (store securely offline) before making changes.
3. Rotate credentials
   – Reset admin and FTP accounts; rotate API keys and change database passwords. Rotate WordPress salts in wp-config.php to invalidate cookies/sessions.
4. Remove malicious entries
   – Delete or sanitize affected options/postmeta entries found in searches above.
   – When removing scripts from DB fields, be conservative: keep backups in case you remove legitimate content.
5. Scan and clean
   – Run a full malware scan and remove malicious files or code. If the infection is substantial, consider a restore from a clean backup.
6. Re-audit plugins and themes
   – Update all plugins/themes to their latest versions. Remove plugins that are unused or abandoned.
7. Review logs
   – Analyze access logs to determine how the attacker accessed the site and what pages served malicious content. Look for new admin users, scheduled tasks, or unknown code.
8. Harden and monitor
   – Apply the hardening steps above and enable continuous monitoring and WAF protections to prevent re-infection.
9. If needed, engage professionals
   – For complex compromises, a security professional may be required to perform a deep forensic investigation and cleanup.

Operational recommendations for multisite and agencies

• Network-admins: Update the plugin network-wide immediately. Vulnerabilities in network-active plugins can affect all subsites.
• Agency-managed sites: Audit roles on client sites. Consider centralizing security management and updates; enable controlled auto-updates for minor security releases.
• Client communications: Notify clients of the risk and the planned mitigation timeline (patch + scan + monitoring).

Try WP‑Firewall free plan — Protect your site instantly

Title: Protect Your Site Instantly with WP‑Firewall Free Plan

If you want an immediate layer of protection while you patch, sign up for the WP‑Firewall Basic (Free) plan at:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Why WP‑Firewall Free plan helps now:

• Essential protection: managed firewall that inspects incoming requests and blocks common XSS patterns.
• Unlimited bandwidth so protection scales regardless of traffic or attack volume.
• WAF (Web Application Firewall) rules applied to block suspicious payloads like script tags submitted through plugin forms.
• Malware scanner to detect stored scripts or injected assets.
• Mitigation of OWASP Top 10 risks to reduce the chance of successful exploitation while you update.

Upgrading to paid plans adds automatic malware removal, blacklisting/whitelisting, monthly security reports, and virtual patching — but the Free plan gives you fast, no-cost immediate protection that can block attempts to exploit CVE-2026-4341 while you plan and perform the plugin update.

Final checklist (practical step-by-step)

1. Check plugin versions: Is Prime Slider <= 4.1.10 installed?
2. Update plugin immediately to 4.1.11 or later.
3. If unable to update now:
   – Remove editor capabilities for untrusted roles.
   – Enable WP‑Firewall protections and apply WAF rules for follow_us_text.
4. Search DB for “<script”, “javascript:”, and meta keys containing follow_us or follow_us_text.
5. If you find injected scripts:
   – Backup the site.
   – Sanitize or remove malicious entries (careful, test on staging first).
   – Reset passwords and rotate salts.
6. Run a full malware scan, and keep monitoring alerts/suspicious rule hits.
7. Implement long-term hardening: least privilege, CSP, periodic scans, backups.
8. Sign up for WP‑Firewall Basic (Free) to get managed WAF and malware scans immediately:
   https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Appendix: Practical examples and commands (recap)

• Update WordPress plugin via WP Admin or CLI:
  wp plugin update bdthemes-prime-slider-lite
• DB search for suspect postmeta:
  wp db query "SELECT * FROM wp_postmeta WHERE meta_key LIKE '%follow_us%' OR meta_value LIKE '%<script%';"
• Disable unfiltered_html capability for authors and contributors (MU plugin snippet shown earlier).
• Example ModSecurity rule template (adapt to your WAF provider):
  See WAF rules examples above; deploy in monitoring mode for 24–48 hours, then switch to blocking once false-positive rate is acceptable.

Closing thoughts

Stored XSS vulnerabilities like the one in Prime Slider are a classic example where a seemingly small oversight (improper output encoding) can lead to persistent, high-impact attacks — because the payload lives in your own database and executes in the browsers of your admin users and visitors. Updating the plugin is the first and best action. If you cannot update right away, virtual patching with a WAF, tightening privileges, scanning for injected content, and maintaining a robust recovery plan will significantly reduce risk.

If you manage multiple WordPress sites, consider centralizing update management and enabling continuous WAF protections. The WP‑Firewall Basic (Free) plan is a practical first step to get managed rules, scanning and OWASP mitigations in place without delay: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Stay safe — and prioritize patching followed by verification and monitoring. If you need assistance applying WAF rules or running a safe forensic search on your site, WP‑Firewall’s support team can help you implement virtual patches and perform scans so you can update and recover with confidence.