Antecedentes e impacto

On 7 April 2026 a stored XSS vulnerability was disclosed affecting Prime Slider – Addons For Elementor (versions up to and including 4.1.10). The plugin stored a value from the follow_us_text parameter without sufficient sanitization or output escaping. An authenticated user (author-level or higher) could inject HTML/JavaScript that is stored and later executed in other users’ browsers when the value is rendered.

The issue is recorded as CVE-2026-4341 and was fixed in version 4.1.11. Although the reported CVSS is moderate (~5.9), stored XSS is high-risk in practice: attackers can steal session tokens, act as admins, persist redirects, or install further backdoors.

Quién está en riesgo

• Sites running Prime Slider – Addons For Elementor plugin version 4.1.10 or earlier.
• Sites that allow non-admin authenticated users (Author/Contributor) to create or edit slider content.
• Sites where follow_us_text is rendered to pages viewed by administrators, editors, or unauthenticated visitors.
• Multisite networks where the plugin is network-active.

Even low-traffic sites can be targeted or discovered by automated scanning. Treat this as actionable: check versions and patch quickly.

Cómo funciona la vulnerabilidad (a alto nivel)

1. follow_us_text is a plugin setting/editable field saved to the database (options, postmeta, or plugin settings).
2. Input handling does not properly sanitize or escape dangerous input (script tags, event attributes).
3. On output, stored HTML/JS executes in visitors’ browsers. Persistence makes the payload effective across sessions.
4. An author-level attacker can inject a payload that executes when administrators or other privileged users view the slider.
5. Consequences include cookie theft, session hijack, CSRF-style privileged actions, or delivery of secondary payloads.

Escenarios de explotación y objetivos del atacante

• Privilege escalation pivot: capture admin session/cookies when admin views affected pages.
• Persistent malware drop: inject scripts that load external malware, ads, or spam.
• Social engineering & redirects: show fake admin prompts or redirect to phishing/monetized sites.
• SEO poisoning / spam insertion: hide links or content that degrade reputation and rankings.
• Second-stage delivery: use XSS to perform authenticated actions (upload plugin, change options).

Safe detection and indicators of compromise

Focus on stored content and behavioral signs:

• Unexpected inline <script> tags, javascript: URIs, or on* attributes (onclick, onmouseover) in plugin settings, theme options, or slider content.
• Unexpected inline JS appearing on pages that include the slider.
• Admins seeing popups, password prompts, or redirects only when logged in.
• New admin-level users, unauthorized content, or unknown scheduled tasks.
• Outbound connections to unfamiliar domains initiated by site pages.
• Security scanner alerts referencing plugin version and XSS.

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

Back up files and DB before making changes. Prefer read-only queries when investigating.

SQL examples (adjust table prefix if not wp_):

SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%javascript:%' LIMIT 50;

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%onmouseover=%' OR post_content LIKE '%javascript:%' LIMIT 100;

SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_key LIKE '%follow_us%' OR meta_value LIKE '%<script%' LIMIT 100;

SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 200;

WP-CLI examples (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):

grep -R "follow_us" wp-content/ -n
grep -R "<script" wp-content/uploads/ -n

Note: Legitimate code may include <script> (themes/plugins). Review context and look for obfuscated JS: eval, unescape, fromCharCode, base64 strings.

Immediate remediation steps (short path)

1. Actualiza el plugin: Upgrade Prime Slider to 4.1.11 or later — this fixes the root cause.
2. Tighten privileges until patched: Restrict who can edit slider content. Remove untrusted author/contributor edit rights for sliders.
3. Patching virtual a través de WAF: If you cannot update immediately, deploy Web Application Firewall rules to block script tags and suspicious payloads in requests that write settings (see WAF examples below).
4. Block dangerous request patterns: Deny POSTs that include follow_us_text with script-like strings.
5. Search for stored injections: Use the SQL/WP-CLI/file search patterns above to find evidence of injected scripts.
6. Reset sessions and credentials if compromise suspected: Force logout for all users, reset admin passwords, and rotate authentication salts in wp-config.php.

Recommended hardening and long-term mitigation

1. Principio de menor privilegio: Only trusted users should edit content that allows unfiltered HTML. Limit capabilities to administrators where feasible.
2. Remove unfiltered_html from lower roles: Use role management or a small MU plugin to revoke unfiltered_html for authors and contributors.

Example MU plugin snippet (test in staging first):

<?php
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');
        }
    }
});

3. Output escaping & sanitization: Plugin developers should sanitize input and escape output (sanitize_text_field, wp_kses_post, esc_html, esc_attr).
4. Política de Seguridad de Contenidos (CSP): Deploy a restrictive CSP to reduce impact of injected inline scripts (for example, disallow inline scripts and limit script-src to trusted origins).
5. Disable plugin UI for untrusted roles: Remove menu access or capability checks to prevent slider editing by non-admins.
6. Periodic scans & monitoring: Schedule regular checks for injected JS, enable file integrity monitoring, and review alerts.
7. Backups & tested restores: Keep recent, offline backups and practice restore procedures.

WAF / virtual patch rules and examples

A WAF provides immediate virtual patching. Below are conceptual ModSecurity-style rules and patterns you can adapt. Test in monitoring mode 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:'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 plugin 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"

Orientación:

• Start rules in monitor/log-only mode for 24–48 hours to measure false positives.
• When acceptable, switch to blocking mode for the most reliable rules (follow_us_text-specific rules first).
• Where possible, apply positive allow-lists restricting follow_us_text to plain text or a limited safe HTML subset.

If your site is already compromised: recovery plan

1. Contener: Put the site in maintenance mode and limit further damage.
2. Snapshot/backup: Take a forensic copy of files and DB before remediation and store securely offline.
3. Rotar credenciales: Reset admin, FTP, API keys; change DB password; rotate WordPress salts to invalidate sessions.
4. Remove malicious entries: Delete or sanitize affected options/postmeta discovered by your searches. Keep conservative backups.
5. Escanea y limpia: Run full malware scans and remove malicious files or code. If the infection is deep, restore from a known-clean backup.
6. Re-audit plugins/themes: Update all to latest versions; remove unused or abandoned plugins.
7. Revisar registros: Check access logs to determine attack vector, new admin accounts, cron tasks, or unexpected code changes.
8. Asegura y monitorea: Apply hardening steps above and enable continuous monitoring and WAF rules to prevent re-infection.
9. Involucra a profesionales: For complex compromises, consider a forensic security firm to perform deep cleanup and recovery.

Operational recommendations for multisite and agencies

• Network admins: update the plugin network-wide immediately — network-active plugins can affect all subsites.
• Agency-managed sites: audit roles across client sites and centralize update management where possible. Consider controlled auto-updates for security releases.
• Client communications: notify affected clients of the risk, the planned remediation timeline (patch + scan + monitoring), and actions taken.

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. Si no puedes actualizar ahora:
   • Restrict editing capabilities for untrusted roles.
   • Deploy WAF/virtual-patch rules to block follow_us_text XSS payloads.
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 before making changes.
   • Sanitize or remove malicious entries (test on staging first).
   • Reset passwords and rotate salts.
6. Run a full malware scan and monitor for suspicious activity and rule hits.
7. Implement long-term hardening: least privilege, CSP, periodic scans, backups.