Smart Slider 3 flaw CVE-2026-3098 lets subscribers read wp-config.php on WordPress sites

CVE-2026-3098 in Smart Slider 3 up to 3.5.1.33 lets any logged-in subscriber read server files like wp-config.php. Update to 3.5.1.34; why nonces aren't authz.

TechLogHub Engineering Team
March 29, 2026
3 min read
0 views

Share Article

File read flaw in Smart Slider plugin impacts 500K WordPress sites

A file read vulnerability in Smart Slider 3, a WordPress slider plugin active on more than 800,000 sites, lets any logged-in user with Subscriber access or higher read arbitrary files from the server, including wp-config.php. A fix shipped on 24 March 2026, but BleepingComputer estimated that at least 500,000 sites were still unpatched days later. It's a common WordPress mistake: treating a nonce as an authorization check.

What happened

Researcher Dmitrii Ignatyev reported the bug to Wordfence on 23 February 2026. Wordfence validated the proof of concept and notified the developer, Nextendweb, which acknowledged it on 2 March and released version 3.5.1.34 on 24 March. The flaw is tracked as CVE-2026-3098 and rated CVSS 6.5 (medium) because it needs an authenticated account. It affects all versions up to and including 3.5.1.33.

Based on WordPress.org download figures (about 303,000 downloads in the week after the patch), BleepingComputer estimated that at least 500,000 installs were still vulnerable. No exploitation in the wild had been reported at the time.

Who is affected

  • WordPress sites running Smart Slider 3 version 3.5.1.33 or earlier.
  • The risk is highest on sites that let anyone register (WooCommerce stores, membership sites, forums, LMS platforms), because attackers can create the Subscriber account they need.
  • Sites with no public registration are exposed through any existing low-privilege account, including one taken over with a reused password.

What it means for developers and engineering teams

The bug lives in the plugin's AJAX export actions. Those handlers checked a nonce but not the user's capabilities, so any logged-in user could call them. The actionExportAll function then added files to the export archive without checking the file type or that the path was inside an expected directory. As Wordfence's István Márton put it, not only images or videos could be exported, but .php files as well.

The design lesson is that a WordPress nonce is a CSRF token, not an authorization control. Nonces are issued to every logged-in user who loads the right page, so having a valid one only shows the request wasn't forged cross-site. It says nothing about whether the user may perform the action. Every privileged AJAX or REST handler needs an explicit capability check, and any handler that reads files needs strict path validation:

add_action('wp_ajax_myplugin_export', function () {    check_ajax_referer('myplugin_export');           // CSRF protection    if (!current_user_can('manage_options')) {       // authorization        wp_send_json_error('forbidden', 403);    }    $base = realpath(WP_CONTENT_DIR . '/uploads');    $path = realpath($base . '/' . sanitize_text_field($_POST['file'] ?? ''));    if ($path === false || strpos($path, $base . DIRECTORY_SEPARATOR) !== 0) {        wp_send_json_error('invalid path', 400);    }    // ... safe to read $path});

Reading wp-config.php gives an attacker the database credentials plus the authentication keys and salts. With the salts, valid login cookies can be forged. With the database password, a remotely reachable database can be taken over. A "medium" file-read bug can therefore become a full site compromise.

What to do now

  1. Update to Smart Slider 3 version 3.5.1.34 or later. With WP-CLI: wp plugin list --name=smart-slider-3 then wp plugin update smart-slider-3.
  2. Check whether open registration is needed with wp option get users_can_register, and turn it off if not.
  3. Review logs for unusual admin-ajax.php requests from Subscriber accounts during the exposure window, and for subscriber accounts you don't recognise.
  4. If you suspect abuse, rotate secrets: change the database password and regenerate the keys and salts in wp-config.php, which logs everyone out.
  5. Limit the damage of future file reads: make sure the database only accepts local or private-network connections, and keep other secrets out of files the web server user can read.
  6. Plugin authors: check every wp_ajax_ handler for a current_user_can() check, not just a nonce.

Related on TechLogHub

  • CSRF: what nonces actually protect against
  • Authorization: capability checks and least privilege

Sources

Stay Updated

Get the next deep dive in your inbox

Subscribe for product analysis, engineering explainers, and practical guides published on TechLogHub.

See what launched this week

One email a week: new and trending developer tools, fresh comparisons, and what shipped. Unsubscribe in one click.