Recent Social Warfare Vulnerability Allowed Remote Code Execution

In posts last week, we detailed a vulnerability in the Social Warfare plugin, and discussed the attack campaigns against it. These issues were reported widely as Cross Site Scripting (XSS) flaws, due to an unexpected disclosure and proof of concept released by an unnamed researcher. Our Threat Intelligence team quickly released a firewall rule to mitigate impact for our customers, and the plugin’s author issued a patch shortly thereafter. Attackers have issued persistent exploit attempts against this flaw, which are primarily connected to injected JavaScript redirect activity.

However, the patched vulnerability was not limited to XSS behavior. During the triage process, our team identified additional exploitable behavior in Social Warfare’s database migration code. This allowed remote code execution (RCE) on the vulnerable version, 3.5.2, in addition to the reported XSS capability.

Because the WordPress community had already been made aware of the critical 3.5.3 patch to the plugin, and because we had not identified any threat actors making use of this capability in the wild, we withheld this element from publication temporarily. We reached out to the plugin team to make sure they were aware of the issue, and have continued to monitor attack data to confirm no malicious RCE attempts have been caught.

Earlier today, this additional capability was reported by another security research team. Because this will more than likely prompt a new wave of exploit attempts, we feel it’s important to inform our users of the scope of these issues, and how we protect them.

Before we discuss the scary parts, some good news. The RCE vulnerability was removed in the same patch as the XSS flaw, 3.5.3. If you’ve updated Social Warfare, you are not vulnerable to this additional flaw. Additionally, the firewall rule we released last week for the XSS issue blocks the RCE as well, so Wordfence Premium customers are still secure if they haven’t managed to update yet. As usual, firewall or otherwise, it’s important that you update to 3.5.3 of Social Warfare immediately.

Remote Code Execution (RCE) Vulnerability In Detail

In last week’s post detailing the XSS vector, we shared a snippet of the plugin’s code that was responsible for the initial injectable input. The plugin is provided a remote URL, ostensibly containing an exported set of Social Warfare configuration options, and fetches the contents to begin the migration process.

 * Migrates options from $_GET['swp_url'] to the current site.
 * @since 3.4.2
if ( true == SWP_Utility::debug('load_options') ) {
	if (!is_admin()) {
		wp_die('You do not have authorization to view this page.');

	$options = file_get_contents($_GET['swp_url'] . '?swp_debug=get_user_options');

However, this snippet cut short of the RCE flaw just a few lines below:

$options = str_replace('<pre>', '', $options);
$cutoff = strpos($options, '</pre>');
$options = substr($options, 0, $cutoff);

$array = 'return ' . $options . ';';

try {
	$fetched_options = eval( $array );

The intent of this code was to parse a remote text document into a key->value array of options for the plugin to use. However, instead of using a typical data storage format like a serialized string or (preferably) JSON, the plugin generated options as an actual block of PHP code, which is crunched by eval() into an array.

Configuration document generated by Social Warfare to be migrated into a new site.

When a malicious injection matches the format used by the plugin normally, as in the attack campaigns running currently, an XSS payload can be injected into one or more of those settings. However, the contents of <pre> tags in the remote file are arbitrarily passed to eval(), meaning the code within is executed directly as PHP.

A basic example of a remote payload demonstrating PHP execution.

As in the example above, if the contents of the remote address passed via swp_url contain a simple phpinfo(); call between <pre> tags, the site will return a rendered phpinfo page.

With the ability to execute arbitrary PHP, attackers effectively have control of vulnerable sites. First, backdoors can be deployed, rogue WordPress administrators can be created, and system commands can be run, among other footholds. From there, attackers can leverage the controlled site however they choose, whether for spam, phishing, or other monetization methods.


To reiterate, this is not a new vulnerability. This is the same flaw that was patched in Social Warfare 3.5.3, and that the Premium version of the Wordfence firewall has protected against since last week. If you believe anyone in your network uses the Social Warfare plugin and still has not updated, please make sure they’re aware of this issue. We are still tracking the threat actors targeting this vulnerability, and will report on noteworthy findings as they present themselves.

Did you enjoy this post? Share it!


  • I noticed a couple of days ago how when clicking on a post link it would always take me to a spammy site. I took me ages to trace it back to the Social Warfare plugin which I have since deleted.

  • As suggested in FB group a few days back, I had installed and used the free version for a few days. Wpcrafter posted about the problem on the same day becs his site had hacked. I removed the plugin immediately. I have installed wordfence free. Thanks for the updated email.

  • nice post