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 <script in post content
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';

-- Search for script tags in postmeta
SELECT post_id, meta_key, meta_value 
FROM wp_postmeta 
WHERE meta_value LIKE '%<script%';

-- Search for JS event attributes or suspicious onerror/onload
SELECT option_name FROM wp_options WHERE option_value LIKE '%onerror=%' OR option_value LIKE '%onload=%';

WP-CLI examples

wp db query "SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Audit users and logs

• Check wp_posts.post_author and wp_users timestamps for unusual activity.
• Inspect web server access logs for POST requests to slider endpoints containing HTML payloads.

Inspect admin screens

Preview slider pages in an isolated environment. Prefer viewing page source or using tools that avoid executing inline scripts. If you must open a page, do so from a staging or isolated browser profile.

If you find malicious content

1. Export suspicious rows and preserve them for evidence.
2. Remove or sanitize the malicious content (examples below).
3. Rotate credentials and invalidate active sessions.

How developers should fix the plugin (recommended code-level changes)

Fixes must follow three pillars: validate and sanitize input on save, escape output on render, and enforce capability & nonce checks.

1. Server-side sanitization on save

Do not trust HTML from users without unfiltered_html. Use WordPress sanitizers:

• sanitize_text_field() — for plain text
• sanitize_textarea_field() — for multi-line text
• wp_kses() / wp_kses_post() — to allow a safe subset of HTML

Example save handler:

// Allowed tags for slider descriptions (example)
$allowed_tags = array(
  'a' => array('href' => array(), 'title' => array()),
  'strong' => array(),
  'em' => array(),
  'br' => array(),
  'p' => array(),
  'img' => array('src' => array(), 'alt' => array(), 'title' => array(), 'width' => array(), 'height' => array()),
);

if ( isset( $_POST['slider_caption'] ) ) {
  $caption = wp_kses( wp_unslash( $_POST['slider_caption'] ), $allowed_tags );
  update_post_meta( $post_id, '_slider_caption', $caption );
}

2. Properly escape output

Escape at the last moment before output:

• esc_html() for plain text inside elements
• esc_attr() for attributes
• wp_kses_post() if intentionally allowing a subset of tags

$caption = get_post_meta( $post_id, '_slider_caption', true );

echo wp_kses( $caption, $allowed_tags ); // if safe tags are allowed

// or for plain text:
echo '<p>' . esc_html( $caption ) . '</p>';

3. Capability and nonce checks

Enforce authorization and protect against CSRF on any save/update handlers:

if ( ! isset( $_POST['my_slider_nonce'] ) || ! wp_verify_nonce( $_POST['my_slider_nonce'], 'my-slider-save' ) ) {
  return;
}

if ( ! current_user_can( 'edit_post', $post_id ) ) {
  return;
}

4. Validate uploads

For image uploads, validate mime types via wp_check_filetype() and use wp_handle_upload() for WP’s upload sanitation.

5. Avoid raw unsanitized output

Do not save raw HTML that you later echo without escaping. This pattern causes many stored XSS flaws.

6. Tests and static analysis

Add unit tests that attempt to save malicious payloads and verify sanitization, and run static analysis (PHPStan, Psalm) in CI to catch direct unsanitized echoes.

Sample safe save_post hook

add_action( 'save_post_slider', 'my_slider_save_meta', 10, 2 );
function my_slider_save_meta( $post_id, $post ) {
  if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
    return;
  }
  if ( ! isset( $_POST['my_slider_nonce'] ) || ! wp_verify_nonce( $_POST['my_slider_nonce'], 'my-slider-save' ) ) {
    return;
  }
  if ( ! current_user_can( 'edit_post', $post_id ) ) {
    return;
  }

  if ( isset( $_POST['caption'] ) ) {
    $allowed = array(
      'a' => array( 'href' => array(), 'title' => array() ),
      'strong' => array(),
      'em' => array(),
      'br' => array(),
      'p' => array(),
    );
    $caption = wp_kses( wp_unslash( $_POST['caption'] ), $allowed );
    update_post_meta( $post_id, '_my_slider_caption', $caption );
  }
}

WAF and virtual patching guidance (generic)

While waiting for an upstream vendor patch, web-layer controls can reduce risk. Apply rules carefully and test on staging to avoid blocking legitimate traffic.

• Block POST requests to slider save endpoints containing <script or suspicious event attributes (onerror=, onload=) in fields that expect plain text.
• Block or flag requests with javascript: URIs in URL fields.
• Flag requests containing </script> 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 <script
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

# Search postmeta
wp db query "SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

Remove script tags from a meta value (backup first)

-- Replace <script...>...</script> with empty string in postmeta
UPDATE wp_postmeta
SET meta_value = REGEXP_REPLACE(meta_value, '<script[^>]*>.*?</script>', '', 'gi')
WHERE meta_value ~* '<script';

Export suspicious rows for offline review

wp db query "SELECT * FROM wp_postmeta WHERE meta_value LIKE '%<script%';" --skip-column-names > suspicious_meta.csv

Recommendation: prefer a controlled sanitization script (using wp_kses with allowed tags) run on a staging copy rather than blind global regexp replacements on production.

Illustrative WP-CLI sanitization loop (test on a copy first)

# Example (illustrative only; adapt and test thoroughly)
IDS=$(wp db query "SELECT meta_id FROM wp_postmeta WHERE meta_value LIKE '%<script%';" --skip-column-names)
for ID in $IDS; do
  VALUE=$(wp db query "SELECT meta_value FROM wp_postmeta WHERE meta_id = $ID" --skip-column-names)
  SANITIZED=$(php -r "echo htmlspecialchars(strip_tags(urldecode('$VALUE')), ENT_QUOTES);")
  wp db query "UPDATE wp_postmeta SET meta_value = '"$SANITIZED"' WHERE meta_id = $ID;"
done

Note: The above is illustrative. Preserve allowed markup when appropriate using wp_kses in a PHP environment rather than simplistic strip_tags.

Final recommended timeline (practical checklist)

Immediate (within hours)

• Verify plugin version; deactivate if ≤ 2.0.
• Restrict contributors and remove untrusted users.
• Apply host or application-layer rules to filter slider POSTs containing script tags.
• Scan DB for script tags and suspicious content.

Short term (1–3 days)

• Remediate found malicious content (backup before editing).
• Rotate admin credentials and invalidate sessions.
• Apply CSP and secure cookie settings.

Medium term (1–2 weeks)

• Monitor logs for exploitation attempts.
• If you maintain the plugin: publish a patch that sanitizes input, escapes output and enforces capability checks; release an advisory and update the plugin.

Long term (ongoing)

• Harden workflows and reduce accounts that can create HTML content.
• Introduce automated tests and static analysis in CI.
• Keep backups, monitoring and perimeter controls in place.

Why this matters to you

Even though exploitation requires a contributor account, many sites rely on contributor workflows. Stored XSS remains an effective technique for attackers to maintain persistence and escalate impact because it executes in the victim’s browser context. If your site accepts content from semi-trusted users, treat this vulnerability as high priority and follow the containment and remediation steps above.

If you are a plugin developer or integrator

Follow the secure coding guidance listed earlier, add tests that attempt to inject payloads, and implement a vulnerability disclosure and patching process. Fast, responsible remediation reduces risk to downstream sites.