Summary

A stored cross-site scripting (XSS) vulnerability exists in the Simple Responsive Slider plugin (versions ≤ 2.0). The flaw permits an authenticated user with Contributor privileges or higher to save malicious script within slider content that is later rendered to visitors or administrators. Although the assigned CVSS is 6.5, stored XSS can enable account takeover, persistent phishing, SEO poisoning and other severe outcomes. This advisory explains risk scenarios, immediate actions for site owners, detection and forensic checks, developer-level fixes, WAF/virtual patching guidance, and practical hardening steps.

What happened (high level)

The Simple Responsive Slider plugin (≤ 2.0) stores slider content without sufficient sanitization or escaping. An authenticated user with the Contributor role or higher can inject persistent JavaScript into slide captions or text fields. The payload is saved in the database and executes in the browser of anyone who views the affected slider output — site visitors and privileged users alike.

Why it matters (attack scenarios & impact)

Stored XSS is particularly dangerous because the malicious script persists on the server and runs in the context of users who load the affected page. Realistic impacts include:

• Visitor compromise: Redirects to phishing pages, injected ads, crypto-mining, or tracking and credential theft.
• Admin/editor compromise: If slider output appears in admin screens, the payload can run in admin browsers and perform actions via their session (create users, change settings, exfiltrate tokens).
• SEO / reputation damage: Hidden spam links or injected content can lead to blacklisting and loss of search rankings.
• Multi-site / supply-chain risk: Contributor access in multi-site or hosted environments can spread impact based on configuration.

Exploit prerequisites and ease:

• Requires authenticated user with Contributor role or higher.
• Low complexity for an attacker who already has contributor access.
• No victim interaction required other than loading the page that contains the slider.

Who is at risk

• Any WordPress site running Simple Responsive Slider plugin version 2.0 or earlier.
• Sites that allow contributors (or higher) to create slider content or captions.
• Environments where slider output is visible to administrators, editors, or public visitors.
• Multisite and hosted environments that permit semi-trusted users to add content.

Immediate actions for site owners (step-by-step)

If you run Simple Responsive Slider ≤ 2.0, take these steps immediately.

1. Identify plugin and version

   WP admin: Plugins → Installed Plugins → find “Simple Responsive Slider” and note the version.

   WP-CLI:

   wp plugin list --format=table

2. Deactivate the plugin (fastest immediate mitigation)

   If the slider is not critical, deactivate immediately to stop stored payloads executing:

   wp plugin deactivate addi-simple-slider

   (Replace the slug with the plugin slug used on your site.)

3. Restrict Contributor privileges until patched
   • Disable new registrations.
   • Review and remove untrusted contributors.
   • Ensure contributors do not have unfiltered_html or equivalent capabilities.
4. Apply web-layer mitigations

   If you can, apply host-level or application firewall rules to block slider save requests containing suspicious HTML (see WAF guidance below).

5. Scan for suspicious content

   Search the database for script tags and suspicious attributes (examples in the Helpful commands section).

6. Review admin activity and credentials

   Check recent contributor edits, newly created admin accounts, and login anomalies. Rotate admin passwords and invalidate sessions if you find evidence of compromise.

7. Apply browser-level mitigations

   Deploy or tighten Content Security Policy (CSP) and ensure cookies use HttpOnly and Secure flags where possible (see Long term hardening).

If you suspect active exploitation, isolate the site, preserve logs and database dumps, and restore from a known-clean backup after remediation.

Detecting exploitation and forensic checks

Focus on persistent data locations, user activity and server logs.

Check for stored payloads

Common storage locations:

• wp_posts.post_content and post_excerpt
• wp_postmeta (meta_value)
• plugin-specific tables (look for tables with your DB prefix + plugin slug)
• wp_options (less common but possible)

Example SQL queries (run on backups or read-only copies)

-- Search for  or base64-encoded JS in parameters.
Use allowlists for trusted admin IPs during tuning to reduce false positives.

Note: apply rules narrowly to slider-related endpoints or form fields to avoid collateral blocking of legitimate HTML content used by other plugins.

Long term hardening and best practices

• Principle of least privilege: Limit Contributor and higher roles where possible. Change workflows so contributors submit drafts for review rather than publish directly.
• Harden capabilities: Remove unfiltered_html and similar capabilities from contributors unless necessary.
• Content review workflow: Require moderation for any content that can include HTML (slider captions, widgets).
• Backups and integrity monitoring: Maintain periodic backups and file integrity checks.
• Deploy CSP and secure cookie flags: Example headers:

  Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; frame-ancestors 'none';
  Set-Cookie: wordpress_logged_in=...; HttpOnly; Secure; SameSite=Strict
  

• Regular scans: Periodically scan DB and files for suspicious script tags and unexpected changes.

Helpful commands and queries (WP-CLI and SQL)

Search for script tags

# Search post content for  with empty string in postmeta
UPDATE wp_postmeta
SET meta_value = REGEXP_REPLACE(meta_value, ']*>.*?', '', 'gi')
WHERE meta_value ~* '

wp db query "SELECT * FROM wp_postmeta WHERE meta_value LIKE '% suspicious_meta.csv

# Example (illustrative only; adapt and test thoroughly)
IDS=$(wp db query "SELECT meta_id FROM wp_postmeta WHERE meta_value LIKE '%