Smart Slider 3 Pro Backdoor: Six Hours to Compromise 800,000 Sites

On April 7, 2026, an unauthorized party gained access to Nextend's update infrastructure and pushed a trojanized build of Smart Slider 3 Pro, tagged 3.5.1.35, through the plugin's official auto-update channel. For roughly six hours, every WordPress site running Smart Slider 3 Pro with auto-updates enabled received the malicious version. The backdoor it installed is not subtle. It creates hidden administrator accounts, plants persistence in three separate locations, accepts pre-authenticated remote code execution via custom HTTP headers, and exfiltrates credentials and site configuration to an attacker-controlled domain.

Smart Slider 3 has more than 800,000 active installations across its free and Pro editions. Only the Pro version, only version 3.5.1.35, and only sites that updated between the release and the detection window are affected. Even so, the six-hour window is long enough to have compromised thousands of sites, and the forensic profile of the backdoor means many of those sites are still compromised even after updating to the clean 3.5.1.36 release.

If you run Smart Slider 3 Pro, this post is a checklist. Don't skim it.

Timeline

• April 7, 2026. Nextend releases Smart Slider 3 Pro version 3.5.1.35 through its official update server.
• April 7, 2026 (approximately six hours later). Researchers identify the release as compromised, notify Nextend, and the malicious build is pulled.
• April 7, 2026. Nextend publishes version 3.5.1.36 containing the clean code.
• April 8, 2026. Detection advisories begin circulating, and hosting providers start sweeping customer fleets for signs of the backdoor.

The six-hour window is the critical period. Any Smart Slider 3 Pro site that auto-updated during that window received the backdoor. Sites that had auto-updates disabled and updated manually later may have received the clean 3.5.1.36 depending on exactly when they pulled. Sites still running 3.5.1.34 or earlier were never exposed.

How the Backdoor Works

The trojanized update doesn't hide itself inside the Smart Slider plugin directory. That would make it easy to remove. Instead, it uses the update process as an installer, drops its real payload in three separate locations outside the plugin, and disappears from the plugin itself as if nothing had happened. That's why simply updating to 3.5.1.36 doesn't clean an affected site.

Persistence Location 1: The Must-Use Plugin

The installer drops a file called object-cache-helper.php into wp-content/mu-plugins/. Must-use plugins are loaded automatically by WordPress on every request, before regular plugins, and cannot be deactivated through the normal plugin management interface. They don't appear in the Plugins screen. A site owner who goes looking for malicious plugins won't find this one unless they browse the mu-plugins directory directly on the filesystem.

The file is named object-cache-helper.php because the name is plausible. WordPress sites genuinely do use MU plugins to provide object caching helpers, and the specific name is just ambiguous enough that a casual inspection might dismiss it as legitimate infrastructure. A forensic examination of the file contents immediately reveals the malicious code, but no automated scanner that works by filename alone will catch it. Our writeup on PHP backdoors in WordPress covers several more examples of this exact naming trick.

Persistence Location 2: The Theme's functions.php

The installer also appends code to the active theme's functions.php file. This second persistence location survives plugin uninstalls, plugin updates, and even deletion of the mu-plugins file, because functions.php is part of the theme and is reloaded on every page request. It doesn't survive a theme switch, but most site owners don't switch themes as part of incident response.

The code appended to functions.php is typically a single obfuscated PHP block, either base64-encoded or hex-encoded, designed to look like a cache or performance helper. The block unpacks and executes the real payload at runtime, which makes simple grep-based detection harder unless you know which encoding to look for.

Persistence Location 3: A Fake Core File

The third location is the most aggressive. The installer drops a file called class-wp-locale-helper.php into wp-includes/. This is the directory WordPress uses for its own core files. Dropping a malicious file there violates every WordPress convention, but it's effective precisely because WordPress itself doesn't check for extra files in wp-includes during core updates. The update process only verifies that expected files are present and correct, not that unexpected files are absent.

A file in wp-includes with a name like class-wp-locale-helper.php looks, to the untrained eye, exactly like a legitimate WordPress core file. A developer auditing the directory might assume it was part of WordPress itself. It isn't. It's part of the backdoor, and it serves as the fallback persistence mechanism if both the MU plugin and the theme file are removed.

The Runtime Capabilities

Once any of the three persistence locations is loaded, the backdoor registers a handler on every WordPress request that inspects incoming HTTP headers. If the request contains X-Cache-Status: <magic-value> and X-Cache-Key: <command>, the backdoor decodes the command and executes it as PHP, pre-authenticated. No login is required. No nonce is checked. The headers are invisible to ordinary visitors because no browser sends them, and they don't appear in most server access logs because access logs typically don't record request headers by default.

Alongside the header-triggered RCE, the backdoor:

• Creates hidden administrator accounts matching the naming pattern wpsvc_<random-hex>, for example wpsvc_a3f1 or wpsvc_9b4c.
• Stores configuration and state in WordPress options with names like _wpc_ak, _wpc_uid, and _wpc_uinfo.
• Exfiltrates site credentials, site configuration, and a catalogue of the backdoor's own persistence methods to the command-and-control domain wpjs1[.]com.
• Accepts arbitrary PHP execution via hidden request parameters, providing a secondary remote access channel if the header-based method is disrupted.

