Slider Revolution Vulnerability: What Site Owners Should Know

Contents

A widely used WordPress plugin called Slider Revolution was found to have a security flaw that can let attackers read files on a website. This vulnerability has been linked to a public advisory and an assigned CVE number.

According to Wordfence’s vulnerability database, 4 million WordPress sites could have been exposed to an arbitrary file read issue in Slider Revolution (versions up to 6.7.36).

If your site uses the plugin, the steps you take now will shape how well you avoid data leaks and costly cleanups.

How the Vulnerability Exposes Sensitive Files on WordPress Sites

A vulnerability in the Slider Revolution plugin allowed certain users to read files on the web server that they should not have been able to open. The bug uses path traversal techniques: that means a crafted request could point the plugin to files outside its normal folder. Files like configuration files, backups, or key files can be exposed.

The vulnerability had a low bar for access: contributor-level accounts could trigger the read. That is a common role on many sites where outside writers or less-trusted users can submit media or posts. When a plugin accepts file paths or names from a user and does not check them properly, attackers can manipulate those inputs.

Because Slider Revolution is widely installed, many websites could be affected. That is why the recommended first step is to update the plugin. Plugin creators released a fixed version and site owners are urged to run that update.

How Attackers Exploit Path Traversal in Slider Revolution to Steal Sensitive Data

Imagine a library where a librarian should only hand you books from a public shelf. The plugin acted like a librarian who sometimes took a book request with a secret path that led to the archive room. If the librarian follows that secret path, they might hand over private documents.

The plugin had a function that accepted lists of image or SVG references. Attackers could send special requests that included path traversal sequences. Those sequences tell the server to move up directories and access files outside the safe folder. When a file is readable by the web server account, the plugin would return its contents.

Files that attackers often target include configuration files, database credentials stored in wp-config.php, and old backups left on the server. If someone can read configuration details, they can learn usernames, passwords, and API keys that the site uses. That is the risk.

Sites Affected by the Slider Revolution Vulnerability

Sites using Slider Revolution versions at or below 6.7.36 were flagged as affected by the advisory. The plugin is commonly bundled with themes and also distributed as a standalone plugin. Because of that distribution model, many WordPress sites use it, including some that are not regularly updated.

If you manage multiple sites, check each site for the plugin and its installed version. Themes sometimes include a copy of the plugin inside their files. That copy can be missed by routine plugin checks if it is nested inside a theme.

You can confirm the plugin version from the WordPress dashboard or with a quick command line check if you have access to WP-CLI. I list a few commands later that make these checks easy.

How to Secure Your Site After the Slider Revolution Vulnerability

Follow these steps in order. Each step is short and has a reason you can understand.

Update Slider Revolution. Go to your WordPress admin and update the plugin, or use WP-CLI. Updating to the patched release is the primary fix.
If you cannot update immediately, remove the plugin or disable it temporarily. If you rely on the plugin for live site features and cannot remove it, block access to the plugin endpoints with a web application firewall (WAF) or server rules.
Restrict contributor uploads. Temporarily remove the upload_files capability from Contributor roles if your site uses that role for external users.
Check server and WordPress logs for evidence of attempts to read files. Look for calls to admin-ajax.php or plugin endpoints that include strings like used_svg or used_images.
Rotate credentials if needed. If you find clear evidence that sensitive files were read, change your database password and any API keys that might have been exposed.
Scan for added files or web shells. Use a trusted malware scanner and check the uploads and plugin folders for code that shouldn’t be there.
Restore from a verified backup if the site shows signs of tampering. Make sure the backup predates any suspected intrusion.
Apply long-term hardening. Enforce two-factor authentication for administrators, limit plugin/theme edits in production, and keep regular backups off the same server where the site runs.

Manual Inspection Tips for Identifying the Exploit Activity

Below are short, practical commands. Use what you can apply.

Check plugin version with WP-CLI:

wp plugin list --format=table | grep revslider

This shows the installed Slider Revolution version. If the version is 6.7.36 or lower, treat it as needing an update.

Update via WP-CLI:

wp plugin update revslider

Running that without a version argument updates to the latest available release from the WordPress repository.

Search webserver logs for telltale parameters:

grep -i "used_svg\|used_images" /var/log/nginx/access.log*

or for Apache

grep -i "used_svg\|used_images" /var/log/apache2/access.log*

Look for admin-ajax calls related to the plugin:

grep -i "admin-ajax.php" /var/log/* | grep -i "revslider\|revslider"

(Adjust paths to suit your host.)

Find suspicious files in uploads or plugin folders:

find wp-content/uploads -type f -mtime -30

This lists files added or changed in the last 30 days. If you see PHP files in the uploads folder, that is a red flag.

How to Detect a Compromise: What to Look For

Detection is a mix of log searches, file checks, and account review.

Logs: Repeated or patterned requests to the plugin endpoints. Rapid sequences of requests that include path traversal markers like ../ are suspicious.
Files: Unexpected PHP files in the uploads directory. Modified plugin or theme files that you did not change.
Accounts: New administrator accounts you did not create. Plugins or pages added without your permission.
Behavior: Site defacements, redirects to other sites, or unexpected outbound connections from your server.

If you find evidence, act quickly: rotate credentials, pull a clean backup, and work with your host or a professional incident responder.

Long-Term Steps to Reduce Risk

Short-term fixes patch the immediate hole. Long-term steps reduce the chance of future incidents.

Keep plugins and themes updated. Schedule regular checks.
Use a managed WAF or a host that provides automatic rules for common attacks.
Remove plugins and themes you no longer use. Fewer installed packages means fewer potential holes.
Use role-based controls and limit which accounts can upload files.
Keep off-site backups. Store backups in a place not directly reachable from your website.
Enable two-factor authentication for administrator-level accounts.

If a Breach Happened: A Basic Incident Response Plan

Here is a short plan to follow if you find evidence that files were read or the site was changed.

Take the site offline or put it into maintenance mode to stop active damage.
Capture logs and a snapshot of the site for later analysis. Preserve data for your host or an incident responder.
Rotate credentials: database, admin accounts, FTP, SSH, and any API keys used by the site.
Scan for web shells and backdoors. Remove or quarantine any malicious files you find.
Restore from a known-good backup if you can verify one. If you cannot, rebuild clean and import only verified content.
Report the incident to your host and to relevant third parties if customer data was exposed.
Review and learn. After containment and recovery, review how access controls or processes allowed the issue and adapt.