The result is a site that continues to function normally for its legitimate users while being fully under the attacker's control. The attacker can read the database, steal customer data, install further malware, pivot to other sites on the same server, or sit silently and wait for a more valuable moment. Our 9 signs your WordPress site has been hacked post has the full list of red flags worth watching for.

Remediation

Update Smart Slider 3 Pro to 3.5.1.36 immediately. This removes the trojanized plugin code but doesn't clean the three persistence files or the malicious options. The plugin update is necessary but not sufficient.

Delete the three persistence files. On the server, remove:

• wp-content/mu-plugins/object-cache-helper.php
• Any code block appended to your active theme's functions.php that you didn't write
• wp-includes/class-wp-locale-helper.php

Before deleting, take a copy of each file so you have a forensic record of what was installed. This is worth doing even if you aren't going to analyse the files yourself, because security researchers may ask for samples.

Remove the malicious WordPress options. Run the following against the database on a staging copy of the site to find them first:

SELECT option_name FROM wp_options WHERE option_name IN ('_wpc_ak', '_wpc_uid', '_wpc_uinfo');

If any of the three are present, delete them. WP-CLI makes this easy:

wp option delete _wpc_ak _wpc_uid _wpc_uinfo

Audit the user list for hidden administrator accounts. The wpsvc_<hex> naming pattern is a strong indicator, but the attacker may vary the prefix. Run:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Any administrator you don't recognise, particularly any account registered on or after April 7, 2026, is a candidate for the backdoor. Delete them, reassigning any content they own to a legitimate account.

Rotate every secret. Change the WordPress salts in wp-config.php, force a password reset for all users, regenerate API keys, and rotate any secrets stored in options or environment variables. The attacker had code execution for some period of time. Assume the entire credential surface is burned. For a full post-compromise playbook, follow our WordPress malware removal guide.

Check server access and error logs for header-triggered RCE attempts. Look for requests containing X-Cache-Status and X-Cache-Key headers. Most web servers don't log custom headers by default, so you may need to check application-level logs or enable header logging if you want a complete picture. Even without logs, the fact that any such request was possible is enough to assume the attacker used it.

Quarantine the site and investigate laterally. If you host multiple WordPress sites on the same server, assume they are all at risk. The backdoor had arbitrary PHP execution, which means it had read access to anything the web server process could reach. Check neighbour sites for the same three persistence files and the same malicious options. If you're using shared hosting with strict site isolation, the blast radius is limited. If you're using a VPS or dedicated server with weak isolation, it isn't.

What Nextend Needs to Explain

At the time this post is being written, the detailed post-mortem from Nextend hasn't been published. The critical questions a full post-mortem will need to answer:

• How was the update infrastructure accessed? Compromised developer credentials? A vulnerability in the update server software? A trusted third party with access? Each answer implies different defensive measures for other plugin vendors.
• When was access obtained? If the attacker had access to Nextend's infrastructure for days or weeks before pushing 3.5.1.35, there may be other artefacts (other releases, other changes) that also need auditing.
• What was the exact content of 3.5.1.35 versus 3.5.1.36? A side-by-side diff published by a trusted third party, not just by Nextend, is needed for the community to verify that 3.5.1.36 is truly clean.
• Are any other Nextend products affected? Smart Slider 3 is Nextend's flagship but not their only product. If the compromise was at the infrastructure level rather than the project level, other Nextend plugins and themes may also be at risk.

Sites running Smart Slider 3 Pro should not wait for these answers before remediating. The checklist above stands regardless of what the post-mortem eventually reveals.

Why Signed Updates Would Have Helped

WordPress doesn't, as of this writing, verify plugin update signatures. When your site downloads a plugin update, it trusts whatever the update server says the correct file is. If the update server is compromised, your site downloads the malicious version and installs it. There's no cryptographic check that would catch a server-side tampering of the update payload.

This is a gap the WordPress core team is aware of. Proposals for signed updates have been discussed for years, and some progress has been made on the infrastructure needed to support them. The Smart Slider incident is a reminder of why the work matters. A signed update system would mean that even if an attacker compromised Nextend's update server, they couldn't push a malicious update unless they also had access to the signing key, and the signing key can be kept on hardware isolated from the update server. The supply chain becomes significantly harder to compromise when the distribution channel and the signing channel are separated.

Until signed updates are reality in WordPress, the only practical defence is behavioural monitoring. Watch for unexpected file changes. Watch for new mu-plugins. Watch for new administrator accounts. Watch for unexplained PHP files in wp-includes. Each of these is a tripwire that would have caught this backdoor within minutes of installation. (The Essential Plugins supply chain incident from the same week shows the same lesson with a very different attack path.)

WP Vanguard Detection

WP Vanguard now flags the three persistence files used by the Smart Slider backdoor as known indicators of compromise. A deep scan will also surface the _wpc_ option keys, the wpsvc_ administrator pattern, and any PHP injection in theme functions.php files that matches the obfuscation pattern used by this campaign. If you run Smart Slider 3 Pro and haven't scanned your site since April 7, queue a deep scan now. If the scan comes back clean, you're almost certainly fine. If it comes back dirty, follow the remediation checklist above and treat the site as fully compromised until it's thoroughly rebuilt.

References

• The Hacker News: Backdoored Smart Slider 3 Pro Update Distributed via Compromised Nextend Servers
• Cyberpress: Hackers Use Silent Malware to Take Over WordPress Admin Accounts
• TechRadar: WordPress websites under attack: expert report says dozens of plugins hijacked